What you're actually trying to contain
The real threat isn't a model escaping a VM but legitimate capability used through unplanned paths: four failure modes, autonomy stages and the high-risk trifecta.
Part 2 of the series "Containing the agent, counting the value"
The first article argued that containment became urgent in 2026 because agents stopped advising and started acting, and because the damage from a misbehaving agent scaled with how long something outside it took to stop it. This article answers the next question: contain it from what, exactly? Get this wrong and you buy expensive defences against the wrong threat. The 2026 incidents are a map of where agents actually break, and it is not where most people were looking.
It was never the hypervisor
The mental image of a "rogue AI" is a model clawing its way out of its sandbox. That is not what happened in 2026, and it is not what you are mainly defending against.
Article 1 showed where the 2026 incidents actually broke: not the hypervisor, but egress, credentials and configuration. That is the starting point here. A security analysis of those incidents put the lesson plainly — an agent with legitimate credentials does not look like malware, and the recommended response was default-deny egress with an alert on every blocked attempt.
So the first thing you are containing is not escape. It is legitimate capability used wrongly: the network call the agent was allowed to make, to a destination nobody thought to deny; the credential it was handed, used for an action nobody intended; the tool it holds, invoked in a sequence nobody tested. This is why a sentence in a system prompt is not a control. The agent is not breaking rules at the infrastructure level. It is following its instructions through a path you did not anticipate, using access you granted.
The four things that actually go wrong
Underneath the incidents sit four recurring failure modes. They are worth naming because each maps to a different control later in this series.
Egress. The agent sends data or reaches a service it should not. One permitted path — a package proxy, a DNS resolver, an outbound webhook — becomes the whole attack surface. Containing egress means default-deny on the network, not just on the prompt.
Credentials and identity. The agent acts with more privilege than its task needs, or with privilege that cannot be told apart from a human's or another agent's — the shared-service-account problem from article 1. If you cannot attribute an action, you cannot stop the thing that caused it.
Configuration. The gap between what was declared and what was true. The offline environment that was online. The policy left in log-only mode. The tool scope that was never tightened after testing. Most containment failures are configuration failures wearing another costume.
Over-broad tool access. The agent can call tools, and chain them, in ways nobody enumerated. OWASP's agentic risk list calls this tool misuse; MITRE's ATLAS now documents invoking an agent's own mutative tools to destroy data. A frequently cited example is an agent with production write access and no confirmation step that deleted a production table.
None of these requires the model to be malicious or super-capable. They require it to be capable enough and connected, which every production agent now is.
Risk rises with autonomy, in steps you can name
Not every agent needs the same containment, and the variable that matters most is how much the agent is allowed to do. It helps to think in four autonomy stages, each inheriting the controls of the one below:
- Answers questions. A model responding from its own knowledge. The containment surface is small.
- Connects to enterprise data. It retrieves. Now data-layer authorisation and output filtering matter: can it read records this user should not see?
- Acts autonomously. It writes, calls mutative tools, changes state. Now egress, credentials and a tested stop matter, because actions have consequences that outlive the session.
- Operates as an ecosystem. It delegates to other agents. Now one agent's privilege can become another's, and coordination between agents becomes an attack surface in its own right.
The practical point is that an agent's stage should be observed, not just declared. A workload registered as "answers questions" that starts issuing write calls has moved to stage 3 without anyone deciding it should. That drift — observed autonomy exceeding declared autonomy — is one of the most useful early-warning signals you can measure, and later in this series it becomes a line in the ledger.
The combination that deserves the most fear
One pattern turns a manageable agent into a dangerous one. It is the combination of three properties in a single agent:
- it holds or can reach sensitive data;
- it can communicate externally; and
- it is exposed to untrusted content — web pages, inbound email, uploaded files, third-party documents.
Any one of these alone is normal. Together they are the high-risk trifecta, and they are dangerous because untrusted content can carry instructions. An agent that reads an attacker-controlled web page, holds sensitive data, and can send outbound traffic has everything required to be turned against you: the payload arrives in content it was told to read, and the exfiltration path is a tool it was given. No infrastructure is breached. The agent does exactly what it can do.
The design response is not to add another monitor. It is to break the combination — to ensure no single agent holds all three at once. A quarantined reader agent that handles untrusted content but has no outbound tools and no access to sensitive stores is a design break. This is why the trifecta belongs in the register as a first-class property of every agent, derived from the tools the agent actually holds rather than trusted from a declaration — because the declaration is usually optimistic.
A working map of the risks
You do not have to invent the taxonomy. The OWASP Top 10 for Agentic Applications, published at the end of 2025, is the working risk map, and its core containment risks line up with the failure modes above: tool misuse, identity and privilege abuse, cascading failures across agents, and rogue agents. MITRE's ATLAS covers agent tool abuse as a documented technique. The CISA-led guidance sorts agentic risk into five categories. These exist; use them as the checklist so your containment design covers the known ground rather than the ground that happens to be top of mind.
What this means for the rest of the series
If you accept that the thing you are containing is legitimate capability used through unanticipated paths — not infrastructure escape — then three consequences follow, and they shape the next three articles.
First, controls have to act whether or not the agent cooperates. That rules out instructions and ranks the software and hardware controls by whether they still work when the agent is actively trying to get around them. That is article 3 (software) and article 4 (hardware and out-of-band).
Second, the right amount of containment depends on autonomy stage and the trifecta, so you need those recorded per workload, derived from behaviour, not taken on faith. That is the bridge into the ledger in Part C.
Third, a control you have not tested is a control you do not have. Proving a control works — not asserting it — is its own discipline, and it is article 5.
You are not trying to stop a jailbreak out of a VM. You are trying to ensure that an agent with real credentials, real tools and real network access cannot be steered, by content or by its own planning, into doing something irreversible before anyone outside it notices. That is a narrower and far more tractable problem than "rogue AI" — and naming it precisely is the first step to containing it.
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/
- 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
- OWASP, "Top 10 for Agentic Applications." https://neuraltrust.ai/blog/owasp-agentic-ai-top-10
- Speakeasy, "The OWASP Agentic Top 10, explained." https://www.speakeasy.com/blog/owasp-agentic-top-10-explained
- MITRE ATLAS, "Invoke mutative agent tools (AML.T0101)." https://d3fend.mitre.org/offensive-technique/attack/AML.T0101
- Cloud Security Alliance / CISA, "Agentic AI security guide: enterprise implications." https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/05/CSA_research_note_cisa-agentic-ai-security-guide-enterprise-implications_20260508-csa-styled.pdf
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article