What a Sandbox Doesn't Cover When Your Team Uses AI Coding Agents

Our developers have run coding agents directly on their own machines. The tools have real safety features, including a mode where the agent asks before it runs anything.

Here's what happens next. The agent asks to run a build. You approve. It asks to run the tests. You approve. It asks to run a long shell script you don't fully follow, and by then you're approving on reflex. Approve, approve, approve. Eventually a lot of developers switch to a mode where the agent doesn't ask at all.

We call it approval fatigue, and it isn't just us. Anthropic's May 2026 containment report says its telemetry showed Claude Code users approving roughly 93% of permission prompts.

A system that relies on someone reading every permission prompt is fragile and insecure. That's one reason we put our coding agents in a sandbox. When the environment enforces agreed file and network boundaries, developers can give the agent more autonomy with less risk. Notice the word "less." A sandbox is the first layer, not the whole answer.

Follow the paths out of the sandbox

At WWC, we run coding agents in Docker Sandboxes, with our own scripts and configuration for access and credentials. Running it day to day has taught us to look hard at every request that leaves the box.

We tested our network rules by blocking a website and asking an agent to get information from it. The agent found a way. It called the model provider's web search tool, which fetched the page from the provider's side, not ours. Our local block never saw the request.

That doesn't make network rules pointless. What we worry about most is an agent pulling in a malicious instruction from the internet and then sending your data somewhere. Outbound rules can stop a transfer to a destination you've blocked. An allowed service can still give data a way out, and Anthropic's report documents exactly that. When you map your network policy, look at what each allowed service and remote tool can actually do, not just which domains are on the list.

Two more paths deserve attention:

• Credentials. A proxy can keep a secret out of the sandbox and still authenticate requests with it. While keeping secrets out of an agent's reach provides a layer of security, the permissions and scopes associated with that credential also need careful consideration. Read-only repository access and cloud admin rights are very different things. Even when credentials are injected through a proxy, that doesn’t constrain what requests an agent makes.

• MCP servers. Docker's sandbox security documentation notes that local stdio MCP servers run on the host, outside the sandbox VM. Treat each one as a trusted program on the developer's machine, because that's what it is.

Review what leaves the sandbox

An agent edits a build script and the tests pass inside the sandbox. A developer then runs that script on a laptop that has their keys, other projects and production access.

That's the moment the sandbox stops protecting you. The script runs with the laptop's permissions, and the sandbox's boundaries don't follow it. Make that handoff part of your review.

Docker Sandboxes (sbx) support two primary paths to get file changes out of sandboxes and back onto the host machine. The first method involves mounting a directory with the sandbox, which results in file changes getting translated back to the developers machine instantly. The other method keeps changes isolated until the user explicitly pulls them in. Whichever route is taken, it is critical that changes are thoroughly reviewed before application scripts are run directly on a host machine where elevated privileges may live. A notable area of risk is downloading third party dependencies on a host machine, such as npm packages, that can run malicious postinstall scripts. The sandbox may have shielded the users host machine from those scripts, creating a false sense of security.

Decide what runs unattended

For a pilot, pick a small set of tasks the agent can do without asking, within the limits of the sandbox. Actions like running tests, builds, lints, or pulling in tickets via an Atlassian MCP are great examples of tasks an agent can safely run in a sandbox on its own. Keep merges, deployments and infrastructure changes behind a person. This framework is easy to enforce, because higher risk actions typically require credentials that can be excluded from the sandbox environment. Adding a bit of friction to your SDLC can be beneficial for critical actions like deployments and infrastructure changes. Force a human approval and review for these actions.

Finally, make the safe path the easy one. If developers keep needing exceptions to finish ordinary tasks, the setup needs fixing, not the developers.

Start with what an AI coding agent should be allowed to access, then use our team practice guide to plan a pilot.

Tyler Riker and Mike Clancy from our team presented "Sandboxing the Machines: Practical Host Security for AI Coding Agents" at Iowa Code Camp on November 7 in Ankeny. If you'd rather talk through your own setup, get in touch with WWC.