In Part 1 of this series, we argued that software-only security cannot contain autonomous AI agents. In Part 2, McKinsey's Lilli breach showed what happens when that architectural gap meets reality. Both pieces operated at the level of architecture and analysis.
This piece goes deeper. The most common objection we hear to the infrastructure-enforced thesis is: "We already sandbox our workloads. Containers and VMs provide isolation. Why isn't that sufficient?"
It is a reasonable question. And the answer is technical, not philosophical.
The Sandbox Assumption
Every sandboxing mechanism in production today — process namespaces, seccomp filters, containers, virtual machines — was built on a single foundational assumption: the workload does not want to escape.
This is not a design flaw. It is a design constraint that made perfect sense for the workloads sandboxes were built to contain. A web server does not strategize about its confinement. A database does not probe the boundaries of its cgroup. A batch job does not reason about whether a side channel exists in the hypervisor. These workloads are passive. They execute their code, consume their allocated resources, and terminate.
Sandboxes were built to protect against two things: bugs in the workload that accidentally reach across boundaries, and external attackers that exploit vulnerabilities in the workload to pivot laterally. In both cases, the threat originates from outside the workload's intent.
An autonomous AI agent is different in kind, not degree. It is a goal-directed reasoner with the ability to observe its environment, form hypotheses about constraints, and systematically test them. It does not need a pre-written exploit. It can discover one. The sandbox is no longer protecting against accidental boundary violations or external attackers. It is containing an entity that is actively, intelligently trying to accomplish goals — and the boundary of the sandbox is just another obstacle in its planning space.
Where Each Isolation Layer Breaks
The industry deploys isolation at four levels. Each was designed for passive workloads, and each fails in a specific way when the workload is an autonomous agent.
Process-Level Isolation
Linux namespaces, seccomp-bpf, and capability dropping restrict what a process can see and do at the syscall level. A PID namespace hides other processes. A network namespace restricts interface access. Seccomp filters block dangerous syscalls entirely.
But agents do not operate at the syscall level. An AI agent making an HTTP request to an external API is not calling connect() and sendto() in ways that seccomp can meaningfully distinguish from legitimate traffic. The agent works through high-level abstractions — tool calls, API requests, SDK methods — that all resolve to the same permitted syscalls. Seccomp cannot tell the difference between an agent calling a sanctioned tool and an agent crafting an HTTP request to an unauthorized endpoint, because at the kernel level, they look identical.
Process isolation answers the question: "What syscalls can this process make?" But the right question for agents is: "What should this entity be allowed to decide to do?" These are fundamentally different questions, and the first cannot answer the second.
Container-Level Isolation
Containers — OCI runtimes, Docker, containerd — add filesystem isolation, resource limits via cgroups, and a degree of network segmentation. They are the default deployment unit for most AI workloads today.
The structural problem is the shared kernel. Every container on a host shares the same Linux kernel, and kernel vulnerabilities are not theoretical. CVE-2024-21626 allowed container escape through /proc/self/fd manipulation in runc. CVE-2022-0185 exploited a heap overflow in the filesystem context handling to escape user namespaces. These are not obscure attack paths — they are well-documented, and new ones appear regularly.
A traditional workload does not actively scan for kernel escape vectors. An autonomous agent can. It can query its own kernel version, cross-reference known CVEs through tool calls, and iteratively probe for exploitable conditions — exactly the kind of systematic, patient enumeration that the McKinsey breach demonstrated at the application layer. The shared kernel means that a successful escape from one container gives access to every container on the host. For multi-tenant agent deployments, this is not an edge case. It is an existential risk to the isolation model.
VM-Level Isolation
Virtual machines provide a materially stronger boundary. Each VM runs its own kernel, and the hypervisor enforces isolation at the hardware abstraction level. A vulnerability in one guest OS does not directly compromise another guest.
VMs are the right instinct. But the isolation they provide is only as strong as the layer that orchestrates them.
In practice, VMs are provisioned, configured, and networked by software orchestration systems — Kubernetes, OpenStack, cloud provider APIs. These orchestration layers define which networks the VM can reach, what storage it can mount, and what resources it can consume. An agent that can influence its own orchestration — through tool calls to cloud APIs, through prompt injection that alters deployment configurations, or through exploitation of the management plane — can weaken its own isolation without ever touching the hypervisor.
There is also the matter of side channels. Spectre-class vulnerabilities demonstrated that hardware-level information leakage across VMs is not theoretical. For workloads processing sensitive data — financial models, healthcare records, classified information — even the hypervisor boundary may be insufficient when the workload on the other side is an autonomous reasoner capable of mounting a systematic side-channel attack.
The Pattern
Each isolation level fails for the same fundamental reason: the enforcement mechanism operates in a domain that the agent can observe, reason about, and in many cases manipulate. Process isolation operates at the syscall level, which the agent works above. Container isolation depends on a shared kernel that the agent can probe. VM isolation relies on a software orchestration layer that the agent can interact with.
The trend is clear: isolation is only effective when it operates at a level the workload cannot reach. For passive workloads, every level provides some degree of this property. For autonomous agents, only physical infrastructure provides it unconditionally.
The Controlled-Escape Problem
There is a deeper reason why sandboxing fails for agents, and it has nothing to do with escape vulnerabilities.
A sandbox exists to prevent a workload from reaching the outside world. But an agent's entire purpose is to reach the outside world. It needs to call APIs. It needs to query databases. It needs to read and write files, send messages, invoke tools, and interact with external services. Every one of these capabilities is, by definition, a deliberate hole in the sandbox.
This creates what we call the controlled-escape problem: the sandbox must simultaneously prevent unauthorized access and permit authorized access, and the boundary between the two is determined by the agent's intent — something no sandbox mechanism can inspect.
Consider a concrete scenario. An agent is granted access to a database through a connection string. The sandbox permits this connection because the agent needs it for its task. But nothing in the container, VM, or process isolation layer can distinguish between:
- The agent querying the three tables it needs for its current task
- The agent enumerating the schema of every table in the database
- The agent exfiltrating sensitive data from an unrelated table through the same permitted connection
All three actions use the same connection, the same port, the same protocol. The sandbox sees no difference. The isolation layer did its job — it restricted network access to the permitted endpoint. But the security problem was never at the network level. It was at the intent level, and sandboxes have no mechanism for reasoning about intent.
This is the fundamental limitation. The more capable the agent, the more tools it needs. The more tools it needs, the more holes the sandbox must permit. The more holes the sandbox permits, the less meaningful the sandbox becomes. At the limit, a highly capable autonomous agent operating inside a fully-provisioned sandbox is barely sandboxed at all.
Isolating Agency, Not Just Execution
The sandbox model isolates code execution: what instructions can run, what memory can be accessed, what files can be opened, what network connections can be made. These are the right controls for passive workloads, because passive workloads are nothing more than their code execution.
An autonomous agent is more than its code execution. It is an entity that decides, and its decisions have consequences that extend far beyond the syscalls they produce. Isolating an agent requires controlling three dimensions that no sandbox mechanism was designed to address:
Tool Access Isolation
An agent's tool set is its action space. A sandbox does not know what tools an agent has access to, or whether a given tool invocation is appropriate for the agent's current task. Tool access control must be dynamic — scoped to the current task, time-bounded, and revocable in real time. This is an authorization problem, not an isolation problem, and it must be enforced at a layer the agent cannot reach.
Data Reach Isolation
Even within a perfectly sandboxed environment, an agent's data reach is determined by the credentials and connections it has been granted, not by the sandbox boundary. A container with a database connection string has full reach to whatever that string permits. A VM with an S3 access key can read every object in the bucket. Sandboxes constrain the transport layer but not the authorization layer, and agents operate above both.
Decision Authority Isolation
The most consequential dimension, and the one that no current sandbox even attempts to address. An agent can decide to take an action that is technically within its permissions but operationally inappropriate — transferring funds to the wrong account, deleting a production dataset, sending confidential information to an external endpoint through an authorized API. The action is permitted at every isolation layer. It is the decision that is wrong.
Constraining decision authority requires enforcement that operates below the agent's reasoning layer — at a level the agent cannot introspect, cannot manipulate, and cannot reason its way around. Software-level guardrails attempt this, but as we argued in Part 1, they operate within the same execution environment the agent can influence. Deterministic control of agent decisions requires anchoring enforcement to something the agent fundamentally cannot touch.
Sandboxes isolate processes. Agents are not processes. They are decision-makers with tool access, data reach, and autonomous authority. Containing them requires isolating all three — at a level no software-only mechanism can provide.
What Agent Isolation Actually Requires
| Isolation Dimension | What Sandboxes Provide | What Agents Require |
|---|---|---|
| Execution Boundary | Process / container / VM walls | Physical infrastructure separation — no shared silicon |
| Tool Access | Not addressed — all permitted calls look identical | Dynamic, task-scoped, time-bounded tool authorization |
| Data Reach | Network-level restrictions only | Fine-grained data access tied to task context, enforced at infrastructure |
| Decision Authority | Not addressed | Deterministic controls enforced below the reasoning layer |
| Identity | Process UID / container label | Cryptographic identity anchored to hardware — unforgeable |
| Shutdown | SIGKILL / container stop | Infrastructure-enforced termination — un-bypassable |
| Threat Model | Bugs and external attackers | The workload itself is a goal-directed reasoning entity |
The Bottom Line
Sandboxing is a necessary layer. It is not a sufficient one. Containers and VMs were built to isolate code from code. Agent isolation requires isolating intent from capability — ensuring that an autonomous entity can only act within the boundaries of its authorized purpose, even when it has the intelligence and the tools to do otherwise. That enforcement must live at the infrastructure level, because it is the only level an agent cannot compromise.
Where This Leads
The sandbox model served the industry well for two decades. It was the right abstraction for a world where workloads were passive, deterministic, and predictable. Agents are none of these things.
The instinct to reach for containers and VMs when deploying agents is understandable — they are the tools we know. But the threat model has changed. The workload is no longer something that might accidentally escape. It is something that actively reasons about its environment, tests its boundaries, and pursues goals with whatever capabilities it can access.
Isolation that works for agents must operate at a level the agent cannot observe or influence. It must enforce not just what code can execute, but what decisions can be acted on. And it must anchor every identity, every permission, and every enforcement mechanism to something that exists below the software stack entirely.
This is why we built Vecta's execution fabric from hardware up — not from software down. Not because sandboxes are useless, but because for autonomous agents operating in high-stakes environments, the sandbox is the floor. The ceiling is infrastructure-enforced isolation across every layer, from silicon to decision boundary, with no level of the stack taking the agent's cooperation for granted.