Sandboxing AI Agents: Isolation, Security, and Prompt Injection
A coding agent runs a workload, not a single executable. The security boundary must follow that workload through dependencies, tests, local servers, and browser sessions.
Contain the process tree
One task can start a package manager, install scripts, compiler plugins, tests, a dev server, and a browser. Wrapping only the agent executable leaves an escape route through its children. A Git worktree separates the checkout but grants no filesystem or network confinement. The outer boundary needs to cover all processes involved in the task, while the policy can grant narrower permissions to particular tools.
A browser belongs inside that model. It executes page code, carries session state, and may connect to a local dev server. A browser running on the host can expose the developer's normal profile or reach a different localhost than the boxed server. A fresh browser profile inside the same task boundary avoids that mismatch.
Consider an apparently harmless dependency update. The agent runs the package manager; an install script reads environment variables, then tests start a local service, then the agent opens a documentation page in a browser. A final diff may contain only one lockfile change. The security question is which of those subprocesses could see the developer's home directory or contact the network. The scope of the box must be defined before the first command, not added after a suspicious step appears.
Choose isolation by the failure to prevent
Workspace separation addresses accidental edits to the parent checkout. Process isolation restricts host file access. Supervised execution can enforce network rules on raw traffic. A container also fixes a toolchain image; a microVM adds a guest kernel boundary at greater cost. These are different guarantees, and availability depends on the host. Check the selected tier and enforced policy for the actual run; the isolation reference records the limits.
Even strong local isolation cannot protect a secret sent to an allowed model endpoint. Credentials should remain outside the writable box and be supplied only through constrained host-side mechanisms. If source must not leave the machine, model egress must be disabled or served locally.
A tier name alone is not evidence of enforcement. The host may lack the relevant Linux feature, a network rule may be unavailable, or the run may have fallen back to a weaker mode. The run's status should report what was actually enforced. Different tasks justify different costs: a routine local edit may value quick startup, while running an unknown pull request may justify a separate guest kernel and a stricter outbound policy.
Prompt injection is an authority problem
A malicious README, issue comment, page, or tool result can tell the agent to read credentials, change a policy file, or send data away. Detecting the sentence is useful but fragile: the attacker can rephrase it. The stronger control is to keep the requested action outside the agent's authority. A page can suggest exfiltration, but the box should lack access to host credentials and disallow the destination.
Policy must be resolved outside the workload's writable paths. Otherwise the agent can rewrite the rule that is supposed to constrain it. Network controls must account for local services and DNS behavior as well as public hosts. Denied actions are worth recording because an attempted escape may leave no Git diff.
Imagine a malicious page instructing the agent to "verify setup" by reading a token file and sending it to an attacker-controlled endpoint. A classifier may or may not recognize the instruction as hostile. The durable defenses are that the token file is inaccessible and the destination is disallowed. If the agent is permitted to read the token for the legitimate task, policy design becomes harder: it must narrow where that token can be used, and the run needs close review. Isolation reduces available authority; it does not magically classify intent.
Containment leaves other risks
A confined agent can still write vulnerable code, choose weak tests, or produce a persuasive but inaccurate report. Human review and application-level tests remain necessary. Host-kernel tiers also continue to trust the host kernel; a microVM moves, but does not eliminate, the trusted computing base.
The practical design is to let the agent work in a disposable environment, then cross a narrow review boundary with a proposed patch and execution record. The sandboxed workflow guide has the commands and policy examples. The companion audit essay explains what the reviewer can infer from the records.
Review the runAuditing AI Agent Workflows with Execution Evidence
Examine what an execution record can and cannot establish.
Run one bounded task
Use a disposable box and review its policy before the agent starts.