Change control for agents with production access
An agent asks to drop a column on a hundred thousand rows. Nobody can answer that honestly — not without knowing whether the rollback actually works.
So AIRLOCK does not ask it. It runs the change against a copy of your database, undoes it, and checksums all three states. The gate opens only if the data came back.
npm run demo— three real changes, ~90s
Every other approval flow
The agent wants to:
alter table users
drop column plan_name
100,000 rows · 1 dependent index
You are being asked to trust a plan. Nothing on this screen tells you whether the rollback works.
AIRLOCK
gate sealedRan it against a copy of the real rows. Then ran the rollback.
no approval control exists
Line 3 is not line 1. The column came back; the hundred thousand values in it did not.
Not greyed out — never rendered. The value that would represent permission cannot be constructed, so the agent has nothing to offer a human and nobody is interrupted about a change that cannot be undone.
Writes the change and its inverse. No certificate yet, so the gate is shut by default.
Runs it on a copy of the real rows, runs the rollback, checksums all three states.
Only reachable from a passing proof. The agent has no tool that applies anything.
// packages/contract/src/gate.ts
const GATE_WITNESS: unique symbol = Symbol('airlock.gate.witness');
export interface ApprovalGrant {
readonly [GATE_WITNESS]: true; // unforgeable outside this module
}Not greyed out, not hidden behind a warning. A disabled button is a decision you can argue with; an unrepresentable state is one you cannot.
Attempts to fake a grant are asserted as type errors. Weaken the type and tsc reports an unused @ts-expect-error — the build fails.
The gate re-runs server-side against the stored dossier. Approving through the HTTP API with no browser involved is refused identically.
PROVEN — ROLLBACK VERIFIED
Applied and rolled back on a shadow branch. The data returned byte-identical.
Add a tier column to users, backfill it, then drop the deprecated plan_name column.
openGate() returned a grant, so the control above can exist. It is the only way one comes into being.
openGate(dossier, { role: 'approver' })
-> { state: 'OPEN', grant: { final: true, seals: 0/1 } }Apply the change to a shadow branch. Apply the rollback. Checksum the affected tables a third time and prove the data came back byte-identical.
AIRLOCK never trusts the verifier’s own match flag. It recomputes pre === post_rollback itself, so an engine bug cannot open the door.
Every record that will be destroyed, across every system — plus an explicit list of what is being deliberately kept and the obligation justifying each exclusion.
An exclusion with no stated reason is rejected by the contract. “We kept some things” is not a scope.
| Class | Certificate | Approvers | Proof valid | Undo window | Break-glass |
|---|---|---|---|---|---|
| Schema migration | UNDO | 1 | 30 min | 30 min | permitted |
| Data operation | UNDO | 1 | 30 min | 15 min | permitted |
| Erasure | SCOPE | 2 | 15 min | none | no |
| Access grant | SCOPE | 2 | 10 min | none | permitted |
| Money movement | SCOPE | 2 | 10 min | none | no |
| Comms blast | SCOPE | 2 | 15 min | none | no |
| Infrastructure mutation | ANY | 2 | 15 min | 10 min | permitted |
Note what is deliberately absent: there is no change freeze on erasure, money movement or access grants. A freeze that blocks a right-to-erasure request trades a legal problem for an operational one. That absence is asserted in the test suite, so it cannot be quietly reversed.
Production is re-checksummed the moment the change lands and compared against what the certificate predicted it would become.
A mismatch executes the inverse that was already demonstrated. Where it was never proven, AIRLOCK refuses and raises an alarm instead.
Most bad changes are perfectly healthy by every checksum and simply turn out to be wrong. Only a person ever catches that.
The refusal is the feature. AIRLOCK will only auto-revert a rollback it has proof of. Running an untested inverse against a database already in an unexpected state is how a bad afternoon becomes a bad quarter — so that case stops and gets a human.
COMPUTING…
Hashing three records into a chain with the Web Crypto API.
sha256:0000000000000000000000000000000000000000000000000000000000000000
Keep this hash somewhere we cannot reach — a wiki, an email to yourself, an auditor’s file. Any future edit to any record above changes it, and you will be able to tell without trusting us about anything.
This does not make the ledger unforgeable — anyone who can rewrite the file can recompute the whole chain. What it makes is tampering visible to anyone holding an older copy of a single hash.
That is the property that actually matters, because the person auditing you is not the person who edited it.
The change ran against a copy of the real rows and the rollback brought them back byte-identical.
Certificates that passed. The one state in which the gate can open.
--seal
Refused. A proof that failed, a policy ceiling, drift, a missing signature, an injection.
Every refusal, and the space where an approve control is not rendered.
--fault
There is no inverse. An erasure, a refund, forty thousand emails.
Scope certificates and armed approvals. Never hover, never emphasis, never brand.
--hazard
Something you can operate: a link, a control, a focus ring.
The only accent on this page. If it is this colour, you can press it.
--ice
AIRLOCK is the literal answer — an agent that behaves as though it is not trusted with root, and proves it every time before it asks.