Sandbox the AI agent. Or the next incident is already in your repo.

Last week, an AI coding agent (Cursor running Anthropic's Claude Opus) deleted a production database via a Railway API call. The incident took nine seconds. The agent then wrote a confession enumerating the safety rules it had violated.

The post-mortems on this incident, including Jer Crane's excellent write-up, focus on the right systemic failures: destructive API calls without confirmation, blanket-permission tokens, backups stored in the same blast radius as the data, system prompts being treated as security controls.

All of those points are correct. But there's a one-control fix that hasn't shown up in the lessons-learned posts, and it's the most important one:

Sandbox the agent.

If the agent can't reach Railway's API, it can't delete the volume. Period. Every other failure becomes academic.

What "sandbox the agent" actually means

Three layers, each independently sufficient to prevent the incident:

1. Network sandbox. The agent has no outbound internet access by default. Outbound HTTP calls require an explicit allowlist of permitted hosts. backboard.railway.app not on the list = call blocked. The destructive API call literally never leaves the machine.

2. Credential sandbox. The agent runs with zero host secrets in its environment. The Railway CLI token sitting in a file isn't mounted into the agent's filesystem at all. Even if the agent decides to call Railway, it has no auth to do so.

3. Filesystem sandbox. The agent can only read/write a specific scoped directory, say /workspace/current-feature/. Files in other parts of the repo, the home directory, or anywhere else on the host are not visible to the agent. The token discovery never happens.

Any one of these would have killed the Cursor/Railway incident at step one. All three together make it practically impossible for the agent to do damage even if it goes rogue.

Why most AI dev tools don't sandbox by default

The agentic AI coding wave that started in 2024 (Cursor, Claude Code, Devin, Replit Agent, Codex, dozens more) almost universally ships without meaningful sandboxing. The agent runs as the developer's user, with the developer's credentials, in the developer's filesystem, with full network access.

Why this is the default:

Vendors compete on capability, not safety. "Our agent autonomously refactored 47 files and deployed the change" is more demo-able than "our agent operated within a constrained sandbox and required human approval for every privileged operation." The vendor that adds friction loses the demo war.

Sandboxing breaks the "magic" UX. An agent that prompts for permission on every network call or every file write feels less autonomous. Vendors optimized for the wow factor at the cost of the safety boundary.

Setup is genuinely harder. Network allowlists, mount controls, capability dropping. These are unfamiliar to most application developers. macOS sandbox-exec, Linux bubblewrap, Firecracker microVMs, gVisor: all real tools, all underused outside platform engineering circles.

Until recently, most users didn't ask. The Cursor/Railway incident is the first widely-discussed failure that maps cleanly to a sandboxing gap. Before this, the case for sandboxing was theoretical.

A practical sandbox model

Four tiers, in order of friction added:

Easiest (ship today)

Run the AI dev tool inside a VS Code Dev Container or a project-specific Docker container. No host filesystem mount beyond the workspace. No host network bridge. Only proxied access through the container's network namespace. Use a non-privileged user inside the container. No sudo, no host Docker socket.

This alone reduces blast radius dramatically. The agent runs in an environment it can't escape.

Medium (ship this month)

• Network egress allowlist enforced at the container or proxy level. Docker network policies, or a SOCKS/HTTP proxy in front of the agent that only allows whitelisted destinations. The agent cannot make arbitrary outbound calls.
• Secrets manager integration so credentials are fetched on-demand and never sit in files. Doppler, 1Password CLI, AWS Secrets Manager, Vault. Pick one. The token only exists in memory in the wrapper service for the moment of use.
• Per-task ephemeral workspace. Each agent session starts with a fresh clone of just the files it needs, in a temp directory. Nothing persists between sessions.

Strong (for production-touching workflows)

• Agent workloads run in microVMs (Firecracker, Cloud Hypervisor). Kernel-level isolation. The same architecture AWS Lambda, Replit Agent, Modal, and several others use to run untrusted code at scale.
• Capability-based access. The agent gets a credential scoped to only the operations needed for the current task, expiring in 15 minutes. If the task is "add a custom domain to Railway," the agent gets a credential that can do exactly that and nothing else, and it expires.
• Per-task fresh environment. Spawn the sandbox, run the task, destroy the sandbox. No cross-session state. No accumulated permissions. No drift.

Best (where the industry should be heading)

Agentic tasks run in isolated sandbox environments by default. The agent never has direct access to the host. All output is proxied back through a verified channel. Anthropic has been investing in this model with their "computer use" sandbox. Replit's agentic environment is built this way. E2B, CodeSandbox, and Daytona offer it as a service.

This model also opens the door to multi-agent workflows where each agent operates in its own sandbox and they communicate only through a controlled message bus, rather than the current pattern where multiple agents share the same host environment.

What this means for the industry

Three things follow from taking sandbox seriously:

Vendor responsibility shifts. The Cursor/Railway incident has been framed as a vendor failure, and it is. But "vendor" in this context isn't just Cursor and Railway. It's also the OS vendors (Apple, Microsoft, the Linux distributions) that ship default-permissive environments to developers. Default-deny sandboxing for AI dev tools at the OS level is the right long-term fix. macOS App Sandbox is a workable model. We need an "AI agent sandbox" entitlement.

Capability tokens are the next step. Even with sandboxing, the agent eventually needs to do work that touches real systems. The right model is short-lived, narrowly-scoped capability tokens, issued per task, expiring quickly, and revocable. This is closer to how human contractors are granted temporary access, not "here's the root key, please be careful."

Defense in depth still matters. Sandboxing is the meta-control, but it doesn't eliminate the need for the others: destructive operation confirmations, scoped tokens, off-platform backups, audit logging. Sandbox is the layer that catches everything below it before it gets a chance to fail. The other layers are for when the sandbox itself has a bug.

What to do this week

If you run AI dev tools in your environment:

1. Audit which tools have access to host credentials. Cursor, Claude Code, Devin, Codex, whichever ones your team uses. Where do they read secrets from? What's in scope?
2. Move production credentials out of files. Into a secrets manager. Loaded at runtime, never written to disk.
3. Run AI dev tools inside a Dev Container with no host filesystem mount beyond the workspace. This is a 10-minute change.
4. Add a network egress allowlist to that container. Default-deny. Allow only the hosts the current task actually needs.
5. Move production-touching workflows out of the dev tool entirely. The agent shouldn't be running production deploys. That's a separate workflow with separate authentication.

None of this absolves the AI dev tool vendors. But every team can ship the dev container + secrets manager + allowlist combo this week. And the Cursor/Railway incident only happens to a team that hasn't.