88% of Companies Running AI Agents Had a Security Incident. Ask the Blast Radius Question First.

There is a survey number going around that I keep coming back to: among enterprises with agents deployed, 88% reported a confirmed or suspected security incident tied to those agents in the past year. OWASP's 2026 reporting puts prompt injection as the fastest-growing category of attack, up several hundred percent year over year, and roughly a third of deployed agents have been hit with at least an attempt.

The number that should worry a board is not 88%. It is that most of the organisations in that 88% were fine, and a small number were not, and the difference between them was decided months before the incident.

Prompt injection is a permissions problem wearing a language costume

The instinct, when a team first understands prompt injection, is to fix the prompt. Add instructions telling the model to ignore instructions found in data. Add a classifier that looks for suspicious text. Add a second model to check the first.

All of that helps a bit and none of it is a boundary. The reason is structural: a language model reads its instructions and its data through the same channel. There is no privileged position in the context window that data cannot occupy. Every defence at that layer is a filter with a bypass rate, and attackers are patient about bypass rates.

So the useful question is not how to make injection impossible. It is what happens when it works.

That reframing changes the whole engineering effort. Instead of an arms race over wording, you get a finite design task: enumerate what the agent can do, decide which of those actions you are willing to have happen without a human, and make the rest impossible rather than discouraged.

I have seen this land with executives faster than any technical explanation, because it is a familiar shape. You do not secure a warehouse by asking everyone nicely not to steal. You control what the doors open onto.

The two root causes

Sorting the incidents that get written up, and the ones I have been called in after, they come down to two things with tedious consistency.

The agent had more access than the job required. Somebody wired it to a broad integration credential during the pilot because that was the credential available, and nobody went back. The agent's designed purpose used 5% of that access. The incident used the other 95%.

The agent acted on data nobody had thought of as input. A support agent reads a ticket, and the ticket body is attacker-controlled. A procurement agent reads a supplier's PDF. A research agent browses a page. A coding agent reads a repository issue. In each case the team had a mental model where the "input" was the user's request, and the actual attack surface was every byte of text the agent ingested along the way.

The March 2026 case that circulated, a customer-facing agent at a financial services firm leaking internal pricing data for three weeks after a carefully worded question, is both causes at once. It could reach data it did not need, and someone put words in front of it.

Three weeks is the detail I would sit with. Not the leak. The three weeks. Nobody noticed, because nothing crashed.

The blast radius questions

This is the exercise I run with clients, and it takes about ninety minutes per agent. It is not a threat model in the formal sense. It is a list.

What can this agent read? Not what does it read. What can it. Everything the credential reaches, including things nobody remembered were behind that credential.

What can it write, modify, or delete? Split this from reads deliberately, because the risk profiles are not comparable and lumping them together hides the important half.

What can it send outward? Email, chat messages, webhooks, API calls to third parties, and anything that puts data in front of a person outside the company. Exfiltration paths are often the ones nobody counted, because they were built as convenience features.

What can it spend? Payments, obviously, but also anything with a cost per action: model calls, third-party API charges, cloud resource provisioning.

What can it trigger downstream? If it can file a ticket that another automation acts on, its real reach includes that automation's reach. Agent chains multiply blast radius quietly, because each hop looks small on its own.

Then the question that matters. If an attacker had complete control of this agent's next twenty actions, what is the worst outcome? Write it as a sentence a board member would understand. "It could email our full customer list to an external address." "It could issue unlimited refunds." "It could delete the production dataset."

If that sentence is unacceptable, the agent's permissions are wrong, and no amount of prompt hardening fixes it. If the sentence is "it could give a customer a slightly wrong answer about shipping times", you can relax and ship.

Containment beats detection

Detection matters and I am not arguing against it. But detection is a race and containment is arithmetic, and I would rather bet on arithmetic.

Some specific patterns that hold up.

Split the agent by trust level. An agent that reads untrusted external content should not be the same agent that holds write credentials to internal systems. Have the untrusted reader produce a structured summary, and have a separate, more constrained component act on it. The injection lands in a process that cannot do anything interesting.

Put hard limits on the actions that matter, in code rather than in prompts. A per-transaction cap, a daily total, a maximum number of records touched per run, an allowlist of email domains. These are not clever and they are not bypassable by argument, which is the entire point.

Require human approval on the irreversible. The instinct is to resist this because it dilutes the automation story. In practice it rarely costs much, because the irreversible actions are a small fraction of the volume in most workflows. An agent that handles 94% of cases autonomously and asks about the 6% that involve money leaving the building is a good product, not a compromised one.

Make egress explicit. Default-deny on outbound network access from anything running agent-generated code or agent-directed tool calls, with an allowlist. A remarkable share of the ugly incidents involve an agent reaching somewhere nobody expected it could reach.

Log at the step level, and alert on shape rather than content. You will not catch the injection by pattern matching the text. You may well catch the consequence: a support agent that reads two thousand records in four minutes, an agent that suddenly starts calling a tool it has never used, a run that is thirty steps longer than the median. Those are cheap alerts and they are how the three-week leaks get caught in three hours.

What this looks like in the budget

I get asked whether this is a lot of work. Honest answer: it is a week or two of design per agent if you do it before building, and a quarter of rework if you do it after. That asymmetry is the whole argument.

The cost of not doing it is harder to state precisely, and the figures floating around for average agent breach cost, somewhere near the $4.7 million mark, are the kind of number I would not lean on too hard in a board paper because the sample behind them is thin. The argument that lands better is the specific one from your own blast radius exercise: here is the sentence describing what our worst agent could do, here is what it would cost us if it happened, here is the two weeks of work that makes that sentence untrue.

That framing also has the advantage of being honest. Security spending justified by industry averages gets cut. Security spending justified by "our refund agent currently has no upper limit" does not.

The thing that actually goes wrong in organisations

One last observation, because it is the pattern underneath most of the incidents I have watched.

The security review happens at the end. The team builds for four months, gets it working, and then submits it for review, at which point the reviewer finds that the agent runs on a shared credential with broad access and cannot produce a per-action audit trail. Now there is a fight, because the build is done and the deadline is real and the fix is architectural.

Everyone involved behaves reasonably and the outcome is bad. The team was not told to think about it earlier. The reviewer cannot approve something they would be blamed for.

Moving the blast radius conversation to week one costs almost nothing and removes the fight entirely. It also, in my experience, makes the agent better, because deciding precisely what it may do forces precision about what it is for. Vague agents are both less safe and less useful, and the same exercise fixes both.

Where to start tomorrow

Pick the agent with the most write access, not the one with the most traffic. Run the blast radius questions on it. Write the worst-case sentence.

If the sentence scares you, scope the credential down this week and put a hard limit on the irreversible actions. That is usually a couple of days of work and it removes the majority of the tail risk.

Then do the same exercise on everything else, in order of write access. And put it in the design checklist for the next agent, so the backlog stops growing while you work through it.

Agents are not unusually dangerous. They are usually over-permissioned, which is a different problem with a known fix.

We do this exercise with clients regularly, sometimes as a standalone review and sometimes as the first week of a build. If you have agents in production and cannot currently write the worst-case sentence for them, we should talk.