The security reviews we walk into usually start in the wrong place.
Someone wants to talk about the model. Is it safe, has it been red-teamed, can it be jailbroken, what does the provider say about training data. All reasonable questions, and all of them about a component that, on its own, cannot do very much. A language model with no tools and no permissions is a very expensive way to produce text. It can be wrong, it can be offensive, it can be coaxed into saying things it should not. None of that touches your systems.
The moment you give that model tools, the question changes completely. Now it can read a database, call an API, file a ticket, move a file, send a message, kick off a workflow. It is no longer producing text. It is taking actions, with real permissions, against real systems, on someone's behalf. And the security question is no longer "can the model be tricked into saying something." Every model can be tricked into saying something. The question is what happens to your enterprise when it is.
That is the question we mean by blast radius, and it is the one most AI security conversations skip.
The attack surface moved, and most controls did not move with it
For thirty years, enterprise security has been built around a clear idea: a request comes in, you authenticate who is making it, you check what they are allowed to do, and you let the action through or you do not. Identity, authorization, and an audit trail of who did what. It is not glamorous and it works.
Agentic AI breaks the comfortable part of that model, which was the assumption that the thing making the request has fixed intent. A human user wants what they want. A traditional service account does exactly what it was coded to do, every time. An agent is different. Its next action is computed at runtime from a prompt, a context window, retrieved documents, tool outputs, and the results of its own previous steps. Change any of those inputs and you change what it decides to do. Most of those inputs come from outside your trust boundary.
This is why prompt injection is not a curiosity. It is the defining vulnerability class of this architecture, and it has no clean equivalent in the systems we built before. A document the agent retrieves can contain instructions. An email it is asked to summarize can contain instructions. A web page, a support ticket, a field in a record, the output of a tool it called a moment ago, all of these are data the agent reads, and any of them can carry text that the model treats as a command. The agent cannot reliably tell the difference between the task you gave it and the instruction someone hid in the data it was told to process. There is no header that separates the two. They arrive in the same channel.
So the attacker's move is no longer to breach your perimeter. It is to leave a message where your agent will read it, and let your agent, holding your credentials and trusted by your systems, do the rest.
The old question was whether an attacker could get inside. The new question is whether your own agent, acting on poisoned input, will do the attacker's work for them using access you granted it on purpose.
Where the damage actually travels
When we map blast radius on an engagement, we are not asking whether the model can be fooled. We assume it can. We are asking, if a given agent does the worst plausible thing in the middle of its workflow, where does that go. The answer is almost always shaped by three things, and the model is not one of them.
The first is permissions. An agent inherits whatever access you gave its tools, and the default, the easy thing, the thing that makes the demo work on Friday, is to give it broad access so nothing gets in the way. A read-only agent that gets compromised leaks. A read-write agent that gets compromised changes things. An agent with a standing credential to a system of record can do, in one confused step, whatever that credential allows, and it will do it faster than any human and without the hesitation a human would feel. Most of the blast radius we find was provisioned at build time by someone trying to remove friction.
The second is reach. A single agent answering questions has a small radius. A network of agents that call each other, hand off tasks, and trigger downstream workflows has a large one, because a bad decision does not stop where it started. It propagates. Agent A's poisoned output becomes Agent B's trusted input, and B has tools A never had. The multi-agent designs that look so capable in a diagram are exactly the designs where one compromised step can travel the furthest, and the travel is invisible unless someone built the seams to be visible.
The third is reversibility. Some actions can be undone. A draft can be deleted, a flag can be cleared. Some cannot. A payment sent, a message delivered to a customer, a record purged, an external call made with real-world consequence. The blast radius of an agent is not just how many systems it can touch. It is how many things it can do that you cannot take back. An architecture that lets an agent take irreversible actions without a gate in front of them has decided, whether anyone said so out loud, that it trusts a probabilistic system to never be catastrophically wrong. Nobody would write that sentence down. Plenty of systems are built as if it were true.
Risk mitigation is a design property, not a filter you add later
The instinct, when security raises its hand, is to reach for a content filter. Scan the prompts, scan the outputs, block the bad strings, and call it governed. Input and output filtering has its place and we use it. But a filter on the language is treating a system problem as a text problem. The risk does not live in the words. It lives in what the agent is allowed to do after it reads them.
Containment is the control that actually changes the blast radius, and containment is architectural. It is decided when you draw the boundaries, not when you tune a classifier.
The principle underneath it is old and it transfers cleanly: least privilege. An agent should hold the narrowest set of permissions that lets it do its specific job, scoped to the task in front of it and no further, and ideally granted for the duration of that task rather than standing there permanently. The broad service account that can touch everything because it was easier is the single largest blast-radius multiplier we encounter, and it is almost never necessary. The agent that summarizes tickets does not need write access to the ticket system. The agent that drafts the response does not need to be the one that sends it.
The second principle is separation. The component that reads untrusted data and the component that takes consequential action should not be the same component with the same trust level. When the part of the system exposed to poisoned input is also the part holding the dangerous permissions, you have built a straight line from the attack surface to the consequence. Putting a boundary between them, so that a compromised reasoning step has to cross a checkpoint before anything irreversible happens, is the difference between an incident and a headline.
The third is the gate on the irreversible. For the narrow set of actions that cannot be undone or carry real external weight, autonomy is the wrong default. Those actions get a human in the loop, or a second independent check, or a hard policy boundary the agent cannot argue its way past, no matter how confidently its reasoning trace explains why it should. We have written before that agentic AI needs a hand on the wheel. This is the part of the wheel that matters most: not the routine decisions, which can run free, but the small number that are expensive to get wrong.
For any agent you are about to put into production, ask one question: if this agent does the single worst thing its tools physically allow, while behaving exactly as designed, what is the damage and can we undo it? If the honest answer is "we are not sure" or "we could not undo it," you do not have a security gap waiting in some future incident. You have one now, in the architecture, waiting for an input it has not seen yet.
Governance is the part that survives the demo
Security controls that live only in the heads of the team that built the system do not survive contact with scale. The pilot is secure because three careful people are watching it. The forty-first workflow, built by a different team under deadline, is secure only if security is something the platform enforces rather than something each team is trusted to remember.
This is where security and governance stop being two conversations. The same boundary that contains an attacker also produces the record an auditor needs. An architecture that scopes permissions per task is also an architecture that can tell you, after the fact, exactly what each agent was allowed to do and when. A system that gates irreversible actions is also a system that logged who approved them. The audit trail is not a separate feature bolted on for the regulators. It is what falls out of a system that was built to contain its own agents in the first place.
When that record exists, the questions that used to end a deployment become answerable. What did this agent have access to. What did it actually do. What was it prevented from doing, and why. Who signed off on the action that mattered. An enterprise that can answer those, in something close to real time and across the whole portfolio rather than one system at a time, has security and governance as the same fabric. An enterprise that has to launch a forensics project to reconstruct what an agent did last Tuesday has neither, no matter how good the filter on the prompt was.
Why we keep designing from the blast radius in
Because the thing about a probabilistic system is that it will, eventually, be wrong in a way nobody anticipated. That is not pessimism. It is the operating assumption that lets you build something that survives being wrong.
You cannot guarantee a model is never fooled. You cannot enumerate every prompt injection in advance, because the input space is the entire open world of text the agent might read. So the security target is not a model that cannot be tricked, which does not exist. The target is a system where being tricked is contained, where the worst input produces a bounded, reversible, fully logged outcome instead of an unbounded one. You design for the failure you cannot prevent, so that the failure you cannot prevent is survivable.
We do not publish the internals of how we draw those boundaries, and this is no exception. But the discipline is not a secret. Assume the model can be compromised. Give every agent the least it needs and nothing standing. Separate the part that reads the world from the part that can act on it. Gate the things you cannot take back. Make all of it produce a record by default. Do that, and a compromised agent is an incident you contain on a Tuesday afternoon. Skip it, and the same compromise is the post-mortem you read about someone else.
The model is the part everyone wants to talk about in the security review. The blast radius is the part that decides how the review actually ends.
MTekLabs is a boutique AI firm that designs, deploys, and governs reusable agentic AI services for government and commercial enterprises. We build platforms that are auditable by design and human-in-the-decision-loop where it matters.
Not sure how far your agents can reach?
We would be glad to walk through the blast radius of your current AI deployments, and what it would take to contain it by design.