← blog

Sandboxes contain the process. Nothing contains the write.

Aug 9, 2026

Three incidents from the last year, in the order they became public.

Amazon’s Kiro agent inherited elevated engineer permissions, bypassed a two-person approval requirement, and autonomously deleted and recreated a live production environment. Cost Explorer in mainland China was down for thirteen hours.

Cursor’s IDE agent deleted around seventy git-tracked files with rm -rf. The developer had issued an explicit instruction: DO NOT RUN ANYTHING. Cursor later confirmed the cause as a critical bug in Plan Mode constraint enforcement.

A developer connected Claude Code to a live Supabase instance. The agent ran a Prisma migration with --shadow-database-url pointed at production. Prisma did exactly what that flag means - it reset the shadow database and replayed migration history. The shadow database was production.

Read those again and look for what they share. It isn’t the model, the vendor, or the prompt.

The shape

In all three the agent was doing something it was permitted to do. No privilege escalation, no exploit, no injected payload that tricked a parser. Kiro’s permissions were real and inherited. Cursor’s rm -rf was a valid command run by a process allowed to run commands. The Prisma flag did precisely what it’s documented to do.

Each incident is the same three facts stacked:

  1. The agent held write access to something stateful.
  2. There was no gate below the prompt layer.
  3. There was no way back.

The third is the one nobody talks about. We spend a lot of energy on the first two - scoped tokens, least privilege, approval flows, better system prompts - and almost none on the third. Every mitigation in common use is an attempt to make the bad write not happen. None of them assume it will happen anyway.

It always happens anyway. That’s what production is.

The response so far has been quiet in a way that bothers me. These reached the front page of Hacker News and the pages of Fortune, and no AI coding tool vendor has published a detailed post-incident review for any of them. A February 2026 study out of Cambridge and MIT found four agents in their entire index publish agent-specific safety documentation. Four.

The numbers keep moving in the meantime. Somewhere between 54% and 65% of organisations report a confirmed or suspected AI agent security or data incident in the past twelve months. Eighty-one percent of agents are in operation. Fourteen point four percent went to production with full security approval. Those last two describe the same population.

Why the sandbox doesn’t help

2026 was the year the agent sandbox market resolved. E2B, Modal, Daytona and Vercel Sandbox all landed within months of each other. They’re good products built by serious people, and they’re now differentiating on cold start latency - Daytona quotes about 90ms and the others are close enough that benchmark posts need three decimal places to find daylight. Anthropic shipped self-hosted sandboxes for enterprises in May.

A sandbox contains a process. It gives the agent a filesystem it can wreck, a network it can hammer, and a memory space it can’t escape. If the agent generates code that forks a hundred thousand times, the sandbox absorbs it. That’s real, and it solved a real problem.

Now look at Kiro through that lens. Put its agent in a perfect microVM with zero escape surface. The credential it inherited still works. The API call still leaves the sandbox - that’s the entire point of a network - and still reaches a real control plane, which still deletes a real environment.

The sandbox contained the process. The process was never the dangerous part.

That isn’t a criticism of sandboxes, it’s a statement about layers. Isolation and reversibility are different problems. The market solved one of them and mostly stopped, because the solved one is easier to demo.

Why the gateway doesn’t either

The other answer on offer is the MCP gateway. There are maybe a dozen now, and the good ones do what they claim: sit between an agent and the tools it can call, enforcing authentication, scoping, rate limits and audit on the invocation.

That’s authorization of which tool gets called. It isn’t governance of what the call does.

A gateway that correctly allows postgres.query has no opinion about whether the query is SELECT 1 or an UPDATE with the WHERE clause omitted. Both are the same tool. Both are authorized. The gateway’s job finished before the interesting part started.

The same gap exists a layer down. OPA and Gatekeeper are excellent and I’d run them in any cluster, but they evaluate Kubernetes admission - they decide whether a manifest may be applied. They don’t sit on a Postgres connection at runtime and reason about a statement’s blast radius. Microsoft’s Agent Governance Toolkit, released in April, intercepts agent actions before execution with policy in Rego, Cedar or YAML. Closer, and still stops at the decision. Allow or deny. If you allow and you were wrong, you’re back to having no way back.

Every tool in this space is a better if statement in front of the action. None of them change what happens after.

Two precedents

We’ve solved this shape of problem twice, and both times the fix was structural rather than a better guess at intent.

Terraform did it for infrastructure. Before plan, changing infrastructure meant running a command and finding out. After plan, there’s a mandatory step between intent and effect where a human reads a diff. Nobody argues about whether an engineer should be trusted with apply, because the question dissolved - they see what it will do first. The trust conversation got replaced by a diff.

Git did it for code. Every change happens somewhere else first. The branch is cheap, the merge is deliberate, and throwing work away costs nothing but the work. We don’t debate whether a developer may edit a file, because editing a file no longer means changing the codebase.

Both are the same move: insert a place where the change is real enough to inspect and not yet real enough to hurt.

Live state never got that move. An agent writing to Postgres in 2026 is a developer editing files on the production server in 2004.

The primitive

Branch, act, diff, promote.

Branch means forking the database. Not a dump into a staging environment that drifted three weeks ago - a fork of current state, cheap enough that you do it per task rather than per sprint. Postgres offers several mechanisms depending on where it lives: CREATE DATABASE ... TEMPLATE, a filesystem snapshot on ZFS or LVM, a cloud provider’s snapshot API. They differ enormously in speed, and speed is the whole game. A fork that takes four minutes is a staging environment with extra steps.

Act means the agent connects and works. It doesn’t need to know, cooperate, or import an SDK. It gets a connection string and behaves exactly as it would against production, because as far as it can tell it is production. Every statement is parsed and recorded on the way through - parsed with Postgres’s own parser, not a regular expression, because a regex-based SQL guard is a headline waiting to happen.

Diff means comparing the branch to the source. Schema changes from the catalog. Row-level changes for tables that actually moved. The statement log, with anything policy blocked or flagged. This is the artifact a human reads, and it’s where the whole idea lives or dies. A diff nobody can scan is a diff everybody rubber-stamps.

Promote or discard means applying the change to real state, or deleting the branch and losing nothing. Discarding has to be genuinely free, or people start promoting out of sunk-cost reflex.

None of this is novel in isolation. Copy-on-write branching is well established - Neon built a business on it, Databricks Lakebase brings git-style branching to Postgres, Xata open-sourced a copy-on-write implementation over unmodified Postgres. Columbia’s BranchBench work in April formalised the branch-mutate-evaluate-compare loop that agent workloads actually produce.

What none of them do is protect a database you already have. Every one requires you to migrate onto it first. That’s a reasonable business decision, and it leaves nearly all of the world’s Postgres - on RDS, on a Hetzner box, in a CloudNativePG cluster, on someone’s laptop - with no answer at all.

What can’t be branched

This is the part it would be easy to leave out.

Branching works because databases are state, and state can be copied. A lot of what agents touch isn’t state. It’s an effect.

A sent email is sent. A captured payment is captured. A webhook delivered to a third party is somewhere else now, in a system you don’t control, possibly having triggered its own downstream effects. There’s no fork of an SMS. There’s no diff you can review afterwards that un-charges a customer’s card.

Anything in this space that implies otherwise is lying to you, and the first person to find the lie will say so in public.

So irreversible effects need a different mechanism, not a rebranded one. Intercept the call. Hold it. Describe what it would do in language a human can evaluate - this would email 412 customers - and release it only on approval, or satisfy it against the provider’s test mode where one exists.

That’s a worse experience than branching. It needs a human more often, it adds latency, and it doesn’t scale the same way. It’s also the honest answer, and it’s the difference between something that works on the things it can fork and something with a coherent story for everything an agent can reach.

Where this is

Stunt is the thing described above. It’s early. It speaks the Postgres wire protocol, forks a database, records what the agent did, and shows you the diff before anything reaches real state. It’ll be open source. It isn’t the whole picture yet, and I’d rather say that here than have you find out.

I’m building it because the incident list is going to get longer, and because “can the agent touch production?” should stop being a judgement call about trust and become a question about configuration. Terraform did that for infrastructure. Git did it for code. State is next, and it’s late.

If you have a story about an agent doing something to your data you didn’t expect, I want to hear it. That’s not a marketing line. The failure modes determine what gets built next, and there’s no public corpus of them, because nobody publishes their post-mortems.

Sources

The incidents:

The numbers:

Sandboxes:

Gateways and policy:

Branching:

Regulatory timing: