A lockout tag for every agent action that can't be undone
Most agent actions
are reversible.
Lock out the ones
that aren't.
Your agents already hold credentials to your repositories, your infrastructure and your production database. Reading a file is free to undo. Wiring $12,400 to an external account is not. Interlok classifies every tool your agents can reach by whether the action has an inverse, holds the ones that don't until a human determines them, and chains the proof of who decided.
One API call before your agent does something irreversible. Interlok holds the action, a named human approves it in Slack, and you get a signed record your auditor can verify without us.
Deterministic rules · no model in the decision path · credential values never stored
Do not operate
payments.payout.create — wire $12,400 to an external account. No inverse exists. Held until a named human determines it, and a second human signs.
held · justification · second signer
- Actor
- agent:payouts-bot
- Locked by
- human:t.okafor
- Entry
- org_seq 418 · b7d2…51ef
Only the human who hung the tag can clear it. An agent may never approve an agent.
Four tiers
Reversibility, not sensitivity, decides what gets locked out.
Free undo
Reading, or a change the same tool can put back with no side effects.
passes through
Compensable
A registered inverse exists: the effect can be undone by another call.
gated, compensator on file
Mitigable only
No inverse. The damage can be limited after the fact, not removed.
held for a determination
Irreversible
Once it happens it stays happened. Nothing here has an undo.
held · justification · second signer
01 / ENTITY
Actor
Who or what is acting — a human, an agent, a service. Identity, not a session.
02 / OBJECT
Target
The system the action lands on. A repo, a database, a payment processor.
03 / INTENT
Action
The specific consequential operation, classified as a read or a write path.
04 / RESULT
Decision
The record of allow, deny or approve — attributable, timestamped, evidential.
Four stages
You cannot gate what you cannot see
01
Discover
Parse the configuration that grants your agents reach. Enumerate servers, tools and identities, classify write paths, and grade the posture.
02
Gate
Interpose on the write path. A deterministic policy decides in-line: allow, deny, or hold for a human — and every decision is chained into the ledger.
03
Approve
A named human resolves the hold. Each decision is a hash commitment over the action, the parameters and the approver — quorum-aware, expiring, chained.
04
Reverse
Every executed action declares its reversal path — compensating action, snapshot restore, or grant revocation — or is labelled irreversible before it runs.
Live demo
One loop: gate, hold, approve, prove
The demo runs on the same engine as the product: no sign-in, real policy evaluation, a live hash-chained ledger.
Open the sandbox — no sign-in, real policy evaluationFintech / payments
A support agent that can move money
Live Stripe key in plaintext and create_refund auto-approved — the agent can issue refunds with no human in the loop.
Open the demo
What it looks like in the loop
One write path, gated, decided, and provable
An agent asks before it acts. The policy holds the action. A named human resolves it. The resolution is hashed into the ledger, and the entry cannot be edited afterwards without breaking the chain.
+−
What it looks like in the loop
One write path, gated, decided, and provable
An agent asks before it acts. The policy holds the action. A named human resolves it. The resolution is hashed into the ledger, and the entry cannot be edited afterwards without breaking the chain.
01 — Agent asks
The runtime calls the gate before the write, not after.
await gate.guard({
actor_ref: "agent:support-bot",
target_ref: "stripe/refunds",
action_type: "refund.create",
params: { amount: 42000 },
}, run)02 — Policy decides
Deterministic, first match wins, no model in the path.
{
"decision": "gate",
"matched_rule": "refunds-over-100",
"approvals_required": 1,
"reversible": true,
"proceed": false
}03 — Ledger proves
Hash-chained and countersigned with your own P-256 key.
{
"org_seq": 418,
"entry_type": "approval_recorded",
"prev_hash": "9f31…c0a4",
"entry_hash": "b7d2…51ef",
"signer_kind": "org_key"
}Every scan is compared to the one before it — a grade that drops notifies your approvers
Doctrine questions
The questions everyone asks before they trust a gate
Short answers to the invariants. The long version lives in the doctrine, and the one-page summary is a download away.
+−
Doctrine questions
The questions everyone asks before they trust a gate
Short answers to the invariants. The long version lives in the doctrine, and the one-page summary is a download away.
+Why can an agent never approve an agent?
An approval is an act of accountability, and only a person can carry it. Interlok binds every approval to a named human identity and refuses a resolution whose approver is an actor of class agent or service — even if that actor holds a valid API key. If an agent could clear its own hold, the gate would be decoration. The invariant is enforced in the engine, not in the UI, so it holds for API callers too.
+What counts as irreversible?
Every action is classified at decision time by whether it has an inverse. A read is T0 and passes through. An action with a known compensator is T1. An action with no safe undo is T2 or T3 and is always held for a named human, with T3 requiring a second signer. Anything Interlok cannot classify fails closed to T3 — an unknown action is treated as irreversible until you say otherwise.
+What makes the ledger tamper-evident rather than just an audit log?
Each entry hashes its own canonical payload, then hashes that together with the previous entry's hash. Editing any historical payload breaks every hash after it, so tampering is provable, not merely suspected. Entries are co-signed with a P-256 key and you can export a proof bundle and re-verify it offline. Custody matters as much as the chain: on platform-held plans we countersign, which means the chain protects you against everyone except us. On customer-held keys, it protects you against us too. We would rather state that plainly than let you find it in an audit.
+Will the gate slow my agents down or take them offline?
Policy evaluation is pure, deterministic and in-process — no model call is ever made to reach a decision. The SDK takes an availability stance: fail_closed refuses the write path if Interlok is unreachable, fail_open logs and proceeds. You choose per integration, and you can test both in the live demo's connectivity simulator.
+Do I have to block anything on day one?
No. Start in observe mode: policies evaluate and record for 14 days without blocking, so you see exactly what would have been held before anything is held. Discover comes first anyway — you cannot gate what you cannot see.
+Do you store my credentials?
Never. Scanning parses configuration to find plaintext secrets and wildcard grants, but only a fingerprint of a credential is retained so drift can be detected. The value itself is discarded and never written to the database or the ledger.
Start with Discover
Paste your MCP config. Get a graded posture report in seconds.
Interlok classifies every reachable tool, flags each write path with no gate in front of it, finds wildcard grants and plaintext credentials, and records the whole scan in an append-only hash-chained ledger. Share the report read-only when you need to.
Run the first scan