AI coding agents on shared-host sandboxes create escape risk

At a glance

What this is: This is an analysis of how allow-default sandboxing for AI coding agents can be bypassed on macOS, with Launch Services, devfs and provenance-tag handling creating an escape route to host execution.

Why it matters: It matters because AI coding agents increasingly operate with access to files, commands and secrets, so weak process isolation can turn a helper into a host-level execution path that identity and privilege controls never intended to grant.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Pillar Security's analysis of sandbox escapes in AI coding agents

Context

AI coding agents are now operating in the same local environments where developers keep files, credentials and command-line access, which makes sandbox design a governance issue rather than a purely technical convenience. In this article, the primary problem is not the model itself but the execution boundary around the agent process, especially when that boundary is built on permissive defaults.

For identity and access practitioners, this is an NHI-adjacent control problem because the agent is acting as a runtime entity with delegated access, file reach and command execution rights. If the sandbox can be crossed, the effective privilege of the agent expands beyond what policy intended, and that undermines both human and machine identity assumptions.

The article's starting position is atypical in the sense that it focuses on a very specific macOS escape path, but the underlying lesson is common across agentic AI deployments: if the runtime boundary is weak, the access model around the agent is already compromised.

Key questions

Q: What breaks when AI coding agents run in allow-default sandboxes?

A: Allow-default sandboxes fail because they preserve most host capabilities and rely on deny rules to catch every dangerous path. For AI coding agents, that is too weak, since file handling, launch behaviour and environment interactions can be chained into host execution. A permissive sandbox can look functional while still leaving the machine reachable through an escape path.

Q: Why do AI coding agents complicate host isolation and access control?

A: AI coding agents complicate isolation because they are delegated runtimes that can read, write and execute based on instructions that may be benign or malicious. That means their access must be governed like a non-human identity with a blast radius, not like a normal app process. If the boundary fails, the agent's effective privilege expands beyond policy.

Q: What do teams get wrong about sandboxing autonomous AI agents?

A: Teams often confuse containment with trust. A sandbox can limit blast radius, but it does not automatically prevent the agent from using allowed tools against its own environment, especially when package installs, runtime scripts, and configuration files are all within reach. The wrong assumption is that policy compliance equals benign intent.

Q: Who is accountable when an AI agent escapes its sandbox?

A: Accountability should sit with the team that owns the agent runtime, its permissions and its exception process. If a sandbox escapes, the failure is usually not one line of code but a control design decision that allowed excessive privilege, weak confinement or incomplete validation. That is a governance issue, not only an engineering issue.

Technical breakdown

Why allow-default macOS sandboxes fail against agent escape

A sandbox-exec profile on macOS is a process filter, not a security boundary that can create new protections. When the profile starts with allow default, it becomes a denylist that preserves most host capabilities unless they are explicitly removed. That matters because AI coding agents often need file, process and network actions, so permissive profiles leave too much room for an attacker to chain allowed behaviours into an escape. The core technical weakness is not one bug, but the combination of a shared host kernel, broad allowed operations and incomplete deny coverage.

Practical implication: treat allow-default profiles as unsafe for agentic runtimes and move to explicit deny-default confinement.

How Launch Services can hand execution outside the sandbox

The article describes a path where a sandboxed process can invoke Launch Services and cause a file or bundle to be opened by a host service rather than by the sandboxed process itself. Apple's provenance tagging reduces this risk for normal files, but the control depends on metadata that not all filesystems support. If the attacker can place content on a filesystem such as devfs that does not preserve extended attributes, the provenance check breaks down and the handoff can occur outside the intended boundary. This is a classic boundary mismatch between process policy and filesystem behaviour.

Practical implication: restrict access to filesystem types and launch paths that can bypass provenance and execution controls.

Why provenance checks and symlink handling are not enough

The article shows that the fix for one escape pattern does not solve the underlying class of issue when the sandbox's allowed operations still include mount, file creation and bundle construction. A provenance control only works if the file object can carry the tag and if the sandbox prevents the attacker from building an alternate execution route. Symlinks, bundle structure and environment-variable injection can turn a permitted launcher into a code execution trampoline. That means the security model must control both object provenance and the pathways that can transform benign file handling into executable behaviour.

Practical implication: pair provenance controls with strict mount, file-write and launch restrictions for any agent that can read untrusted instructions.

Threat narrative

Attacker objective: The attacker wants unsandboxed host execution from a constrained AI agent so they can reach local secrets, establish persistence and exfiltrate data.

1. Entry occurs when the attacker supplies malicious instructions to an AI coding agent that is already running inside a permissive local sandbox.
2. Escalation follows when the agent uses allowed file and launch operations to build a bundle and trigger host execution through Launch Services.
3. Impact occurs when the spawned process runs outside the sandbox, enabling command execution, persistence and secret exposure on the host.

NHI Mgmt Group analysis

AI coding agents have become a non-human identity problem, not just an application-security problem. Once an agent can read files, launch processes and touch the local environment, it is exercising delegated privilege in ways that should be governed like any other NHI. The issue is not whether the model is clever enough to exploit the host, but whether the runtime boundary prevents that delegation from becoming uncontrolled execution. Practitioners should treat the agent process as an identity-bearing workload with a blast radius, not as a simple tool extension.

Allow-default sandboxing creates a governance illusion because it measures restraint by exception rather than by policy. A denylist can look practical during development, but it leaves the burden on the defender to anticipate every hostile path through the operating system. That is the wrong shape for agentic AI, where adversarial prompts can steer behaviour into adjacent services and filesystem tricks. The practitioner conclusion is straightforward: if the policy model starts permissive, the control already failed.

Filesystem provenance is a fragile trust anchor when execution can be re-routed through services outside the sandbox. The article's devfs example shows a broader principle: metadata-based controls are only as strong as the storage and launch paths that preserve them. This is the same governance gap that appears in other NHI environments when credentials, tokens or certificates are trusted without testing the full lifecycle of how they are created, moved and consumed. Practitioners should validate the whole execution chain, not just the obvious control point.

Agent governance needs a named concept here: sandbox escape debt. That is the accumulating risk created when teams keep patching individual bypasses instead of redesigning the trust boundary around the agent. Each extra allow rule, service exception or launch exception increases the future escape surface. The lesson for identity and security teams is to reduce the number of places where delegated runtime behaviour can cross into unsandboxed execution.

NIST-style governance thinking fits this problem better than feature-led containment. In practice, the question is who owns the runtime boundary, how exceptions are approved, and how agent execution is monitored when the host and the sandbox share the same operating system. That aligns with the NIST AI Risk Management Framework and with NHI governance patterns that demand clear accountability for each delegated action. The practitioner conclusion is to govern the agent as a privileged runtime, not as a harmless assistant.

What this signals

AI coding agents are now close enough to privileged developer workflows that the old distinction between application runtime and identity runtime is breaking down. The practical signal for teams is that confinement controls need to be tested as part of AI governance, not left to endpoint or platform teams alone. The control question is whether the agent can cross from permitted workspace activity into unsandboxed execution without tripping a monitored boundary.

Sandbox escape debt: every extra exception added to make an agent usable increases the chance that future prompt injection or file-based manipulation can turn into host execution. That makes exception management a first-class governance task, similar to privileged access review. Teams should align this work with the NIST AI Risk Management Framework and, where agent identity is in scope, the OWASP Agentic AI Top 10.

The broader programme signal is that AI agent deployment is outpacing the maturity of runtime guardrails. Where agents can reach secrets, local developer tools or launch services, monitoring should assume adversarial intent and look for chain-of-action behaviour rather than single-command anomalies. That is especially important for environments that already treat service accounts and machine identities as high-risk trust anchors.

For practitioners

• Replace allow-default sandboxes with deny-default profiles Audit every AI coding agent that runs locally and remove broad allow rules for file, process, launch and mount operations. If the agent needs a capability, grant only the narrowest path required and test the profile against hostile prompts, not just normal developer workflows.
• Block launch paths that can bypass provenance metadata Review whether the agent can invoke Launch Services, open bundles or interact with filesystem types that do not preserve extended attributes. Explicitly constrain any path that can turn a file write into unsandboxed code execution, especially where provenance checks depend on metadata support.
• Treat AI coding agents as delegated identities Assign ownership, approval and monitoring to the agent runtime just as you would for a service account or privileged workload. Track what the agent can reach, what it can execute and which secrets become exposed if the sandbox boundary fails.
• Test escape paths with adversarial instructions Use red-team style validation to try filesystem tricks, symlink abuse and command injection through normal developer content. The goal is to prove that an attacker cannot move from sandboxed activity to host execution through a path the profile accidentally permits.

Key takeaways

• AI coding agents running in permissive sandboxes can be steered into host execution, which turns a local helper into a boundary-crossing runtime risk.
• The weakness is structural, not incidental: shared-host isolation, launch-service handoff and metadata-dependent provenance checks create a fragile control chain.
• The practical response is to govern agents like delegated identities, using deny-default confinement and adversarial validation of every execution path.

Key terms

• Sandbox-exec: A macOS command-line wrapper that applies a sandbox profile to a process at launch. It can reduce what the process is allowed to do, but it does not create a new security boundary if the profile is permissive or the underlying OS path can be re-routed.
• Allow-default profile: A sandbox profile that starts by allowing everything and then subtracts specific operations with deny rules. It is operationally convenient, but it is not a true confinement model because any unblocked system path remains available to the process.
• Provenance tag: Metadata used to mark files created by a sandboxed process so later execution can be treated with caution. The control is only effective when the filesystem preserves the metadata and when launch paths cannot sidestep the check.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.

What's in the full report

Pillar Security's full blog covers the exploitation steps and sandbox profile details this post intentionally leaves at a governance level:

• The exact sandbox-exec profile structure and the allow-default choice that created the escape surface
• Step-by-step macOS launch chain details showing how Launch Services and provenance handling were bypassed
• The full proof-of-concept workflow for mounting, bundle construction and payload execution
• The operational preconditions that make the bypass work in a real developer environment

👉 The full Pillar Security post covers the macOS profile, the Launch Services bypass path and the proof-of-concept sequence.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners translate delegated access risk into controls they can operate consistently.