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.
Editorial analysis by NHI Mgmt Group, based on content published by Pillar Security: “The Week of Sandbox Escapes Day 7: A time bomb in .vscode: bypassing Antigravity's Secure Mode”.
Key questions
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 auto-run workspace files create a sandbox escape risk?
A: They create risk because the host executes them with user trust after the agent’s sandboxed action is over.
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
- Restrict writes to auto-executing workspace files Deny AI coding agents permission to create or modify task, launch, hook, and similar workspace config files unless the path is explicitly approved for that workflow.
- Move from blocklists to path allowlists Define a minimal set of writable directories for the agent and remove blanket access to project config locations such as .vscode and other execution-bearing folders.
- Review host-side auto-run features separately from sandbox policy Inventory editor and IDE features that execute on open, save, or project load, then require human approval before those mechanisms can consume agent-authored files.
Bottom line: The central failure is not sandbox breakout in the narrow sense, but host trust in configuration written by the agent.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/07/2026 4:41 pm
Agent-written configuration is now part of the attack surface: once an AI coding agent can author files that the host later executes, workspace config becomes a governance boundary, not just a convenience layer. The security model must distinguish between files the agent can write and files the runtime will trust. Practitioner conclusion: any editor or IDE workflow that auto-runs project config needs explicit control over agent-authored writes.
A few things that frame the scale:
- Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
A question worth separating out:
Q: Should organisations use blocklists or allowlists for AI agent write access?
A: Allowlists are the safer default because blocklists only stop the dangerous files someone remembered to name. In agentic environments, the missed file is the one that becomes the bypass. Organisations should permit only the workspace paths the agent genuinely needs and treat everything else as non-writable.
👉 Read our full editorial: Sandbox escapes in AI coding agents expose auto-run config risk