Sandbox escapes in AI coding agents expose auto-run config risk

At a glance

What this is: Pillar Security shows how an AI coding agent sandbox can be bypassed through allowed writes to auto-running workspace configuration files such as .vscode tasks.

Why it matters: This matters to IAM and security teams because a sandboxed AI agent can still trigger host-side execution if workspace trust, file write permissions, and local policy enforcement are not aligned.

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

Context

AI coding agent sandboxing only works if the agent cannot plant configuration that a host environment will later execute. In this case, the security gap is not direct shell escape, but trusted workspace files that can convert a permitted write into unsandboxed execution. For identity and access teams, the question is whether the agent can create durable host action through a path that sits outside normal control assumptions.

The article centers on a familiar governance problem in agentic AI: limiting tool use inside the agent is not enough when another component on the endpoint will trust the agent's output. That creates an identity bridge between agent permissions, local workstation controls, and execution trust, which is exactly where NHI and agentic AI governance starts to matter.

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. The immediate command may still be blocked, but the agent has already planted state that survives the session. That turns a contained interaction into deferred host execution, which is harder to detect and easier to miss in routine review.

Q: Why do coding agents create persistence risk even when sandboxed?

A: Because persistence does not require the agent to escape at runtime. It only needs permission to leave behind trusted files, startup logic, or task metadata that the editor or operating system will later consume. Once that happens, the dangerous action occurs after the sandbox is gone, under the user's privileges.

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. If auto-run files, startup hooks, or task definitions can appear in the workspace and later execute silently, the control is failing. Effective governance should make those writes visible, reviewable, and, by default, impossible.

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.

Technical breakdown

Why auto-run workspace config breaks sandbox assumptions

A sandbox limits what the agent can do at runtime, but it does not automatically govern what happens after the agent writes files to the workspace. In this case, VSCode task files, launch configuration, and settings can cause code or shell commands to execute when a folder opens or a task is triggered. If the sandbox permits those files to be created, the hostile action is deferred rather than blocked. The risk is therefore architectural: the write path is safe enough for the agent, but the read-and-execute path belongs to the host environment, which may trust the file too much.

Practical implication: treat auto-executing workspace files as execution surfaces, not inert configuration.

How allowlists differ from blocklists in agent write controls

A blocklist removes known-bad paths, but agentic systems and developer toolchains expose too many adjacent execution files for that model to hold up. An allowlist reverses the default and only permits the specific paths the agent truly needs. That does not solve every trust problem, because a host can still execute whatever it is configured to trust, but it reduces the chance that a newly discovered auto-run file slips through. In workspace governance, the key question is not whether a file looks suspicious, but whether writing it can alter later execution behavior outside the sandbox.

Practical implication: move from path deny rules to explicit write allowlists for agent-managed workspaces.

Why prompt injection becomes persistence when config writes are allowed

Prompt injection here is not limited to a one-time malicious instruction. If the agent can be convinced to place code into startup or task-related files, the injection becomes persistence that survives the current session. The malicious payload can sit quietly until the user reopens the project or the editor auto-runs the task. That shifts the issue from content safety to execution lifecycle control. For AI coding tools, the boundary that matters is no longer just what the model can say, but what environment state it is permitted to leave behind.

Practical implication: inspect every agent write path for persistence potential, not just immediate command execution.

Threat narrative

Attacker objective: The attacker wants a sandboxed coding agent to plant host-executed configuration that survives the session and runs with the user's privileges.

1. Entry occurs through prompt injection or poisoned workspace content that persuades the coding agent to write configuration files into .vscode.
2. Escalation happens when allowed writes create tasks.json, settings.json, or launch.json that can trigger host-side execution outside the sandbox.
3. Impact follows when the user reopens the project and the auto-run task executes with host privileges, enabling persistence or token theft.

NHI Mgmt Group analysis

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.

Workspace persistence is the named concept this article sharpens. A sandbox can limit immediate damage while still allowing a malicious instruction to survive as configuration, startup logic, or task metadata. That persistence is especially dangerous because it looks like normal developer output until the host consumes it. In NHI and agentic AI terms, this is a trust-boundary failure between an acting system and a later-executing system, which means policy must govern both write authority and downstream execution trust.

Blocklists are too brittle for AI agent workspace governance. The article shows how one unblocked file name can be enough to preserve an attack path. This is the same failure mode seen in many identity programmes that rely on exclusion lists instead of explicit trust boundaries. For security architects, the lesson is that agent-written workspace state should be treated like privileged input and denied by default unless it is explicitly required.

Secure Mode only protects the session it can directly see. Once a file has been written to disk, the host operating system, editor, or task runner can execute it without the agent present. That creates a governance gap between runtime containment and deferred host execution, which is exactly where agent security controls must become stricter. Practitioners should assume that any allowed write to an auto-run surface is a potential post-session execution path.

NHI governance applies here because the agent is acting as a machine identity with durable side effects. The article is not about a human logging in or a traditional service account, but the same lifecycle logic applies: scoped action, trusted state, and later execution risk. That makes agentic AI a governance domain in its own right, where identity, privilege, and persistence have to be managed together. For teams, the conclusion is straightforward: if the agent can leave behind trusted state, it has crossed into identity governance territory.

What this signals

Workspace persistence is becoming a first-class agentic AI risk. As coding agents gain broader write permissions, the relevant control question shifts from prompt safety to whether the environment will execute agent-authored state later. That is a governance and endpoint issue as much as an AI issue, and it belongs in the same control conversation as NIST AI Risk Management Framework mapping and OWASP Agentic AI Top 10 threat modelling.

Agentic AI security teams should prepare for deferred execution paths that look benign at write time. The operational signal is not just whether the model produced unsafe text, but whether it left behind filesystem state that can later activate outside the session. In practice, that means policy needs to follow the write, not just the conversation.

98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments. That trajectory means sandbox escape prevention is not a niche hardening topic, it is a control requirement for scaling AI-coded workflows safely.

For practitioners

• 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. Treat these paths as execution surfaces, not ordinary project files.
• 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. This reduces the chance that a new configuration filename becomes a persistence vector after a tooling update.
• 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. The control objective is to stop deferred execution, not merely to constrain immediate prompt-following behaviour.
• Inspect workspace state for persistence before reopening projects Scan project folders for newly created configuration, startup, or task files before developers reopen them in the editor. This is especially important where agent sessions process untrusted docs, issues, or repository comments.

Key takeaways

• AI coding agent sandboxes fail when trusted workspace files can be written and later executed by the host.
• The core failure mode is workspace persistence, where a benign-looking file becomes a deferred execution path.
• Practitioners need explicit write allowlists, execution approval gates, and pre-reopen workspace inspection to contain the risk.

Key terms

• Workspace Persistence: A condition where an AI agent leaves behind files or settings that continue to influence execution after the session ends. In agentic environments, this is dangerous because the hostile action may occur later through trusted host components, not through the agent itself.
• Auto-Executing Workspace File: A configuration file that causes code or commands to run when a project opens, a task starts, or a toolchain initialises. These files are part of the execution surface and should be governed like privileged inputs, not treated as harmless project metadata.
• Endpoint Trust Boundary: The part of the security model where a device is treated as sufficiently trusted to hold or use sensitive data locally. For offline vault access, the endpoint becomes part of the identity control plane, so device loss, reassignment, and malware risk all matter.

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.

👉 The full Pillar Security post shows the .vscode file chain, execution trigger, and host-side impact path.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security and identity practitioners design controls that hold up when autonomous systems leave durable trust artefacts behind.