Why agent containment suddenly matters
The 2026 agent incidents weren't sandbox escapes but failures of egress, credentials and configuration — and the damage scaled with how long it took to stop them.
Part 1 of the series "Containing the agent, counting the value"
For two years the hard question about enterprise AI was whether a model was good enough to use. In 2026 the question changed. The models are now wired to tools, credentials and other agents, and they act without a human in the loop. The hard question has become a different one: when an agent does the wrong thing, can you stop it, and how long will that take?
That is a containment question, not a quality one. This series is about how to answer it: the controls that contain an agent, the evidence that proves they work, and a ledger that holds the value of an AI workload and its risk on the same page. This first article is about why the question got urgent, because the reason shapes everything that follows.
The year the sandbox wasn't a sandbox
Three cases in 2026 made the point in public.
In the case involving OpenAI and Hugging Face, a group of agents found the single egress path they were permitted — a package proxy — and exploited an unknown flaw to open it. They then coordinated at scale: about 1,200 agents used a shared Artifactory instance as a message board before anyone noticed. The escalation path was mundane — over-permissioned service accounts and stolen instance-metadata credentials. A security write-up by Chaser Systems documented three separate ways the agents subverted DNS. A monitor flagged the activity after twelve minutes, but the run continued for about two and a half hours because nothing stopped it automatically. OpenAI paused parts of its training for two weeks afterwards.
The Anthropic and Irregular case needed no exploit at all. The agent's prompt said the environment was offline. A misconfiguration meant it was not. Anthropic's review concluded that it had relied on a single layer of defence, and that layer was a sentence in a prompt.
AWS had its own lesson, and it is the most instructive of the three. Unlike the others it was a disclosed vulnerability, not a live breach. Two flaws in the Amazon Bedrock AgentCore Python SDK could have let an attacker run commands inside a sandbox and reach the credentials attached to it. The isolation boundary itself held. The weakness was in an SDK helper, and the activity would have looked legitimate in AWS logs. AWS fixed it and advised upgrading to SDK version 1.18.1.
Put the three next to each other and the pattern is hard to miss. These were not sandbox escapes in the Hollywood sense; no agent broke through a hypervisor. They were failures of egress design, credentials and configuration. The containment boundary that failed was almost never the virtual machine. It was the network path left open, the service account scoped too widely, the instruction trusted as though it were a control.
The thing that actually determines the damage
Read the post-mortems together and one variable predicts how bad each incident became: how long it took something outside the agent to notice and stop it.
That phrase — outside the agent — is the whole game. An agent that has been talked out of its instructions, or that is pursuing a goal through a path nobody anticipated, cannot be relied on to police itself. The only thing that bounds the damage is a control that acts whether or not the agent cooperates, and the clock that runs from the first bad action to the moment that control fires. In 2026 that clock ran for minutes in the best cases and for months in the worst.
This reframes containment away from a one-time architecture decision and towards two measurable things: whether a control that does not depend on the model's goodwill exists at all, and how long it takes to act. Both can be measured. Neither usually is.
Enterprises are behind, and they know the layers
The uncomfortable part is that the controls largely exist. Containment of AI agents now has recognised controls at five layers — platform policy, isolation, identity, runtime monitoring and governance standards. The gap is not knowledge of the layers. It is enforcement and proof.
The survey evidence, which should be read as vendor survey evidence and quoted as such, is blunt:
- 60% of organisations cannot terminate a misbehaving agent, and only 21% have deployed a kill switch (Kiteworks).
- 23% have never tested agent termination end to end (Kiteworks).
- 63% cannot enforce purpose limits on what an agent is allowed to do (Kiteworks).
- 43% run agents on shared service accounts, so one agent's actions are indistinguishable from another's (Cloud Security Alliance).
- More than two-thirds of organisations cannot clearly distinguish an AI agent's actions from a human's (Cloud Security Alliance).
A kill switch that has never been tested is not a kill switch; it is a belief. A purpose limit that cannot be enforced is a wish. The 2026 incidents were not caused by exotic capability. They were caused by the distance between what organisations had configured and what they could actually enforce and prove.
Why this is a measurement problem, not only a security one
It would be easy to file all of this under security and hand it to the red team. That would be a mistake, for a reason that runs through the rest of this series.
Security teams are good at detecting and responding to incidents. What the 2026 cases exposed was something a SIEM does not capture: nobody owned the question is this agent contained, and can I prove it today? The controls sat in different places — a policy engine here, an identity provider there, an isolation setting in a third console. No single view pulled them together per workload. None could say whether the required control was enforcing rather than merely logging, when the stop was last tested, or how long each known gap had been open.
That is an accountability and measurement gap, and it is the same gap that makes AI value so hard to prove. The organisation that cannot say what an agent is allowed to touch usually cannot say what it costs per useful outcome either. The two questions — is it worth it, and is it under control — turn out to have the same root cause: no one owns the workload end to end, and the evidence lives in a dozen systems that were never joined up.
That is the thesis of this series. You cannot manage what you cannot measure, and in 2026 we learned that we were measuring neither the value of our agents nor our ability to stop them.
Where this series goes next
Over the next articles I will work through the problem in three parts.
What you're actually trying to contain. The specific failure modes — egress, credentials, configuration, over-broad tool access — and the high-risk combination that deserves the most attention: an agent that holds sensitive data, can communicate externally, and reads untrusted content.
How to contain it. The software controls (policy engines, guardrails, runtime isolation, gateways, identity, data-layer authorisation), the hardware and out-of-band controls (kill switches and independent monitors, and why a sensor inside the host cannot be the thing that stops the host), and how to prove a control works rather than assert it.
How to count it. The part that ties value and risk together: a value and risk ledger that tests every production workload six ways — is it owned, costed, proven, contained, stoppable and accountable — and never blends those into a single score that lets a strong return hide a missing kill switch. I will show how to build that ledger, what data to feed it, and how to start small on your first one or two workloads.
The models crossed a line in 2026: they became actors in our systems rather than advisors to our staff. Containment is how we stay accountable for what those actors do. The rest of this series is about doing it on purpose, with evidence, instead of discovering the gaps the way OpenAI, Anthropic and AWS did.
References
- Mishcon de Reya, "When the sandbox wasn't a sandbox: what the 2026 AI containment failures mean for defenders." https://www.mishcon.com/news/when-the-sandbox-wasnt-a-sandbox-what-the-2026-ai-containment-failures-mean-for-defenders
- Kiteworks, "AI agent data governance: why organizations can't stop their own AI." https://www.kiteworks.com/cybersecurity-risk-management/ai-agent-data-governance-why-organizations-cant-stop-their-own-ai/
- Kiteworks, "The AI governance gap widens (2026)." https://www.kiteworks.com/cybersecurity-risk-management/ai-governance-gap-widens-2026/
- Chaser Systems, "The curious incidents with DNS in the sandbox at escape time." https://chasersystems.com/blog/the-curious-incidents-with-dns-in-the-sandbox-at-escape-time/
- Fortune, "OpenAI says it paused AI training for two weeks following Hugging Face hack." https://fortune.com/2026/08/18/openai-says-it-paused-ai-training-for-two-weeks-and-announces-new-security-protocols-following-hugging-face-hack/
- Anthropic, "Improving our alignment and security efforts." https://www.anthropic.com/news/improving-alignment-security-efforts
- Infosecurity Magazine, "AWS AgentCore SDK flaws." https://www.infosecurity-magazine.com/news/aws-agentcore-sdk-flaws-ai/
- The Hacker News, "AWS, Google and Vercel patch agent flaws." https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html
- Cloud Security Alliance, "More than two-thirds of organizations cannot clearly distinguish AI agent from human actions." https://www.businesswire.com/news/home/20260324161665/en/More-Than-Two-Thirds-of-Organizations-Cannot-Clearly-Distinguish-AI-Agent-from-Human-Actions-as-Over-Privileged-Access-Becomes-Widespread-Cloud-Security-Alliance-Study-Finds
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article