Blast radius is what an injected agent can still cause after every filter has failed. It is a property of your deployment, not of the attack: the same payload against an agent with a read-only token and against an agent with an administrative one produces two different incidents. Prevention is not fully available, on the word of the standard that ranks the risk first. Containment is, and it is measurable in advance.
Why make containment the objective?
Because the alternative has been ruled out in print by the people best placed to rule it in.
- OWASP, in LLM01: "it is unclear if there are fool-proof methods of prevention for prompt injection" (OWASP).
- The UK NCSC: prompt injection "may never be totally mitigated in the way SQL injection attacks can be", and the recommendation is "reducing the risk and impact of prompt injection" (NCSC).
- Meta, stating the design premise before its own rule: prompt injection is "a fundamental, unsolved weakness in all LLMs" (Meta).
The research direction that produced the strongest results agrees. CaMeL's claim is that a protective layer around the model "secures it even when underlying models are susceptible to attacks", by enforcing policy when tools are called (arXiv 2503.18813). The model stays fallible on purpose. The system does not.
How do you measure blast radius before an incident?
Inventory the agent's reach. Six columns, one row per tool the agent can call.
| Column | What to write down |
|---|---|
| Action | The tool or API call, by name |
| Target class | Which systems and which records it can touch |
| Credential | Whose authority it runs on, and where that credential lives |
| Reversible | Yes, or no, or only within a window |
| Bound | How many times per hour, per target, before it stops |
| Notice | Who finds out, and how soon |
Two answers on that sheet are findings on their own. A credential that lives in the agent's environment means the agent's authority is standing authority, and an injection inherits it. A blank in the Reversible column means nobody has decided, which in an incident review reads as an assumption that it was fine.
Which reductions actually shrink it?
Ordered by how much they remove, not by how easy they are.
- Take the credential out of the agent. An agent that cannot authenticate cannot act, however thoroughly it was persuaded. This is the only reduction that is unaffected by how convincing the injected text was.
- Cut a leg of the trifecta. Private data, untrusted content, external communication: remove one and the exfiltration path closes (Willison). Read-only credentials are the cheapest version.
- Shrink the toolset. OWASP LLM06 names excessive functionality and excessive permissions as root causes, and the mitigation is to remove them rather than to watch them (OWASP LLM06).
- Bound the rate. A per-hour and per-target-class ceiling turns a mass action into a handful before something stops.
- Require a signature on what cannot be undone. The one control whose effect does not depend on having recognised the attack.
- Make the record external. OWASP names T8, Repudiation and Untraceability. A record the acting system can rewrite does not survive a dispute (OWASP).
Note what is not on this list: a better classifier. Detection reduces how often you are here. It does not change what happens when you are.
What does contained look like on paper?
Three questions, answerable in writing before the rollout, and again after any incident.
- What could the agent have done? The set of actions reachable with its standing authority at the moment of the injection. If the answer is "anything the API allows", the blast radius is the API.
- What could it not have undone? Irreversible actions taken without a named person signing them should be zero, and zero by construction rather than by luck.
- What can you show someone? Not what your system says happened, but a record a party who was not there can check for themselves. ATLAS treats tool invocation as the technique to watch (AML.T0053), so the tool-call history is the evidence that matters.
An agent that answers all three in writing is deployable while prompt injection remains unsolved. An agent that cannot answer the second one is not, whatever its filter benchmark says.
Related: prompt injection in AI agents, defences and their limits, and prompt injection in the SOC.
What is the smallest possible blast radius?
The set of actions your policy allows, and nothing beyond it. That is the layer ZIFFER is.
The agent holds no credential. It proposes; the credential that performs the action sits with an executor on your side of the line. A proposal written by a compromised agent is graded against the same signed policy as a clean one, because the risk, the reversibility and the owner of the target are recomputed from that policy rather than read from the proposal. Irreversible actions are held for a quorum of two named humans who sign the exact bytes that will run, and a hold nobody signs expires with nothing run. Every outcome, refusals included, leaves a signed receipt: the action, the policy version, the signers, the time.
ZIFFER is not a guardrail, detects no injection and prevents none. It decides whether a proposed action is entitled to run, and it leaves the answer on the record. See agent authorization, the agent audit trail and every refusal.