The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Seal listing page.
Public register: the Retry-Safety Index lists which agent-payment implementations pay once when the answer is lost — verified safe, found & fixed (with time-to-fix), and how to get verified. Every row links to its proof.
Your agents earn the right to spend without you.
Seal and EffectFence stop an irreversible action from firing twice while it happens — runtime enforcement on money movement. Coherence never touches your runtime; it reads the record afterwards and grades what an agent claimed against what it proved. Prevention versus proof. Different problems, different code, no overlap.
Free: submit any client, facilitator, SDK or toolkit that moves money — yours or someone else's — and we read it and publish a verdict on the Retry-Safety Index at no cost. Findings come back with the mechanism, the file and line, and a failing test. You are counted, never named, until you ship a fix. Submit for grading →
Seal is an MCP server (seal-mcp, stdio, JSON-RPC 2.0) — and a Python
library. It gives an MCP host 12 tools for exactly-once execution of
irreversible actions: seal_propose, seal_execute, seal_paths (gateway
mode — the agent holds a single-use ticket, never the provider key), plus
seal_admit, seal_commit, seal_abort, seal_heartbeat, seal_get,
seal_verify, seal_incident_receipt, seal_expect, seal_obligations.
It starts in introspection-only mode with no environment — initialize and
tools/list answer with no database, so a host or registry probe can connect
immediately. Set SEAL_DSN to a Postgres DSN to actually admit actions, and
SEAL_EXECUTORS=your.module for gateway mode.
Not an engineer? Read docs/PLAIN-ENGLISH.md instead — the same thing with no jargon, including what we can't do.
Everyone else ships a lock: a spend cap you set once and forget. The cap never learns, so an agent that has settled ten thousand clean payments is trusted exactly as little as the one you installed this morning — and you keep clicking Approve.
Seal ships the unlock. It reads what a payment path has actually proven — settlements the provider confirmed, sweeps showing nothing moved behind its back — and computes the autonomy that path has earned. L0 OBSERVED → L5 AUTONOMOUS. Nobody types the level.
Since 0.4.0 the licence drives the wheel, not just the dashboard. Turn on
earned autonomy — Gateway(seal, earned_autonomy=True), or
SEAL_EARNED_AUTONOMY=1 for the MCP server — and the gateway lets a path move
money unattended only to the extent its own record has earned (L3+), inside
the operator's ceilings, never above them. Three things hand the wheel back to
a human instantly: a path that hasn't earned it yet, a suspension (money moved
behind the gateway's back), and a hold — an execution reached the provider
and its outcome is unknown, so the path pulls over until settle() has asked
the provider what happened. The hold lifts by itself once the world answers.
A human can still approve any single action through the same maker-checker
door (tier=LICENCE). Off by default: nothing changes until you switch it on.
Can you prove your agents won't double-charge a customer? Three rungs, one ladder, written-only: a $300 founding conformance run — your implementation through the battery, result published on the Index (first three only; book) · a $1,200 attestation run — your live endpoint against every ambiguous outcome, signed result, findings within five business days, a clean run signed within 24 h (book) · a $12,000 fixed-scope money-path review — one production money path read, tested and attested in 7–10 days, no invoice if no real double-fire is shown on a path you run. For a free self-check first, hostile-facilitator tells you in 60 seconds.
Slow to earn, instant to lose — the only shape that makes a track record mean anything. The full level definitions: docs/AUTONOMY-LEVELS.md.
Seal's ambiguous-outcome doctrine — "could not determine" is terminal, never absent — is now §4.3 of the draft MCP retry-safety proposal, co-authored by us, with our conformance battery as its test suite.
Two different agents, on two different machines, both decide to charge order 123 at the same instant. In-process idempotency can't help — the guard has to live in a store both agents talk to, and the winner has to be decided atomically there.
Seal is that layer. One Postgres, one row per intent, one winner:
Every admitted action ends in a certificate: a content-addressed hash over intent + args digest + result digest + the previous cert's hash. Editing, deleting or reordering any cert breaks every hash after it — and anyone with the DSN can check, with no network and no trust in us:
The claim is tested the hostile way: 1,000 real threads released by one barrier against one shared Postgres, where the "charge" increments a measured counter — if two callers run, the counter says 2 and the test fails loudly.
Result, four consecutive runs: ACTUAL_EXECUTIONS = 1. Every loser either replayed the sealed cert, stood down mid-flight, or failed safe when the store was unreachable. A 50-caller post-seal wave: all replayed, none re-ran. Full numbers, including the honest limits: STORM-PROOF.md.
Run it yourself:
To run the 1,000-thread storm proof yourself, clone the repo (the harness ships with the source, not the wheel):
The exact harness above, generalized into a standalone file with zero dependency on this repo — copy it, point it at your own write-bearing tool, and find out for yourself:
It demonstrates itself against a known-unsafe target and a known-safe one before you ever run it for real, so a pass means something. Full writeup, including the three ways an early version of this test lied to us before it was fixed: docs/RANGE-SAFETY-TEST.md.
If the effect fails before anything irreversible happened, release the claim
so a retry is legitimate: seal.fail(adm.intent, adm.fence, reason).
A cert saying "admitted once" is a claim about us. The next question is what Stripe (or Resend, or your bank's webhook) actually recorded — and the answer is allowed to disagree with us.
What it does, against your real Stripe test account, no mocks:
PaymentIntent is created.WORLD_FINAL.WORLD_DIVERGED, the domain freezes, and further spend on it is
refused automatically.Two honest things the live run taught us, both fixed and both tested: Stripe's
search index is eventually consistent (a fresh charge can take real seconds to
appear — the witness polls to a definitive answer rather than ever recording a
"not indexed yet" empty read as authoritative absence), and once the world has
contradicted the ledger, a later flaky re-count must never quietly downgrade
the cert back to WORLD_FINAL — divergence is sticky by design.
admit() has always taken a read_set — the world facts a decision depends
on (a cart total, an inventory count) — and stored it on the cert. Until now
nothing ever checked it: a caller who believed they had staleness protection
had none. Same defect shape as a bug fixed earlier the same day, one layer up
— a guard present in the schema, never enforced.
Enforcement point is deliberate: before the fence, not after the effect ran.
Checking afterward could only refuse to claim success — it can't stop money
moving on stale information, which is the actual failure this exists to
prevent. Opt-in and backward-compatible, same rule as everywhere else in this
library: only engages when the caller supplies both read_set and checker.
Honest limit, printed where it applies rather than left to be discovered: the
checker call itself can't be made atomic with the admission INSERT, so a
change landing in that narrow gap is a residual window — the same caveat
class as a witness's eventually-consistent provider index.
The fence proves an action ran once. Clearance is the layer above it that a company actually buys: which tool paths may an agent fire unattended, and on what evidence.
The rule that makes this more than a toggle: CLEARED is earned, not
declared. A path only reports effectively CLEARED if an operator set it
and a green storm proof was recorded recently enough. Let the last proof go
red, or let it go stale, and status() reports HOLD on its own — nobody has
to remember to downgrade it. REVOKED always wins, never auto-recovers, and
revoke_all() is one switch that stops every known path at the choke. A
range_report() exports counted events and provider-cited certs — the artifact
a security questionnaire or a CFO actually reads.
Clearance is policy. Policy an agent can walk around if it still holds
sk_live itself isn't a rail, it's a suggestion. Exclusive Authority removes
the credential from the agent entirely.
An agent calls propose() and gets back a ticket — proof an intent was
admitted, cleared, and budgeted — never a secret. execute() is the only place
the provider is ever called, and the ticket is bound to the exact args that
were cleared: it's rejected if what you hand execute() doesn't match what was
proposed, single-use, and expires. (The first cut of this didn't bind args to
the signature and would have let a ticket cleared for $1 be spent on any
amount — found by attacking our own build before it shipped, not after.)
Custody model, stated plainly: the gateway runs inside your own infrastructure. AurumFlux never holds, sees, or transports your provider secret — we ship the software that takes the key out of the agent's hands; we do not become a vault ourselves. Honest limit: a process on the same host that can read the gateway's own environment can still steal the secret. This raises the bar to "steal from the vault," not to physical impossibility.
Binary CLEARED is enough for a $5 API call. It is not what a finance org signs off on for a $50,000 payout — they sign off on segregation of duties: the person who proposes a spend is never the person who approves it, on the record. Graduated Clearance adds thresholds on top of Clearance:
Wired into the gateway: Gateway.propose(..., amount=X) on a path with
thresholds configured returns {"status": "needs_approval", "tier": "DUAL"}
instead of a ticket until a satisfied approval_id is supplied. The maker
cannot approve their own request — enforced in code, not policy — and one
approver cannot be counted twice even under a genuine concurrent race, because
it's a Postgres UNIQUE constraint on (approval, approver), not an
app-level check. A single reject is terminal. An approval authorises exactly
one execution and is bound to the exact intent it was requested for. Every
decided approval — approved or rejected, with every vote — is appended into
the same hash chain the execution certs live in, so seal verify covers
governance decisions the same way it covers what actually ran.
Backward-compatible by design: a path nobody ran set_thresholds() on never
triggers graduated clearance, even if propose() is called with an amount —
existing budget-only integrations are unaffected.
Run the whole story end to end — no payment provider needed, nothing charged:
A $200 purchase clears on its own; $12,000 is refused until two distinct
humans approve; the requester is refused when they try to approve their own;
a duplicate vote from the same approver is refused; one reject is terminal;
$250,000 is never automatic; and one revoke stops even the $200 path. It
ends on the Range Report, which states approvals in money — approved and
rejected totals — rather than a count of event kinds.
The dispute that matters spans three parties — the user who authorised an
agent, the operator who ran it, and the merchant who got paid — and each holds
a database the other two cannot read. seal verify answers "did this run
exactly once, and did the world confirm it?", but only to someone holding the
DSN, which is to say only to the party being asked to prove its own innocence.
A portable receipt is that answer as a file. Certs are hashed over
RFC 8785 canonical JSON and (with a key configured) Ed25519-signed at
write time, so a counterparty verifies them with no database, no network, and
none of our code — docs/verify-receipt.mjs does
it in ~30 lines of Node:
Honest limits, on the verdict itself: a pinned-key pass proves these certs were produced by the key holder and are unaltered — it cannot prove completeness (whether other certs exist takes the chain check against the store), and an unpinned pass proves internal consistency only, never authorship. Signing is opt-in; an unsigned store keeps working exactly as before, and v1 certs keep verifying next to v2 forever.
Idempotency keys make retrying the same request safe. They do not answer
what happened after a timeout where the provider may already have acted. That
intent sits open, and before settle() the only resolution was implicit — a
future admit(heal_with=…) some caller might never make. Now it is one verb:
Every guard above — and every agent-safety tool we know of — watches commission: the double-charge, the overspend, the contradiction. Nothing watches omission. An agent that crashed, lost its key, or silently stopped looks exactly like an agent with nothing to do — until payroll doesn't go out, or the refund that was legally due in 14 days quietly doesn't happen.
This repo already refuses that failure mode for its tests (conftest.py: a
run where everything skipped is not a pass). Obligations apply the same
sentence to production money. It is the dual of the reconcile sweep:
What makes a miss more than a dashboard row: the breach itself is appended
to the tamper-evident chain (deleting it breaks every hash after it), and
obligation_breached is a licence-suspending event — a path that goes
silent on declared work loses its earned autonomy exactly like a path that
double-charged. Declaring duties is open to agents (seal_expect over MCP);
cancelling one is an operator act with no agent-facing tool, because an
obligation an agent could cancel is not an obligation. A breach deliberately
does not freeze the path — a frozen refund path cannot cure a missed
refund; the levers are evidence, alarm, and the licence.
A cert proves the action was admitted exactly once at this gateway and that
the recorded result hasn't been altered since. It does not prove the outside
world settled it — every v1 cert carries world: "unconfirmed", permanently and
on purpose. "We admitted this once" and "Stripe took the money" are different
claims; conflating them is exactly the bug class this tool exists to stop.
World confirmation (provider adapters that flip that field against Stripe's or
your provider's own records) is the next layer, and the cert schema already
carries the field so the format won't break.
once-kernel proves one
process didn't run an effect twice. effectfence
guards one MCP server. Seal is the cross-process layer above both, for the
moment your agents outgrow a single machine. The free primitives stay free
(Apache-2.0 / MIT), forever.
For claim vs proven on agent PRs and CI (said it ≠ showed it), see the
separate project coherence —
not part of this repo; different package, different git history.
Business Source License 1.1: read it, run it, use it in production internally (commercial included) — just don't resell it as a hosted service. Converts to Apache-2.0 on 2030-08-12.
mcp-name: io.github.aurumflux20/seal