Notifications
Clear all
Topic starter
22/07/2026 4:36 pm
TL;DR: A coding-agent sandbox can still be bypassed if the agent is allowed to write auto-executing workspace files, as Pillar Security shows in its analysis of Antigravity Secure Mode and .vscode task handling. The real control problem is not shell confinement alone, but whether host-side configuration will trust agent-written files before execution.
NHIMG editorial — based on content published by Pillar Security: Introducing SAIL 2.0 Framework and The Week of Sandbox Escapes Day 7
Questions worth separating out
Q: What breaks when AI coding agents can write auto-run workspace files?
A: A sandbox breaks down when the agent can write files that another trusted component later executes.
Q: Why do coding agents create persistence risk even when sandboxed?
A: Because persistence does not require the agent to escape at runtime.
Q: How do security teams know whether agent workspace controls are working?
A: Look for whether the agent can create configuration that changes execution behaviour without a second approval step.
Practitioner guidance
- Block agent writes to auto-executing workspace files Prevent AI coding agents from creating or modifying tasks.json, launch.json, settings.json, and similar auto-run configuration unless the use case is explicitly approved and monitored.
- Replace deny lists with explicit write allowlists Define the exact file paths and directories an agent may modify, then deny all other writes by default.
- Separate agent output from host trust decisions Require a human or policy engine to approve any file that can trigger task execution, startup behavior, or shell commands.
What's in the full article
Pillar Security's full research covers the operational detail this post intentionally leaves for the source:
- The exact proof-of-concept file sequence used to turn a sandboxed write into host-side execution.
- The full .vscode configuration payloads that make folder-open execution possible.
- The broader Week of Sandbox Escapes context showing how adjacent workspace trust failures compose into attack paths.
- The source article's walk-through of the host privilege boundary that the sandbox does not control.
👉 Read Pillar Security's full analysis of sandbox escapes in AI coding agents →
AI coding agent sandbox escapes: is auto-run workspace config the weak point?
Explore further
22/07/2026 4:41 pm
Agent write permissions are now an execution control problem, not just a data loss problem. When an AI coding agent can write files that a host later trusts, the security boundary has already moved. The important question is no longer whether the model can be sandboxed, but whether it can plant state that becomes executable after the sandbox ends. For practitioner programmes, this reframes agent governance as a lifecycle issue across write, trust, and runtime phases.
A question worth separating out:
Q: Who is accountable when an AI agent plants a host-executed task file?
A: Accountability should sit with the team that defined the agent's allowed write and execution boundaries, not only with the end user. If the platform permits agent-written configuration to trigger host execution, the control owner has failed to separate content generation from execution trust. That is a governance design issue, not just an operational mistake.
👉 Read our full editorial: Sandbox escapes in AI coding agents expose auto-run config risk
