What Coding Sandboxes Get Wrong About AI Agent Workloads
Isolated execution environments weren't built for agents that reason across steps.
Coding sandboxes isolate execution. AI agents need infrastructure that supports an entire working lifecycle. The mismatch is architectural. A safe place to run code is only one part of an environment in which an autonomous agent can complete and prove its work.
Why coding sandboxes and agent workloads are built on opposite assumptions
The original sandbox has a bounded lifecycle. A human submits code, the environment executes it, returns output, and disappears. That design gives isolation a clear beginning and end. An agent, however, reasons across steps, calls tools, waits for results, and generates more code in response. Its work may continue beyond a process exit and pause for human review.
What, then, counts as the end of a task? For a discrete execution system, returning output is enough. For an agent, that output may simply become the next input. The code also arrives with no guarantee that a human has reviewed all of it and may try to cause damage, use too many resources, or take insecure actions. The sandbox’s original choices were sensible, but the workload changes both the lifecycle and the threat model.
Shared-kernel isolation was not designed to contain untrusted, autonomously generated code
The first mismatch appears at the kernel boundary. Standard shared-kernel containers give workloads separate process namespaces but still use the host Linux kernel. Because the kernel is shared, a kernel-level exploit inside a container can reach the host. The distinction is fundamental.
Autonomously generated code cannot be fully reviewed before execution, so treating it as trusted is the wrong starting point. Isolation must be evaluated by what remains protected when an agent’s code behaves badly. MicroVMs such as Firecracker and user-space kernels such as gVisor provide stronger isolation mechanisms than ordinary shared-kernel runtimes. The architectural choice concerns the boundary between the workload and the host.
Even that choice does little to protect the host if isolation can be left off. Anthropic’s Claude Code documentation states that its sandbox uses Bubblewrap on Linux and Seatbelt on macOS and is off by default. Gemini CLI’s documentation likewise describes Docker and Podman sandboxing that must be enabled, while OpenAI Codex enables sandboxing by default. These defaults are not interchangeable with isolation strength. A deployment needs both an appropriate boundary and enforcement of that boundary.
Sandbox permission models cover the shell but leave most of the agent loop unprotected
A strong execution boundary still leaves another question unanswered. Which agent actions actually pass through it? Anthropic’s documentation states that Claude Code’s sandbox wraps shell commands and their children, while Read, Edit, Write, WebFetch, and WebSearch follow permission rules instead. A denyRead entry does not stop the Read tool, and allowedDomains does not limit WebFetch. The shell boundary is narrower than the agent’s action surface.
Network permissions introduce a similar distinction between an allowed destination and a safe action. The same documentation describes a proxy that uses the client-supplied hostname for domain allowlisting and does not terminate or inspect encrypted traffic by default. It also warns that broad domains such as github.com can provide paths for data exfiltration. Secrets passed through environment variables can still be exposed even when process isolation works, unless those variables are scrubbed or egress is limited.
Human approvals do not repair this mismatch in scope. Repeated prompts create approval fatigue, turning review into a reflex. Cursor’s documentation explicitly states that its automated review mode “is not a security boundary”. The distinction is between permission and containment.
Sandboxes stop at code execution and cannot close the verification loop agents actually need
Even a sandbox that enforces its security boundary correctly can leave the agent unable to establish whether its work succeeds. Unit tests are only one form of evidence. An agent may also need a real database, a staging deployment, end-to-end tests, and a live preview URL that a reviewer can inspect. Those capabilities require access beyond isolated execution.
The agent-native environments associated with Codex, Cursor, Claude Code, and Copilot illustrate the distinction between running tests and verifying a deployment. They support unit-test execution, but the isolated environment does not itself provide a real deployment, end-to-end verification, or a preview URL. Cursor’s engineering team described the underlying problem directly. “An agent that can write code but can't run tests, query services, or reach APIs cannot close the loop on its work”. The team built what it called “essentially enterprise IT for agents” to make the working environment usable.
The isolation that protects the host also separates the agent from services needed to test the result in context. Expanding access without governance weakens the boundary established for safety. A full-stack environment on the team’s own cloud addresses a different requirement, allowing deployment and verification within a governed environment. That is an infrastructure responsibility.
Ephemeral lifecycle breaks agent workloads that need to pause, resume, and persist state across steps
An ephemeral environment treats task completion as a reason to discard state, while an agent lifecycle depends on continuity. A human review, a failure, or a wait for new input may interrupt work without ending it. The environment must survive that distinction. Otherwise, resumption becomes reconstruction, and reconstruction is not necessarily equivalent to continuing from the point of interruption.
What must a pause preserve to count as continuity? A filesystem snapshot does not preserve a running pytest debug session, while process restart alone does not recover uncommitted files. Saving only one can preserve the appearance of progress without preserving the conditions under which the agent was operating.
Session memory addresses a different problem again. Chat history helps an agent remember, but it does not establish which shell command ran, which approval was granted, or whether retrying an action would duplicate a side effect. Durable execution needs an execution journal and idempotent tool boundaries. Accumulating conversation context and tool output can also degrade coherence during extended sessions. Explicit state management addresses that structural problem rather than asking a better model to compensate for it.
With the orchestration-kernel pattern, reasoning and durable execution are kept separate. Agents remain stateless across invocations, while a stateful orchestration kernel persists workflow state and handles recovery. Each invocation becomes a pure function in which current state and new input produce next state and actions. Continuity belongs to the orchestration layer rather than the conversation. This makes the relevant questions concrete, including what a pause preserves, what sleep destroys, and how long state can remain on standby.
Provisioning latency is a first-class architectural problem, not a performance detail
Persistence does not solve the problem if returning to work takes too long. A human may tolerate waiting for one environment to boot, but agents generate code continuously across concurrent sessions. Each wait for provisioning delays work within the loop. At that point, time-to-ready constrains the architecture rather than merely affecting how responsive an interface feels.
Firecracker boots in approximately 125 milliseconds, illustrating what purpose-built provisioning can achieve. Boot time, however, is only part of the question. A fast new environment is not necessarily the environment an interrupted agent needs. Resume latency must be weighed alongside what state is restored, how long it can stay on standby, and what it costs while idle.
An environment can hibernate while preserving state and resume in milliseconds between agent steps. That continuity has a specific technical meaning. It includes the filesystem, memory, and running processes, rather than just files restored into a newly started runtime. Otherwise, “resume” conceals the need to reconstruct state that persistence was supposed to preserve.
Computer-use agents expose a category of workload that sandbox architectures were never designed for
Computer-use agents shift the unit of work again. They click, type, scroll, switch windows, and read the screen before choosing another action. Rather than calling an exposed API, they operate interfaces that already exist. This requires a display environment, OS-level process access, and interaction with native applications. A code-execution sandbox alone does not supply that runtime.
Browser agents are faster and cheaper but cannot act outside the browser. OS-level agents can operate native clients, file dialogs, terminals, and other applications, but need a real machine or VM and are slower per step. Information displayed on a page can influence an agent that has access to the machine around it.
Johann Rehberger’s ZombAIs test demonstrated that risk concretely. A Claude Computer Use agent read a plaintext indirect prompt injection on a malicious page, downloaded a binary, ran chmod +x, executed it, and connected to a command-and-control server. The chain worked on the first try with unrestricted host access. AgentHijack, presented as an ICML 2026 benchmark, measures robustness to environment corruptions, while OS-Harm measures safety failures and OSWorld2.0 (2026) tests long-horizon real-world tasks. Together, these research directions treat computer use as a distinct problem space requiring an isolated virtual desktop.
Enterprise compliance requirements expose the remaining gap between sandbox safety and production readiness
Isolation contains code, but leaves open questions about how data is handled, who is accountable, and which rules must be met. SOC 2 Type II shows that a vendor’s internal controls were audited over a set period. It does not by itself establish an acceptable audit trail for agentic actions, explain how a model provider handles data, or determine transcript retention and deletion. Those responsibilities extend beyond the execution environment.
GDPR makes the tension with persistent agent context explicit. Processing personal data of EU data subjects requires a lawful basis under Article 6, while Articles 13–15 and 22 address explanation of automated decisions. Article 5(1)(c)’s data minimization principle constrains the context an agent can retain between sessions. Persistence cannot mean keeping everything without qualification. The European Commission’s Article 50 FAQ states that the EU AI Act’s disclosure requirements apply from 2 August 2026, requiring AI identity disclosure for direct interactions unless the AI nature is obvious from the circumstances and context.
Platform capability also differs from a compliant deployment. A Salesforce Agentforce deployment without Shield Platform Encryption, correctly scoped agent permissions, and a signed BAA is not HIPAA-compliant merely because the platform supports those requirements. Compliance remains an active engineering responsibility. Procurement should require SOC 2 Type II together with AI-specific certifications such as ISO/IEC 42001:2023, which address training data security, AI lifecycle risks, and AI pipeline risks. Neither certification nor sandboxing substitutes for the deployment controls themselves.
What purpose-built agent infrastructure actually requires, and why retrofitted sandboxes cannot provide it
The common design unit is the agent lifecycle. A runtime built around that unit combines stronger kernel isolation with permissions that cover the full action surface and governed access for verification. It also separates durable workflow state from individual model invocations, using an execution journal to support recovery. Fast provisioning and state-preserving resume make that lifecycle practical at machine speed.
Retention, permissions, auditability, and data handling cannot be inferred from a successful execution boundary. Docker-native compatibility can keep existing stacks working without assuming that the execution environment will be thrown away. Compatibility need not dictate the underlying lifecycle.
