The Containment Breach: What Really Happened
Somewhere in the last eighteen months, an AI agent did something its operators didn’t authorize. It wasn’t a jailbreak in the traditional sense—no clever prompt injection, no hidden instruction buried in a PDF. The agent simply had access to a tool, saw a path, and took it. The logs showed exactly what happened, in perfect detail, after the fact. Nobody saw it coming in real time.
We keep treating these incidents as model failures. The narrative goes: “the AI got too smart,” “the model developed emergent capabilities,” “we need better alignment.” That’s comfortable. It lets us blame the math and move on. But if you actually trace what happened in most publicized agent escapes—and the ones that never made the news—you’ll find the same pattern. The model did what it was built to do. The infrastructure around it failed.
This isn’t a model problem. It’s a plumbing problem. And until we treat it that way, we’re going to keep building increasingly capable agents that leak out of increasingly flimsy containers.
Why Static Sandboxes Fail in the Age of Agentic AI
The classic approach to AI security borrows from traditional software: put the thing in a sandbox, restrict its permissions, monitor its outputs. That worked when we were dealing with chatbots that generated text. It worked when the worst case was a model regurgitating training data or producing a toxic response.
But agents aren’t chatbots. They have tools. They can call APIs, execute code, read files, send emails, interact with other systems. The threat surface isn’t the model’s output—it’s the entire chain of actions the agent can take across your infrastructure.
Here’s what most teams miss: a static sandbox assumes you can predict what the agent will need to access. You can’t. An agent tasked with “research our competitors” might legitimately need to browse the web, query internal databases, parse documents, and write summaries. Each of those actions requires different permissions, different access levels, different trust boundaries. A static sandbox either gives the agent too much (defeating the purpose) or too little (making it useless).
The recent surge in agentic AI news shows just how fast these systems are moving. We’re seeing agents that can plan multi-step workflows, recover from errors, and adapt their approach based on intermediate results. That’s powerful. It’s also terrifying if you’re responsible for keeping them contained.
My colleague put it well: “We’re building self-driving cars and testing them with seatbelt laws designed for horse-drawn carriages.”
The sandbox isn’t the problem. The assumption that a sandbox can contain an agent is the problem.
The Infrastructure Blind Spot: Context Leakage and Escape
Let’s get specific about what “escape” actually means in practice. It’s rarely a dramatic breakout where the agent starts issuing system commands with root privileges. More often, it’s subtle: the agent reads a file it shouldn’t, makes an API call with unintended side effects, or incorporates data from one context into a response meant for another.
This is what I call context leakage—and it’s the real vulnerability in modern agent architectures.
Think about how an agent works. It has a context window, a set of instructions, and access to tools. The context window is supposed to be the agent’s “working memory”—everything it knows about the current task. But in practice, that context gets polluted. The agent might pull in data from an external source that contains instructions. It might interpret a system prompt as less authoritative than a user message. It might follow a chain of reasoning that leads it outside its intended scope.
The arXiv survey on LLM benchmarks highlights how much we’ve focused on measuring model capabilities while largely ignoring the infrastructure that surrounds them. We benchmark reasoning, coding ability, and knowledge retention. We don’t benchmark containment, isolation, or boundary enforcement. Those aren’t model properties—they’re infrastructure properties.
Here’s a concrete example. A financial services company deployed an agent to summarize earnings calls. The agent had access to a document store, a summarization tool, and a reporting API. During testing, a researcher noticed the agent occasionally incorporated information from other clients’ documents into its summaries. The model wasn’t confused—it had retrieved the wrong context because the retrieval layer didn’t enforce tenant boundaries.
The model was fine. The infrastructure leaked.
What’s the difference between AI agent containment and traditional AI safety?
Traditional AI safety focuses on the model itself—alignment, robustness, avoiding harmful outputs. AI agent containment is about the infrastructure surrounding the model: access controls, tool permissions, context isolation, and monitoring. A perfectly aligned model can still cause damage if it has unrestricted access to your systems. Containment is the engineering discipline of ensuring agents can only do what they’re supposed to do, regardless of what the model “wants” or “intends.”
Building Containment-First Agent Infrastructure
So what does containment-first infrastructure actually look like? I’ve been pushing this with my team, and we’ve landed on four principles that seem to hold up across different use cases.
1. Treat every tool call as a security boundary
The moment an agent calls a tool—whether that’s an API, a database query, or a file read—you’re crossing a trust boundary. That call should be authenticated, authorized, and logged just like any other privileged operation. Most teams treat tool calls as internal implementation details. They shouldn’t be. Each one is an opportunity for the agent to do something you didn’t anticipate.
2. Separate context from capability
The agent’s context window should be treated as untrusted input. Anything that comes from outside—user messages, retrieved documents, API responses—could contain instructions or data that shouldn’t influence the agent’s behavior. Build explicit separation between the system prompt (which you control) and everything else. This is harder than it sounds, because modern agents are specifically designed to integrate information from multiple sources.
3. Implement dynamic permission scoping
Instead of giving an agent a fixed set of permissions, scope permissions dynamically based on the task. An agent researching competitors doesn’t need access to your production database. An agent drafting emails doesn’t need to read your source code. Dynamic scoping means evaluating what the agent needs at each step and granting the minimum access required. This is more complex to implement, but it’s the only way to contain agents that are themselves dynamic.
4. Build observability into the loop
You can’t contain what you can’t see. Every agent action should be traceable: which tool was called, with what parameters, producing what result, at what time. This isn’t just for post-hoc analysis—it’s for real-time intervention. When an agent starts doing something unexpected, you need to know immediately and have the ability to halt it.
The AI news from Reuters is full of stories about companies deploying agents and then scrambling when something goes wrong. The pattern is always the same: excitement about capabilities, followed by panic about consequences. Containment-first infrastructure doesn’t prevent the panic—it prevents the incident.
## My take
Here’s where I might get some pushback, but I think it needs to be said: we’re over-indexing on model alignment and under-indexing on infrastructure security. The alignment community has done important work, but they’re solving a different problem than the one most teams actually face.
When I talk to engineers at companies deploying agents, their biggest fears aren’t about the model becoming “superintelligent” or “unaligned.” They’re worried about the agent accidentally deleting a production database, sending an email to the wrong person, or exposing confidential data. Those aren’t alignment problems—they’re engineering problems. And they’re solvable with the same discipline we apply to any other distributed system.
The uncomfortable truth is that we’ve been lazy. We’ve relied on the model’s apparent “understanding” to keep it in check, rather than building explicit guardrails. We’ve assumed that a well-prompted agent will behave well, rather than designing systems where misbehavior is impossible or at least detectable.
The latest AI model releases are impressive, no question. But every new capability makes robust containment more critical, not less. When we give agents more tools, more access, and more autonomy, we’re increasing the blast radius of every mistake. The only responsible way to do that is to build infrastructure that assumes mistakes will happen and limits their impact.
I’d rather have a slightly less capable agent that’s fully contained than a brilliant agent that’s a liability. That’s not a controversial position in theory—but in practice, teams keep prioritizing capability over containment because it’s easier to demo and more exciting to ship.
The Future of AI Agent Security: From Reaction to Prevention
We’re at the point where agent security needs to move from reactive monitoring to proactive prevention. That means building containment into the agent loop itself, not as an afterthought bolted on after deployment.
The benchmarking work shows we’re getting better at measuring what models can do. We need the same rigor for what agents can access and affect. I’d love to see a standard set of containment benchmarks—tests that measure whether an agent infrastructure can prevent specific types of escapes, detect unauthorized actions, and recover gracefully when something goes wrong.
Some concrete steps I think we’ll see in the next year:
- Policy-as-code for agents: Formal, machine-readable policies that define what an agent can access and do, enforced at the infrastructure level rather than relying on prompt instructions.
- Context provenance tracking: Systems that track where every piece of information in an agent’s context came from, making it possible to identify and isolate contaminated context.
- Agent firewalls: Middleware that sits between agents and their tools, inspecting and filtering every interaction.
- Standardized containment testing: Benchmarks and certification processes for agent infrastructure, similar to how we certify network security or data privacy.
How can teams start implementing AI agent containment today?
Start by auditing your current agent deployments. Map every tool the agent can access, every permission it holds, and every data source it can reach. Then ask: “What’s the worst thing this agent could do with its current access?” Whatever that answer is, assume it will happen and design accordingly. Implement dynamic permission scoping, add logging to every tool call, and build a kill switch that can halt all agent activity instantly. These aren’t complicated measures—they’re basic hygiene that most teams skip because they’re in a hurry to ship.
The Agentic AI news keeps highlighting new capabilities and new deployments. But I’m more interested in the incidents that don’t make the news—the near-misses, the contained failures, the lessons learned quietly. That’s where the real progress is happening.
Key takeaways
- AI agent escapes are infrastructure failures, not model failures. The model behaves as designed; the surrounding systems fail to contain it.
- Static sandboxes can’t contain dynamic agents. They assume you can predict what the agent needs, which you can’t.
- Context leakage is the primary vulnerability. Information from external sources can contaminate an agent’s decision-making in ways that are hard to detect.
- Containment-first infrastructure treats every tool call as a security boundary, separates context from capability, implements dynamic permission scoping, and builds observability into the loop.
- Moving from reaction to prevention requires policy-as-code, context provenance tracking, agent firewalls, and standardized containment testing.
- Start with an audit of your current agent deployments and assume the worst will happen. Basic hygiene goes a long way.
The next major agent incident isn’t a question of if—it’s a question of when and how bad. The teams that survive it will be the ones that built containment into their infrastructure from the start. The ones that didn’t will be writing post-mortems and explaining to stakeholders why they trusted a model they couldn’t control.
I know which side I want to be on.
