← 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 had legitimate write access to stateful production.
  2. The path from the agent to the write had no enforced control point below the prompt.
  3. Once the write happened, there was no cheap, automatic 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.

The missing piece isn’t another, smarter if statement. It is a control point the caller cannot route around.

From tool access to execution intent

Before an agent causes a governed effect, the system needs a structured description of the exact action being requested: the agent identity, capability, provider, model or route, input, context and a request ID that binds retries to the same operation.

That execution intent is untrusted. A field that says agent:billing does not prove the caller is the billing agent, and a requested route does not make that route authoritative. Identity has to come from an authenticated workload boundary; capabilities and destinations have to resolve from trusted state.

Once resolved, policy has three useful answers:

This is the model behind Aegisora, the open-source runtime governance system we’re building. Aegisora turns an agent action into a canonical intent, evaluates it against policy, and preserves the identity, decision, reason, risk and policy version as correlated evidence.

But the decision only becomes enforcement when it sits on the only path to the effect. If a caller can receive BLOCK and then contact production directly, the policy engine is advice. The controlled path must make the upstream call only after ALLOW; BLOCK and ESCALATE must produce no side effect.

That gives us one governance contract across very different actions. What happens after ALLOW depends on whether the effect can be made reversible.

Reversibility is one execution strategy

Terraform and Git are still useful precedents, but not because every agent action needs a branch.

Terraform inserted plan between intent and infrastructure change. Git made edits cheap and merges deliberate. Both changed the structure of execution: work became real enough to inspect before it became real enough to hurt.

Databases can sometimes use the same idea. A governed database action can run against a fork of current state rather than production. Depending on where Postgres lives, that fork might use CREATE DATABASE ... TEMPLATE, a filesystem snapshot on ZFS or LVM, or a cloud provider’s snapshot API. The useful result is not the copy itself; it is the schema diff, row-level changes and statement log a reviewer can inspect before promotion.

Speed decides whether this is a real per-action boundary or another staging environment people learn to bypass. A fork that takes four minutes is operational ceremony. A cheap copy-on-write branch can be created for one task and discarded without sunk-cost pressure.

The underlying research is well established. Neon built a business around branching, Databricks Lakebase brings git-style workflows to Postgres, Xata open-sourced copy-on-write branching over unmodified Postgres, and Columbia’s BranchBench work formalised the branch-mutate-evaluate-compare loop produced by agent workloads.

This does not make database branching the Aegisora architecture. It makes branching one possible executor behind the governance boundary. Policy can allow an operation into an isolated branch, preserve the resulting evidence, and require a separate promotion decision before production changes.

Where reversibility stops

A lot of what agents touch isn’t copyable state. It is an effect.

A sent email is sent. A captured payment is captured. A webhook delivered to a third party is somewhere else now, possibly triggering its own downstream effects. There’s no fork of an SMS and no diff that un-charges a customer’s card.

Those actions need a different executor under the same governance contract. Intercept the call. Hold it. Describe the consequence in language a human can evaluate - this would email 412 customers - and release it only after policy or an authorized review allows it. Where a provider offers a test mode, execute there. Where it does not, be honest about the latency and human decision involved.

The strategy varies with the capability. The invariant does not: no governed effect crosses the boundary without ALLOW.

Where Aegisora is today

The current TypeScript runtime puts governance in front of protected tool and provider execution and records correlated decision evidence. A new Go 1.27 sidecar implements the shared execution-intent contract, verifies scoped and expiring Ed25519-signed policy bundles, atomically activates policy snapshots, and evaluates deterministic deny-overrides rules close to the workload.

It is still an early vertical slice. The local Go sidecar currently makes and records the decision; controlled upstream proxying, authenticated workload identity, durable audit delivery and a FastAPI control plane are the next boundaries. That distinction is deliberate. A decision endpoint should not be marketed as a non-bypassable enforcement path before the network and execution topology make it true.

I’m contributing to Aegisora 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 property of the execution path. Reversible database state can add branch and review beneath that boundary. Irreversible effects can use interception and escalation. The governance decision connecting them remains explicit and testable.

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: