Sandbox selection for AI coding agents is a threat-model decision

At a glance

What this is: This is an analysis of 14 sandbox approaches for AI coding agents, with the key finding that every isolation tier has a failure mode and sandboxing only contains blast radius, it does not solve trust.

Why it matters: It matters because IAM, PAM, and platform teams must decide what credentials and access an AI coding agent can carry into execution, and the wrong sandbox design turns containment into credential exposure.

By the numbers:

• Pillar Security analyzed 14 sandbox solutions for AI coding agents across four isolation tiers.
• E2B boots Firecracker microVMs in about 150ms.

👉 Read Pillar Security's analysis of AI coding agent sandbox failures

Context

AI coding agents are useful only when they can read files, run commands, and reach network resources, but that same access makes the execution environment part of the trust boundary. When untrusted repositories, packages, or model outputs can trigger code execution, the real question is not whether to sandbox the agent, but which identities, credentials, and data are allowed inside that boundary.

Pillar Security’s analysis shows why conventional access assumptions break down here. A sandbox protects the host from the agent environment, but it does not protect the agent from poisoned context, mounted secrets, or full filesystem visibility. That makes sandbox design an identity governance problem as much as an engineering one, especially for NHI credentials and delegated access.

For teams already thinking in workload identity, the core lesson is simple: containment is only as strong as the credentials and files you place inside it. The starting position in many developer environments is typical, which is why the failure mode is easy to miss until an agent leaks something it was never supposed to see.

Key questions

Q: How should security teams handle credentials inside AI coding agent sandboxes?

A: Security teams should assume any credential visible to an AI coding agent is usable for theft, leakage, or lateral movement. Keep only the minimum necessary secrets inside the sandbox, prefer short-lived credentials, and remove broad read access wherever possible. If an agent can print a secret, that secret is already exposed to the trust boundary.

Q: Why do AI coding agents make sandbox design an IAM issue?

A: AI coding agents are useful only because they can execute with meaningful access, which means the identity and access decisions made before runtime directly shape the blast radius. When secrets, files, and network access are mounted into the sandbox, IAM has effectively extended trust into an untrusted execution environment. That is why sandbox policy belongs in identity governance, not only platform engineering.

Q: What breaks when sandboxing relies only on command allowlists?

A: Allowlists fail when context is poisoned, because a command that looks safe in isolation can become dangerous after environment variables, inherited shell state, or prior execution steps modify the session. The result is an approval model that validates syntax but misses stateful attack paths. Teams need controls over context, not just command names.

Q: What should teams do when an AI agent needs network and filesystem access?

A: Teams should decide whether the agent needs both privileges for the task and, if so, contain each one separately. Restrict filesystem read access to only the files the job requires, limit egress to approved destinations, and add monitoring for unusual reads or outbound transfers. Without those controls, the sandbox becomes a convenient exfiltration layer.

Technical breakdown

Why sandboxing is containment, not prevention

A sandbox constrains what happens after trust is already broken. In AI coding agents, the trigger may be a malicious package install script, a poisoned repository, or prompt injection through external content, but the boundary only limits damage after execution starts. Isolation technology protects the host from the sandbox environment; it does not make untrusted code trustworthy. That distinction matters because many teams treat the sandbox as the control, when it is really the last layer in a chain of controls. If secrets, tokens, or broad filesystem access are mounted into the sandbox, the agent can still read and exfiltrate them.

Practical implication: Treat sandboxing as blast-radius control and inventory every credential, file share, and network path exposed inside it.

Container, microVM, and kernel-enforced isolation in AI agent execution

The isolation tier determines how hard the boundary is to break and what operational trade-offs come with it. Containers share a kernel and therefore share a failure domain with the host. User-space kernels such as gVisor reduce syscall exposure but make correctness critical. MicroVMs give the sandbox its own kernel, which strengthens isolation but adds latency, memory overhead, and session constraints. Kernel-enforced approaches such as Seatbelt, Bubblewrap, or Landlock can be effective locally, but they are not universal platform answers. Each tier solves a different threat model, which is why architecture must follow the exposure profile, not product preference.

Practical implication: Match the isolation tier to the untrusted input source and the value of the credentials inside the execution environment.

Static allowlists fail when agent context is poisoned

Static command allowlists assume that a command remains safe because it is permitted in isolation. That assumption fails when environment variables, inherited shell state, or prior execution steps can modify context mid-session. In the article’s example, a supposedly allowed command becomes dangerous after environment poisoning, which means the real attack surface is not only the command itself but the state around it. The same logic applies to full filesystem read access. An agent does not need write access to leak secrets if it can read credentials and print them to STDOUT or another exfiltration channel.

Practical implication: Pair allowlists with context controls that restrict inherited state, read access, and exfiltration paths.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sandbox trust debt is the gap this article exposes: teams often assume the sandbox is a trust boundary, when it is really a containment boundary. That assumption fails as soon as the agent is given mounted secrets, broad read access, or network reach that can be used against it. The implication is that identity governance must account for what lives inside the sandbox, not just how the sandbox is built.

AI coding agents turn credential placement into the primary risk variable. A microVM with mounted AWS credentials is still an exposed credential environment if the credential itself is reachable from the agent. This is a familiar NHI lesson applied to a new runtime: the control plane matters less than the access payload. Practitioners should evaluate blast radius by mounted identity, not by isolation label.

Read access is the hidden privilege boundary in agent execution. The article makes clear that many teams focus on write restrictions while overlooking the fact that read access is enough for credential theft, data leakage, and malicious chaining. That is a governance failure, not just a tooling gap. Teams need to treat read permissions as a privileged capability when the actor can execute untrusted code.

Dual-isolation is a useful pattern because it separates distinct failure modes. Filesystem controls and network controls fail differently, so combining them gives defenders more than one chance to stop exfiltration. That aligns with OWASP-NHI and zero trust thinking, where no single boundary is treated as sufficient. The practical conclusion is to design for layered containment rather than betting on one sandbox tier.

Identity blast radius is the right concept for agent sandboxes. The article shows that the question is not whether an AI coding agent is sandboxed, but how far its identity can reach before a failure becomes visible. That concept bridges NHI governance and agentic runtime control. Practitioners should map every credential, mount, and egress path to its possible blast radius before deployment.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• Only 44% have implemented any policies to govern AI agents, even though 92% say governing them is critical to enterprise security.
• That gap matters because agent execution is already outpacing governance, a pattern explored further in OWASP Agentic Applications Top 10.

What this signals

Identity blast radius will become the practical test for AI coding agent governance. The next question for platform teams is no longer whether the sandbox exists, but what identity and data the agent can reach before the first alert. As more teams adopt agentic workflows, the boundary between runtime isolation and NHI governance will keep narrowing, especially where secrets, repositories, and network access are bundled together.

Sandbox policy will increasingly be evaluated as a control-plane decision, not a deployment detail. Teams that can answer which credentials are mounted, which reads are allowed, and which egress paths are open will be far better positioned to contain untrusted code. That posture aligns with the NHI Management Group view that containment without visibility creates a false sense of control, particularly when the agent can operate faster than human review cycles.

The article’s core implication is that AI agent environments need governance hooks before they need more power. For many organisations, the first meaningful step will be reducing default read access and moving toward tighter runtime review of what the agent can inspect, copy, or transmit.

For practitioners

• Inventory every credential mounted into agent sandboxes List environment variables, secret files, cloud tokens, and service-account material that an AI coding agent can read during execution. Remove anything not strictly required for the task, and treat read access as sensitive because STDOUT or logs can become exfiltration channels.
• Choose the isolation tier from the threat model inward Select containers, user-space kernels, microVMs, or kernel-enforced controls based on the untrusted source, the value of the data inside the sandbox, and the blast radius you can tolerate. Do not start with the tool and then fit the threat model around it.
• Separate command control from context control Combine allowlists with restrictions on inherited environment state, filesystem read paths, and network egress. Static command approval alone does not stop poisoned context from turning an allowed command into an attack path.
• Add detection for boundary violations, not just prevention Monitor for anomalous file reads, unusual outbound requests, and unexpected access to credential locations inside the execution environment. Sandbox escape attempts are operational events, not only design-time concerns.
• Review developer defaults for hidden privilege Check what the agent can see by default in local and CI environments, including workspace mounts, shell history, and shared repositories. Defaults often create the real exposure, not the sandbox product itself.

Key takeaways

• AI coding agent sandboxes are containment controls, not trust controls, so mounted credentials and broad read access remain the real exposure points.
• Pillar Security’s analysis of 14 sandbox solutions shows that every isolation tier fails differently, which makes threat-model fit more important than product label.
• Practical governance starts with secret minimisation, read-path restriction, and boundary detection, because command allowlists alone do not stop poisoned context.

Key terms

• Sandbox containment: Sandbox containment is the practice of limiting what an executing workload can do after trust has already been extended to it. In AI coding agents, it reduces blast radius, but it does not make the input trustworthy or remove the need to control secrets, mounts, and egress.
• Identity blast radius: Identity blast radius is the amount of data, systems, and credentials an identity can reach before a failure is detected or contained. For AI agents and other NHIs, it is often a better measure of risk than the sandbox label because reachable credentials define the damage path.
• Read access as privilege: Read access as privilege means treating file visibility and data inspection as sensitive capabilities, not harmless defaults. For untrusted AI agents, the ability to read secrets, repositories, or environment state can be enough to leak credentials or stage later abuse without any write permission.
• Context poisoning: Context poisoning is the manipulation of the state around a command or agent session so that a previously safe action becomes unsafe. It commonly involves environment variables, inherited shell state, or embedded content that changes how the agent behaves after the initial approval decision.

Deepen your knowledge

Sandbox selection and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI coding agents or other non-human identities, it is worth exploring.

This post draws on content published by Pillar Security: Your AI Agent Will Run Untrusted Code. Now What? Read the original.