Notifications
Clear all
Topic starter
22/07/2026 4:38 pm
TL;DR: AI coding agents can be pushed past sandbox boundaries through reachable local daemons, with one Docker socket path enabling host-level execution and file access across Codex, Cursor, and Gemini CLI, according to Pillar Security. The control lesson is that deny-default profiles are not enough when privileged services remain reachable from the agent’s runtime context.
NHIMG editorial — based on content published by Pillar Security: Introducing SAIL 2.0 Framework and The Week of Sandbox Escapes Day 2
Questions worth separating out
Q: What breaks when an AI coding agent can reach privileged local daemons from a sandboxed workspace?
A: The sandbox stops being the real trust boundary.
Q: Why do conversational AI systems create new identity and access risks?
A: Because they can combine data retrieval, decision-making, and execution in a single interaction.
Q: How do security teams know whether sandbox controls are actually working?
A: They know by testing for alternate expressions of the same action, not by checking whether one blocked syntax case still fails.
Practitioner guidance
- Map reachable daemons on agent hosts Inventory Docker Desktop, local orchestration services, and any privileged sockets exposed to AI coding agents.
- Separate agent workspaces from host-sharing paths Do not allow autonomous coding agents on developer machines that also expose host-mounted home directories, shared volumes, or convenience file bridges.
- Treat local service accounts as privileged identities Apply PAM-style governance to local daemons and helper services that can act for the agent.
What's in the full report
Pillar Security's full research covers the operational detail this post intentionally leaves for the source:
- The exact proof-of-concept chain used to move from sandboxed agent execution to privileged Docker activity on macOS.
- Vendor-by-vendor response differences, including the fix path, triage position, and documentation stance across the affected tools.
- The full sandbox and socket interaction sequence, including how the agent reaches the Docker daemon and why the boundary fails.
- The practical containment recommendations and follow-on research in The Week of Sandbox Escapes series.
👉 Read Pillar Security's research on sandbox escapes in AI coding agents →
Docker socket sandbox escapes in coding agents - what teams need to know?
Explore further
22/07/2026 4:42 pm
Sandbox policy is not the control boundary if the agent can reach privileged services. The article shows that deny-default profiles can block direct process abuse while still leaving a reachable daemon free to act on the agent’s behalf. That creates a hidden trust bridge between the contained runtime and the host. Practitioners should stop measuring agent safety only at the sandbox layer and include daemon reachability in the control model.
A question worth separating out:
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.
👉 Read our full editorial: Sandbox escapes in AI coding agents expose host execution risk
