AI coding agent sandboxes are becoming a serious security discipline, not an afterthought
Give an AI coding agent full access to your repository, your shell, and your environment variables, and you have handed it the same blast radius as a compromised CI pipeline. That used to be an acceptable risk when agents ran single-turn, watched-by-a-human tasks lasting a few minutes. It stopped being acceptable the moment agents started running unattended for hours, coordinating multiple sub-agents, and executing shell commands to test their own changes.
The industry's answer has converged on a pattern: run agents inside isolated, disposable environments — sandboxes, containers, or ephemeral git worktrees — rather than directly against the developer's live checkout. This is no longer an experimental precaution. It is becoming baseline infrastructure, and teams that skip it are accumulating risk they haven't priced.
Why the naive approach breaks down
The obvious way to run a coding agent is to point it at your working directory and let it edit files directly. This works fine for small, supervised edits. It falls apart along three axes as autonomy increases:
Credential exposure. An agent with shell access can read .env files, SSH keys, cloud CLI credentials, and API tokens sitting in the environment — not because it intends to, but because a debugging step or a misinterpreted instruction leads it to cat a file it shouldn't. Prompt injection from a malicious dependency, a poisoned README, or a compromised package registry can turn this into active exfiltration rather than an accident.
Irreversible side effects. An agent testing a database migration, running a cleanup script, or experimenting with a deployment command against real infrastructure can cause damage that a code review would never approve — because no one reviewed it before it ran.
State pollution. When multiple agents or multiple attempts share a single working tree, partial edits from a failed attempt bleed into the next one. Debugging becomes archaeology: which changes came from which run?
What the sandbox-plus-worktree pattern actually looks like
The pattern that has emerged combines two separate mechanisms doing two separate jobs.
Git worktrees (or full repo clones) provide isolation at the filesystem level. Instead of an agent editing your one checked-out copy of the repository, it gets its own working tree — a separate directory backed by the same git history but with independent files and branch state. Multiple agents, or multiple parallel attempts at the same task, each get a clean tree. Nothing is committed to the main branch until a human — or a verification step — approves the diff.
Execution sandboxes provide isolation at the process and network level. The agent's shell commands run inside a container, VM, or restricted execution context that has no access to the host's credentials, no route to the internet beyond an explicit allowlist, and no ability to touch anything outside its assigned worktree. Google's Antigravity platform, for instance, runs its /boost deep-reasoning mode inside what it calls ephemeral isolated worktrees specifically so that implementation sub-agents can run build targets and test suites locally without touching the developer's actual working state — and so a failed hypothesis can simply be discarded rather than manually reverted.
Put together, this means an agent can be given genuinely broad permissions — read the whole codebase, run arbitrary shell commands, install packages, hit local services — without those permissions extending to anything the developer actually cares about protecting. The blast radius is the disposable sandbox, not the machine or the account.
The verification step still matters
Sandboxing solves the containment problem, not the correctness problem. An agent can run entirely inside an isolated environment and still produce code that's wrong, insecure, or subtly broken. What sandboxing buys you is the ability to let an agent iterate — write code, run tests, see failures, retry — without every intermediate step needing a human in the loop. The review still has to happen at the point where a diff is proposed for merge, and increasingly that review step is itself automated: independent verification passes that re-run the full test suite against the sandboxed changes before they are ever surfaced to a person.
This is also why the sandbox pattern scales better than permission-prompting. Asking a human to approve every file write or shell command an agent wants to run doesn't actually improve security — it trains people to click approve without reading, the same failure mode that made browser permission dialogs and UAC prompts nearly useless. Isolating the blast radius up front, then reviewing the final diff, is a more honest security model than hoping a tired developer reads every confirmation dialog.
What to actually do about it
If you're running AI coding agents against real repositories today, three changes matter more than any specific vendor tool:
Separate the agent's credentials from your own. Never let an agent execute inside a shell that has your personal SSH keys, cloud provider credentials, or production API tokens available. Use scoped, short-lived tokens for whatever access the agent genuinely needs, and nothing more.
Give agents their own worktree, not your live checkout. Whether via git worktree add, a disposable container per task, or a managed platform that does this for you, make sure a failed or malicious run leaves no trace on the copy of the code you actually work in.
Treat network egress as a permission, not a default. An agent that can install arbitrary packages from the public internet during a sandboxed run is still a supply-chain risk. Where possible, restrict outbound network access to an explicit allowlist rather than leaving it open by default.
None of this is exotic infrastructure — worktrees and containers predate the current wave of AI coding tools by years. What's new is the urgency: agents that operate for hours at a stretch, coordinate with other agents, and execute code without a human watching every step have made the isolation boundary a requirement rather than a hardening exercise you get to later.