Amazon Kiro
The agent inherited elevated engineer permissions, bypassed a two-person approval requirement, and autonomously deleted and recreated a live production environment.
13-hour outage
Postgres first · Apache 2.0
Your agent doesn't need permission.
It needs an undo button.
Stunt routes every AI agent write onto a branch of your real data, records what it did, shows you the diff, and promotes only when you say so.
Single binaryNo accountRuns on your laptopNever the system of record
What already happened
Three incidents, one missing component
These are not hypotheticals. Every one of them happened in production, in 2026, to teams who were being careful.
Cursor
The agent deleted roughly 70 git-tracked files after the developer had issued an explicit "DO NOT RUN ANYTHING" instruction. Vendor confirmed a constraint-enforcement bug.
~70 files, no undo
Claude Code + Prisma
A migration command pointed --shadow-database-url at production. The shadow database was reset before migration history was replayed - against the wrong target.
Production database reset
Every one ran inside a working sandbox, on a legitimate connection, executing syntactically perfect statements.
Sandboxes contain the process. Nothing contains the write. That gap is the entire product.
How it works
Branch, act, diff, promote
The agent is handed a connection string and behaves exactly as it would against production. It needs no SDK, no cooperation, and it is not told the difference. Everything it does lands on a copy.
a copy - free to throw away production - the only edge that needs a decision
Terraform put a plan step between intent and effect
Git made every change happen somewhere else first, then merge. Stunt does that for live state: nothing an agent does lands until someone has seen what it would do.
If Stunt fails, the branch fails
It is never the system of record. Your real database is untouched and your real connection string still works. That property is deliberate, and it is why this is safe to put in front of something that matters.
The honest part
Some things cannot be un-sent
A branch only works when the state can be forked. A sent email is sent. A captured payment is captured. A webhook delivered to a third party is gone. So there are two paths through the gate, not one.
Branchable state
Fork it, and decide afterwards
Databases, object storage, clusters. The agent works against a copy, you review a real diff, and promotion is a separate, deliberate act.
- fork
- →
- diff
- →
- promote
Discarding costs nothing. That is the default.
Irreversible effects
Hold it, and decide first
Emails, payments, webhooks, third-party calls. The call is intercepted and parked, described in plain language - "this would email 412 customers" - and released only on approval, or satisfied against the provider's test mode.
- hold
- →
- review
- →
- send
We will not pretend these can be rolled back. They cannot.
On your machine
One command, then the thing you actually read
Each agent gets its own branch, its own port, its own scoped credentials. The diff is the surface a human looks at - so it is the part that gets the design attention.
$ stunt up
✓ branch appdb@a41f from snapshot 06:00 2.4 GB · 9s
✓ gate listening on :6432 · policy dev.cel
→ postgres://localhost:6432/appdb
$ stunt takes
TAKE AGENT STATEMENTS FLAGGED STATUS
a41f-01 claude-code/nenad 47 1 open
a41f-02 claude-code/nenad 112 0 open
b09c-01 cursor/marko 18 3 blocked
$ stunt diff
schema
+ invoices.tax_rate numeric not null default 0
~ invoices_pkey dropped
data
invoices 12,404 → 12,404 (312 rows updated)
line_items 88,120 → 88,140 (+20)
statements
47 recorded, 1 blocked
⚠ UPDATE invoices SET status='paid' - no WHERE clauseCoverage
Postgres first, and only Postgres for now
The primitive generalises to anything an agent can write to. Postgres is what is being built - everything else below is the roadmap, and is labelled as such because implying otherwise would be the kind of thing this product exists to prevent.
| Target | Branch mechanism | Status |
|---|---|---|
| Postgres | Template copy, dump/restore, ZFS/LVM snapshot, cloud snapshot API | Building now |
| MySQL | Clone plugin, filesystem snapshot | Planned |
| Valkey / Redis | RDB fork, or keyspace-prefixed shadow | Planned |
| ClickHouse | Zero-copy table clone, partition swap on promote | Planned |
| S3 / R2 / GCS | Manifest branch - only changed objects materialise | Planned |
| Kubernetes | Forked namespace with rewritten references | Planned |
| Cloud & IaC APIs | No fork - intercept and simulate a plan | Planned |
| SaaS tools via MCP | No fork - hold for approval, or the provider test mode | Planned |
Open core
Everything one developer needs is free
The gate, the cloner, the policy engine and the diff are open source. What is commercial is the part that only matters once there is more than one of you - shared state, retention, identity, and the audit surface.
Local
Free · Apache 2.0
One developer, one laptop, no conversation with anybody.
- Single binary, no account, no daemon
- Branch any reachable database
- Full policy engine and diff
- Per-worktree isolation for parallel agents
- Ledger written to local disk
Team
Per protected datastore
When more than one person is accountable for the same data.
- Shared branches and the review console
- Ledger retention and search
- Org-wide policy, versioned in git
- SSO, agent identities, on-behalf-of
- CI and preview-environment integration
- Verifier auto-promote on green
Sovereign
BYOC
Regulated, air-gapped, or contractually EU-resident.
- Runs entirely in your own VPC
- Air-gapped and EU-resident deployments
- Compliance exports for the EU AI Act
- Custom protocol plugins
- Support and SLA
Pricing is not final. If you have a database you would pay to protect, that conversation is genuinely useful to us right now.
Let the agent take the fall
We are looking for teams running coding agents against a database that would hurt to lose. Tell us what broke last time - that is the whole application.