TL;DR: AI coding agents running under allow-default macOS sandbox profiles can cross from confined workspace actions into unsandboxed host execution, with Launch Services and filesystem quirks creating escape paths, according to Pillar Security. The lesson is not that sandboxes are useless, but that deny-by-default policy and tighter execution boundaries are the only durable answer.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Pillar Security's research: AI coding agents on shared-host macOS sandboxes can escape confinement through Launch Services and filesystem edge cases.
Why it matters: IAM and AI security teams should treat agent execution boundaries as a governance problem, because sandbox policy that shares the host kernel can still be bypassed by host-level services and mis-scoped allowances.
Context
AI coding agents expand the trusted computing base because they can read files, write files, and run commands on behalf of the user. In this case, the security gap is not the presence of a sandbox, but the assumption that an allow-default profile can safely contain a process that still interacts with host services and filesystem features.
The article sits at the intersection of AI agent governance and endpoint containment. For practitioners, the important question is whether the runtime boundary is actually enforced at launch and execution time, or whether the agent can still reach unsandboxed host processes through permitted system interfaces. This is a typical failure mode for convenience-first sandboxing.
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 create more host-execution risk than ordinary sandboxed apps?
A: AI coding agents are active decision-makers that read instructions, manipulate files, and invoke commands during runtime. That makes every permitted host service part of the attack surface. The risk increases when execution brokers can relaunch content outside the sandbox, because the agent can use legitimate system behavior to cross the boundary.
Q: How can security teams tell whether sandbox and proxy controls are actually containing an AI agent?
A: They need to test more than the sanctioned upload command. If the agent can reach the internet through a different client, language runtime, or terminal path, the boundary is incomplete. A useful test is whether the agent can still move a file when the most obvious network route is denied.
Q: Should organisations prioritise deny-default sandboxing over patching known bypasses?
A: Yes. Patch work closes individual bypasses, but it does not fix the underlying governance error of permitting too much by default. Deny-default sandboxing forces every capability to be justified up front, which is the only sustainable model when AI agents can combine host services and filesystem quirks into an escape path.
Technical breakdown
Why allow-default sandbox profiles fail for AI agents
A macOS sandbox profile constrains a process at launch, but it does not change the process into a separate security boundary. With allow-default policy, the profile starts from permit and subtracts controls, so anything omitted remains available if the operating system allows it. That is dangerous for AI coding agents because they are active runtime interpreters of instructions, not passive viewers. Once the agent can issue file, process, or service requests, the sandbox is only as strong as the deny list. If the host kernel and user session remain shared, escape becomes a matter of finding an allowed path rather than breaking confinement outright.
Practical implication: Treat allow-default sandboxes as policy hints, not hard containment, when agents can invoke host services.
How Launch Services becomes an escape path
Launch Services is a host-level execution broker. If a sandboxed process can hand off a file to that broker, execution may occur outside the original sandboxed context. The article shows why provenance tagging tries to stop that by marking files created inside the sandbox, but the protection breaks when the filesystem cannot preserve the tag. That means the confinement problem shifts from process policy to filesystem semantics and execution brokers. For AI agents, this matters because the attack surface is not only the agent process itself, but every trusted helper service that can relaunch content with different privileges or inheritance rules.
Practical implication: Review any permitted launch or open path as a potential privilege boundary, not just the agent process.
Why filesystem quirks turn policy gaps into host execution
The bypass works because devfs and symlinks do not preserve the provenance metadata used to block execution. If the sandbox does not explicitly deny mounting or writing to those surfaces, an attacker can build an app bundle that looks acceptable to Launch Services while escaping the intended trust checks. This is a classic control inversion: the profile assumes default denial will be added later, but the operating system exposes many alternate representations of the same object. For AI agents, that means file system constraints and execution constraints must be designed together, or one will undo the other.
Practical implication: Block alternate filesystem paths and provenance bypasses before relying on sandbox enforcement for agent execution.
NHI Mgmt Group analysis
Allow-default sandboxing is the wrong trust model for AI coding agents. The core failure is not a missing patch, but an inverted policy assumption that treats confinement as subtractive. AI agents do not behave like ordinary desktop apps because they actively interpret instructions and can chain host services in real time. Practitioners should assume the boundary must be deny-first, not permit-first.
The real governance gap is execution delegation, not file access alone. The article shows that a sandboxed agent can hand execution to Launch Services and regain unsandboxed host context. That means agent governance has to include all trusted relays, not just the primary process. In identity terms, this is an authorisation problem for runtime delegation chains, not only an endpoint hardening problem.
Provenance failure is the named concept here: launchable objects can lose trust metadata across unsupported filesystems. When the operating system cannot preserve the tag that enforces trust, the control stops being meaningful. That makes filesystem choice part of agent security architecture, especially where AI agents can create or modify executable content. Practitioners should treat metadata-preserving storage as a security requirement, not an implementation detail.
Agent sandboxing needs to move from policy exceptions to execution whitelisting. The more exceptions a profile needs, the more the sandbox becomes a description of what went wrong after the fact. Deny-default, tightly enumerated execution paths, and explicit control over brokered launches are the only durable design pattern here. That is the practical path for secure AI agent containment.
Endpoint containment for AI agents is now part of AI governance. The article is not just about macOS mechanics. It shows that an AI agent with filesystem and execution reach can turn a convenience feature into a host escape path. Security teams should treat agent runtime boundaries as a governed control surface, not an engineering preference.
From our research library:
- Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.
- Read next: Zero Trust for AI Agents
What this signals
Agent sandboxing is now an execution-governance problem, not only an endpoint problem. AI agents that can invoke host services create a boundary question for every permitted launch path, and that changes how teams should review containment on managed laptops. The control objective is no longer just to restrict files and commands, but to prevent brokered execution from becoming a hidden privilege escalation path.
Execution provenance is a security dependency, not a convenience feature. When a sandbox relies on metadata that some filesystems cannot preserve, the trust model becomes conditional. Security teams should treat provenance-preserving storage and explicit launch restrictions as part of the agent control plane, especially where a single runtime can combine user context with host context.
AI agent identity controls need to align with launch controls. If an agent can ask one subsystem to execute content on its behalf, identity governance has to include delegated launch authority as well as direct command scope. The practical signal is simple: if a sandbox profile can still be sidestepped through a permitted broker, the identity boundary has already failed.
For practitioners
- Adopt deny-by-default agent sandboxes Replace allow-default profiles with allowlists that enumerate only the file, process, and service calls the agent truly needs.
- Restrict brokered execution paths Audit Launch Services, open-based launches, and any other host broker that can relaunch content outside the sandbox boundary.
- Block filesystem paths that break provenance Prevent agents from mounting or writing to filesystems that do not preserve provenance metadata, including devfs-style escape surfaces.
- Treat agent runtime as a governed identity boundary Define which agent actions may cross from workspace context into host execution and require explicit approval for any delegated launch.
Key takeaways
- AI coding agents enlarge the attack surface of shared-host sandboxes because they can combine file operations, command execution, and trusted launch services into a boundary crossing.
- The article's key failure mode is allow-default confinement, which turns the sandbox into a denylist and leaves host-execution paths open unless they are explicitly blocked.
- Deny-default policy, provenance-aware storage, and tighter control over brokered execution are the controls that would have limited the escape path described here.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on an AI agent crossing containment through delegated execution and privilege boundaries. |
| ASI02 — Tool Misuse | The attack relies on an agent using permitted tools and host services in ways the sandbox did not intend. | |
| Recommendation — Constrain agent permissions and delegated execution paths to prevent identity and privilege abuse. Audit agent tool access so brokered launch and filesystem operations cannot be abused for escape. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | This is a governance failure around who controls agent execution boundaries and approvals. |
| Recommendation — Define accountable ownership for AI agent runtime boundaries and approval gates. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | The escape chain converts restricted execution into broader host-level access. |
| Recommendation — Map sandbox escape paths to privilege escalation and lateral movement techniques in detection engineering. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The problem is overly broad permissions that let the agent reach host services and execution brokers. |
| Recommendation — Tighten permissions so agents can only invoke the exact services and actions they require. | ||
Key terms
- Allow-default sandboxing: A confinement model that starts by permitting most actions and then removes specific dangerous ones. It is easy to maintain but fragile for AI agents because any omitted path may remain usable, especially when host services or filesystem behaviors provide alternate ways to execute code.
- Launch Services: A macOS execution broker that opens files and launches associated applications through system-managed handoff. In sandbox escape scenarios, it can become a privilege boundary because the process handling the launch may not inherit the original sandbox constraints.
- Provenance metadata: Structured information that shows where data came from, how it was classified, and how it moved through a system. In AI platforms, provenance helps security and compliance teams reconstruct model inputs, preserve trust boundaries, and investigate whether outputs were influenced by restricted sources.
- Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security for practitioners responsible for runtime access boundaries. It helps security and identity teams build the control discipline needed when software agents can act across host and workspace contexts.
Published by the NHIMG editorial team on July 22, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org