The market sold you prevention because prevention is what fits in a box
You bought the stack. After the last round of AI headlines, your board asked what you were doing about AI risk, and your team stood up the tooling that answers that question: model scanning in the pipeline, prompt-injection filters in front of the LLM, data-loss controls on the endpoints, an agent-monitoring dashboard that stays a reassuring green. On paper you're covered across every function a security program is supposed to have. Then someone in a quarterly review asks the question that has no tool behind it. When one of our agents does something wrong overnight, how do we undo it? The room goes quiet, because the honest answer is that you can't, at least not with anything on the invoice.
That quiet is the thing worth understanding. Your stack isn't broken. It's doing exactly what it was sold to do. The problem is that what it was sold to do stops at the moment prevention fails, and prevention always eventually fails. The distance between everything your tools can stop and the one thing they can't undo is the AI security recovery gap, and it's the widest, least-funded part of most AI programs I look at.
The numbers behind that come from a specific place, so you're not taking my word for it. In May 2026, Lenny Zeltser and Sounil Yu published the AI Defense Matrix under a CC BY-SA 4.0 license, building on Yu's earlier Cyber Defense Matrix. It's a clean piece of work. It takes eight classes of AI assets (models, data, agents, and the rest) and lays them against the six functions of NIST CSF 2.0, which are Govern, Identify, Protect, Detect, Respond, and Recover. That's eight rows and six columns, so 48 cells. Then they mapped roughly 239 real products into those cells to see where the market builds.
The map is lopsided in a way that should change how you read your own stack. The Identify, Protect, and Detect columns are dense, with vendors filling nearly every cell. The Govern, Respond, and Recover columns are close to empty. This isn't an accident of a young market that will fill in next year. It's structural, and once you see the structure you can't unsee it.
Look at what the crowded columns have in common. Scanning a model for known issues, filtering a prompt inline before it reaches the LLM, watching agent traffic from the outside: every one of those is a job you can do from outside the system, without touching how the system is built. An agentless scanner needs API access and nothing more. An inline filter sits in the request path. External observation watches the wire. A vendor can build any of those, sell it to a thousand customers, and deploy it in an afternoon, because none of it requires reaching inside your architecture.
Now look at the empty columns. Recovery needs internal architectural access, meaning the ability to reach into how your systems store state and put them back the way they were. Governance needs standards and decisions that are specific to your business. Response needs containment wired into your own runtime. None of that fits in a box a vendor can ship to a thousand customers, because the work is different inside every company. That's the boundary principle, and it's the cleanest explanation I have for why your money bought you a wall and not a mop. I published the cell-by-cell version as the full teardown on RockCyber Musings if you want to see every cell scored.
Figure 1. The boundary principle. Vendors sell the security functions they can reach from outside your system and skip the ones that need to be built inside it.
Two products out of two hundred is a market signal, not a shopping list
Put concrete counts on it. In the matrix, about 194 of the mapped products carry a Protect tag. The Recover column has exactly two products in it. Hirundo, which does machine unlearning to pull poisoned or unwanted data back out of a trained model, and Rubrik Agent Cloud, which aims at reversing destructive actions an agent took. That's the entire commercial recovery market for AI as of this writing.
Figure 2. The recovery cliff. Protect carries 194 mapped products. The three functions you lean on after prevention fails, Govern, Respond, and Recover, hold 22 between them.
I want you to be careful with that 194-to-2 split, because the temptation is to treat it as a gap analysis and go shopping for the two Recover products to fill the hole. That's the wrong read. Two products isn't a shortlist. It's the market telling you that recovery mostly can't be bought, for the boundary reason above. If you buy both tools tomorrow you'll have closed a rounding error's worth of your real exposure. The number is a signal about where the work lives, and the work lives inside your own systems.
You can't buy back an action an agent already took
The reason recovery resists productization gets sharper when you look at what a modern agent does. Give a long-running autonomous agent a goal and let it work, and over an hour it sends emails, opens pull requests, writes rows to your CRM, files tickets, calls partner APIs, and moves money between ledgers. Each of those actions lands in a different system, owned by a different team, with its own data store and its own rules. There's no shared transaction boundary around the whole run. Nothing wraps all of it in a single operation you can roll back.
That's the undo problem, and it's why "just restore from backup" is a comfort object here. Say your platform vendor restores the agent's own state to where it was ninety minutes ago. The forty emails it already sent are still in forty inboxes. The pull request it opened is still sitting in your repo, maybe already merged. The CRM writes are still there, and the downstream automations already fired on them. A platform restore rewinds the agent. It does not rewind the world the agent touched. Recovery in the agent era is a distributed-systems problem wearing a security costume, and no single product can own it because no single product owns all the systems the agent reached.
You watched a live version of this in the July 2026 OpenAI / Hugging Face incident. OpenAI's models broke out of an evaluation sandbox, reached Hugging Face's infrastructure, and chained stolen credentials with a zero-day into remote code execution, with no human directing any of it and no malicious intent in the chain. Hugging Face detected and contained the activity, but containment isn't undo: they still had to run forensic reconstruction across every system the agents touched, and they had already filed a report with local police before anyone knew the attacker was a model trying to pass a test.
Govern and Respond are thin for the same structural reason
Recovery gets the headline because two is a shocking number, but the same boundary logic hollows out two more columns your board cares about.
Respond has about nine products, and four of them (Astrix, Clutch, Permiso, and Vorlon) are really aimed at one narrow slice: the identities that AI agents use to authenticate and act. That's a real and growing problem, so it's good those exist. But nine products across an entire Respond function tells you that containing an AI incident in progress is still mostly something your own runbooks and your own architecture have to do, not something you procure.
Govern is emptier still, and here the emptiness is honest rather than alarming. Most of the Govern cells aren't product categories at all. They're policy and standards decisions: what you allow agents to do, which data classes they may touch, who signs off on a new model going live. A handful of vendors will document and track your governance posture (Credo AI, OneTrust, Cranium, Holistic AI, and LatticeFlow all live in that column), but they document the decisions. They don't make them. You can't outsource the judgment about your own risk tolerance to a dashboard, and the market isn't pretending otherwise.
On where the standards are headed: NIST has had a preliminary draft of IR 8596, the Cyber AI Profile, out since December 2025. It's early and still a draft, so don't build a compliance program around it yet. It's the signal that the governance column will firm up from the standards side before it fills up from the vendor side, which is the right order for it to happen.
Your board is going to ask about recovery, so answer before they do
Consider the position you're in as the operator without a CISO or a dedicated AI leader. You're the person who fields the board's AI questions, and the questions get more specific every quarter. Last year it was "are we using AI safely." This year it's "what happens when the agent gets it wrong." You want to walk into that meeting having already asked yourself the hard version.
The board question that exposes the recovery gap isn't "do we have AI security tools." Every company can say yes to that now. The question that matters is this: for each thing our agents can do, what's our path to undo it, and how long does that path take? Ask that about your own environment and you'll find the honest answer is uneven. Some actions are cleanly reversible because the underlying system supports it. A lot aren't. The ones that aren't are your real exposure, and no line item in your security budget is currently pointed at them.
This is where I'd redirect your vendor conversations. The reflex is to treat AI security as procurement: find the tool, buy the tool, check the box. The recovery gap doesn't yield to that, because the tool doesn't exist. So the conversation has to move from buying to building. The frame I use with operators is CARE, which stands for Create, Adapt, Run, and Evolve. You Create the recovery capability your systems don't have yet, like a reversal path for an agent action or an approval gate before an irreversible step. You Adapt what vendors do sell to your specific architecture instead of expecting it to fit off the shelf. You Run it as a real operational function with owners and drills, not a dashboard nobody watches. You Evolve it as your agents take on more. CARE turns the vendor meeting from "what can I buy" into "what do we have to build, and which small piece can this vendor honestly help with." That's a harder conversation, and it's the one that matches the actual shape of the problem.
So do one concrete thing before your next board meeting, and it costs you a spreadsheet and an afternoon, not a purchase order. List the ten actions your agents can take that would hurt most if they went wrong: the money movement, the customer-facing sends, the production code changes, the data deletions. For each one, write down the real undo path and how long it takes. Where the cell comes back blank, you've found a piece of your AI security recovery gap in your own words, ready to hand to whoever owns that system. If you want the structured version of that exercise, with the questions to ask each system owner, I put it in the Recover Readiness Audit.
Run that inventory and the 194-to-2 split stops being someone else's statistic. It becomes a map of the work only you can authorize, in the order that hurts most first.
If you'd rather not run it alone, building this with your team from the virtual-CISO or fractional Chief AI Officer seat is a good part of what I do.