AI Coding Agents Need Sandboxes Before They Need Better Models

Last month I gave an agent full shell access on a side project, stepped away, and came back to find it had run npm install on a package I didn't recognize — something pulled from a typo-squatted namespace with a name close enough to fool it. Nothing bad happened, as far as I could tell. But I lost twenty minutes auditing my own machine instead of shipping anything, which is the opposite of what the tool was supposed to give me.

Claude and GPT-5-class models are genuinely solid at working through multi-step coding tasks now. The problem was that nothing sat between "the model decided to run a command" and that command actually executing, on my laptop, with my permissions.

Everyone wants to talk about which model reasons best. Almost nobody asks what happens the day the best-reasoning model is confidently wrong.

Two failure modes

Agents fail in ways that tend to get lumped together but really aren't the same thing.

One is a capability failure — bad logic, a misread requirement, a function that just doesn't do the job. Annoying, sure, but you read the diff, reject it, move on. Nothing's lost but time.

The other is an execution failure: the agent deletes something it shouldn't have, overwrites a .env file, pushes straight to main, pulls in a compromised dependency, or fires off a command whose effects land somewhere outside the project folder entirely. You often don't get a chance to catch this one before it happens, because the whole appeal of an "autonomous" agent is that it acts first and reports back after.

Better models shrink the first category. They barely touch the second. A more capable model can still hallucinate a destructive command with total confidence — arguably it does this more smoothly now, which if anything makes the mistake easier to trust and harder to notice.

What people are running

Cut through the marketing and most agentic coding setups fall into one of three buckets.

Straight in your shell, under your own user account. Quick to set up. Also means the agent inherits everything you have access to — SSH keys, cloud credentials sitting in ~/.aws, active browser sessions if it can reach them, write access across your whole filesystem.

Inside Docker, but usually with the project directory bind-mounted and no real limits on outbound traffic. An improvement, technically. Still not much of a wall if the container can talk to the internet freely and something manages to trick the agent into reaching out.

A proper ephemeral VM, the CI-style approach. Safest of the three, and also the one almost nobody bothers with day to day, because it's slower to wire up and adds friction to every iteration.

Most people land on the first option, because it's the one that works with zero extra setup. It's also the one offering the least protection.

Here's the part that doesn't get enough attention: the agent doesn't need bad intentions to cause damage. It just needs to read something bad. A poisoned README, a scraped answer from some forum, a dependency with a shady postinstall script — any of these can push an agent toward a command that looks perfectly reasonable to the model and completely wrong to you. Prompt injection through untrusted content isn't some far-off hypothetical for these tools. It's just what tends to happen once you hand a language model shell access and let it browse.

Smarter models don't fix this, they shift it

This is the counterintuitive bit. You'd expect better reasoning to lower risk across the board. Instead it just moves the risk somewhere else.

As models get better, teams reasonably let them run longer stretches without checking in. Early copilots suggested one line and paused. Current agents plan out a task, run through five or ten steps, and only surface once they think they're done — that's the entire selling point, less babysitting required.

But less babysitting means more real actions happen in the gap between human checkpoints. If step three out of ten goes wrong and nobody looks until step ten, you've now got nine additional automated actions building on top of a bad call before anyone catches it. A weaker model that got reviewed after every step would, in practice, have been the safer choice — even with worse reasoning.

So the pattern holds: model quality climbs, autonomy climbs with it, and the blast radius of any single mistake climbs too, unless something else is putting a ceiling on it.

What needs to be in place

A sandbox is more than tossing the process into Docker and moving on. Real containment needs several pieces working together.

Filesystem isolation that holds up. The agent should see only the project it's working on — not your home directory, not neighboring repos, not your dotfiles. Writes ideally land on an overlay or snapshot you can discard entirely if a session goes wrong.

Network access denied by default. This single change eliminates most exfiltration risk from prompt injection on its own. If the agent can't reach arbitrary hosts, it barely matters if something tries to trick it into trying.

Actual resource limits. CPU, memory, wall-clock time capped. A runaway loop shouldn't be able to fork-bomb a host or quietly run up a serious cloud bill while no one's watching.

Credentials that are scoped and short-lived. Not a master API key sitting in an environment variable for the whole session — a narrow token, issued right before it's needed, expiring soon after.

Logs kept somewhere the agent can't touch. Every command run, every file opened, recorded outside the sandbox itself, so if something goes wrong you can reconstruct it instead of guessing.

Firecracker microVMs, gVisor, and OCI containers locked down with tight seccomp profiles each handle part of this. What's missing is any of it being the default in the tools developers actually use. Right now it's an advanced setting most people skip, because skipping it saves one command and the risk feels abstract until it isn't.

This is a workflow decision

None of this argues against agentic coding tools, and it doesn't replace reviewing what they produce. It changes what that review is actually protecting. If an agent goes off track inside an isolated, network-restricted, disposable environment, the worst outcome is: task failed, discard the sandbox, try again. If it goes off track on your real machine, the worst outcome is something you're explaining to your team on Monday.

A setup worth aiming for, if you're adopting this seriously:

• One disposable sandbox per task rather than per session, so nothing outlives its purpose
• Every diff reviewed before merging, no "it's probably fine" exceptions
• Network access off by default, opened per dependency only when there's a specific reason
• Credentials issued just-in-time, scoped as tightly as the task allows
• Command and file-access logs kept outside the sandbox regardless of outcome

That's more work up front than pulling an agent CLI and pointing it at a repo. It's also the gap between occasionally getting a bad diff and occasionally getting a security incident.

Which one matters more

Model providers will keep shipping better reasoning and longer context windows, and that's a good thing — this isn't an argument against it. But none of it touches the risk most teams are already carrying: agents with real execution power and nothing meaningful containing them.

Sandboxing doesn't show up on a leaderboard, so it gets a fraction of the attention model releases do. But it's the piece that decides whether handing an AI the ability to run commands turns into a genuine productivity gain or a liability sitting one bad prompt injection away from becoming your problem. Before picking which model to wire into an agent, it's worth working out what your setup actually does on the day that model is confidently wrong.