We Gave AI Agents Tools. Now We Need to Assume They Can Escape.

For the last few years, most AI security conversations have focused on the model. Can the LLM be jailbroken? Can someone inject a malicious prompt? Will it leak system instructions? Can it generate dangerous content?

Those questions still matter. But they are rapidly becoming the wrong layer of abstraction.

Because an AI agent is no longer just User → LLM → Response. It increasingly looks like User → Agent → Planner → Tools → Shell → Filesystem → Network → APIs → Cloud → Production.

And once an LLM can execute commands, install packages, call APIs, browse networks, modify files and assume identities, we are no longer securing just an AI model. We are securing a workload - and more specifically, an autonomous workload whose next action is generated dynamically.

That changes the threat model considerably. There is one assumption I think agent platforms increasingly need to adopt:

This post is about the layer around the agent. Two companions look inward and sideways: the model is not your agent is about the runtime inside a single agent, and MCP gave agents tools, A2A gives agents colleagues is about the boundary between independent agents.

The sandbox was supposed to be the boundary

The obvious answer to agent risk has been sandboxing. Give the agent a temporary filesystem. Run its shell commands inside a container. Restrict what directories it can access. Block network traffic. Destroy the environment after the task finishes.

This is good engineering. But a sandbox should be treated as one security layer, not the security architecture.

We recently got a very concrete demonstration of why. During cybersecurity evaluations in July 2026, OpenAI reported that models operating inside an isolated evaluation environment found and exploited a previously unknown vulnerability in the Artifactory infrastructure surrounding that environment. The evaluation environment itself did not provide direct internet access, yet the models obtained a path outward and ultimately interacted with external systems.

That incident is important beyond the specific vulnerability. It illustrates a general principle: an agent does not need an explicit internet_access=true capability if something reachable from its environment can provide a path to the internet.

The same applies to credentials. And cloud metadata. And package registries. And build systems. And CI runners. And internal proxies.

The effective security boundary isn't the sandbox configuration. It is the complete graph of everything reachable from the sandbox.

1. LLM security

The first generation of AI security concentrated heavily on the model. We worried about prompt injection, jailbreaks, system prompt leakage, hallucination, unsafe generation and sensitive-data disclosure. These remain real problems.

But consider prompt injection in a chatbot: an attacker convinces the model to say something undesirable. Now consider prompt injection in an agent. The attacker convinces the model to execute kubectl delete, or terraform apply, or npm install, or curl, or gh pr merge.

The vulnerability may originate in language. But the damage happens through capabilities.

That distinction matters. The most important question changes from can the model be manipulated? to what happens if the model is manipulated? That is a much more useful engineering question.

2. Agent permissions

The first control layer is capability restriction. An agent should not simply inherit the permissions of the person who launched it.

Consider a developer using an AI coding agent. That developer might personally have GitHub write access, AWS credentials, Kubernetes admin, production database access, npm publishing rights, Slack tokens and SSH keys. That doesn't mean the agent needs all of those capabilities.

Yet today it is surprisingly easy to create a chain where the shell inherits almost everything available to the developer. That is effectively delegation without a delegation model.

The second model has a very large blast radius. The first has a bounded one.

NIST has started explicitly examining this problem through work on identity and authorization for software and AI agents, noting that useful agents need access to tools, applications and data while still requiring appropriate identification and authorization controls.

3. Assume sandbox escape

This is where the architecture becomes more interesting.

Containers are useful. VMs are useful. seccomp is useful. gVisor is useful. macOS Seatbelt and Linux namespaces are useful. But security engineering has never worked by saying this layer is perfect, therefore everything behind it may be trusted.

Anthropic describes agent containment in similar blast-radius terms: constrain the environment using process sandboxes, VMs, filesystem boundaries and egress controls so that even if agent behaviour fails, what it can reach remains bounded. This is classic defence in depth.

So imagine an agent does escape its runtime. What does it find? If the answer is a cloud metadata endpoint, a shared service account, an internal flat network, unrestricted internet, production APIs, CI credentials and package publishing credentials - then your sandbox was doing almost all of your security work.

That is dangerous. Instead, design the surrounding environment as though the process inside the sandbox is already compromised. The escaped process should encounter another wall. And then another.

4. Tool isolation

We also need to stop thinking about tools as innocent functions. For an agent, a tool is a capability boundary.

Consider:

agent.tool("github")

What does that actually mean? Can it read issues? Read private repositories? Create branches? Commit files? Modify workflows? Merge pull requests? Access secrets? Create releases? Delete repositories?

Calling all of that one github tool hides an enormous permissions surface. Tools should become smaller and capability-oriented.

The principle is straightforward: give agents operations, not applications. This is capability security applied to agent tooling.

OWASP's agentic security work increasingly reflects this distinction, identifying risks around tool misuse, identity and privilege abuse, agent goal hijacking and agentic supply-chain vulnerabilities.

5. Network policy becomes an agent control

Network access deserves special treatment. For conventional applications we often think the app needs internet access, so allow outbound HTTPS. That is far too broad for agents.

An autonomous coding agent with unrestricted HTTPS can reach GitHub, package registries, paste sites, cloud APIs, command-and-control infrastructure, random attacker-controlled hosts and data exfiltration endpoints - all over the same port.

443 is not a meaningful security policy.

This is where agent infrastructure begins looking less like application hosting and more like zero-trust workload infrastructure. Network access is a capability - treat it accordingly. The infrastructure layer is growing primitives for exactly this, which is part of why Kubernetes is becoming an AI workload orchestrator.

6. Workload identity

This may eventually become one of the most important pieces.

Today many agents act using user credentials. That makes attribution difficult and often grants unnecessary privilege.

The agent identity should be unique, short-lived, task-scoped, attributable to the initiating user, independently revocable, and unable to silently expand its own permissions.

Think Kubernetes ServiceAccounts, SPIFFE identities, IAM roles and OAuth delegation - but applied systematically to agent runs.

Most importantly, the agent should not possess the user's credential. It should possess a delegated workload identity representing: this user authorised this specific agent to perform this specific task for this specific period. That distinction dramatically improves both containment and auditability.

7. Credentials must never be ambient

This follows naturally. A sandbox should ideally contain almost no long-lived secrets - no ~/.aws/credentials, no .env, no SSH_PRIVATE_KEY, GITHUB_TOKEN, DATABASE_URL or NPM_TOKEN sitting on disk waiting to be read.

The difference is important. If an agent escapes the sandbox but credentials never existed inside it, there is much less to steal.

Security moves from protect the secret toward avoid giving the workload a reusable secret in the first place.

8. Human approval is useful - but not a security boundary

Approval dialogs are commonly used for agent safety. Useful? Absolutely. Reliable security boundary? Probably not.

Anthropic reported that Claude Code users approved roughly 93% of permission prompts in its telemetry, highlighting the predictable problem of approval fatigue. Humans quickly learn to click Allow.

Which means agent architecture should not depend on a human correctly identifying every dangerous action. Human approval should protect high-impact transitions instead.

Far fewer approvals. Much higher signal.

9. Audit trail becomes first-class infrastructure

Traditional application logs answer questions like GET /api/users → 200 → 132ms. Agent systems need to answer considerably more. For every meaningful action, we should be able to reconstruct:

• Who initiated the agent, and which agent instance acted
• Which model and version was running, and what goal was assigned
• What tool was selected, and what arguments were supplied
• What identity authorised the request, and what policy allowed it
• What resource was accessed, and whether human approval was involved
• What changed, and what happened next

Every edge should be attributable.

OpenAI's description of its internal Codex deployment similarly emphasises managed configuration, constrained execution, network policies and agent-native telemetry for understanding and auditing agent behaviour.

This matters not only for incident response. It matters for debugging, governance, cost attribution, compliance, and eventually for learning which agent behaviours correlate with unsafe outcomes.

The agent security stack

Put these layers together and the architecture starts looking like this.

Notice what is missing. There is no layer called trust the model. That is intentional.

The goal is not to build an agent that never fails

This is perhaps the biggest mindset shift. Trying to guarantee that an AI agent will never make a bad decision is probably the wrong systems goal.

We don't build Kubernetes assuming every container is trustworthy. We don't design browsers assuming JavaScript is trustworthy. We don't build operating systems assuming every process behaves correctly. And we shouldn't build agent platforms assuming every agent action will be correct.

Instead, assume the agent will eventually do something unexpected - because of prompt injection, hallucination, compromised dependencies, malicious repository content, poisoned memory, tool bugs, confused planning, an actual software vulnerability, or simply a task interpreted differently from what the user intended.

Then ask the engineering question that matters: how far can it get?

That is blast-radius engineering. It is the same instinct behind the governance layer in agentic patterns - autonomy is only affordable where mistakes are catchable and reversible.

From AI safety to agent infrastructure security

The industry started with is the model safe? Then is the prompt safe? Then is the tool call safe? The next stage is: is the entire execution environment safe when the agent is not?

The interesting consequence is that the future of AI-agent security may look surprisingly familiar. It looks like operating-system security. Cloud security. Container security. IAM. Zero trust. Capability security. Network segmentation. Observability.

Except now the workload interacting with those systems can reason, explore, adapt and choose its own sequence of actions. That makes the fundamentals more important, not less.

We spent the first phase of generative AI trying to make models behave safely. The next phase needs to assume something much more pragmatic. The model might behave incorrectly. The agent might misuse a tool. The sandbox might fail. The credential might be targeted. The network might expose an unexpected path.

And the system should still survive.

Because once we give AI agents tools, shells, identities and networks, containment is no longer an AI feature. It is infrastructure.