- ✓Actively maintained (<30d)
- ✓Documented (README)
- !Licence file present but not machine-readable
- !No description
git clone https://github.com/aurumflux20/sealTools overview
# seal
**Your agents earn the right to spend without you.**
> Not an engineer? Read [docs/PLAIN-ENGLISH.md](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.**
```
████████············ L2 ASSISTED 50 proven · 100% confirmed [human required]
fifty settlements — but volume alone is not trust.
████████████········ L3 DELEGATED 50 proven · 100% confirmed [unattended]
one clean sweep later: the human stops clicking Approve.
···················· L0 OBSERVED 50 proven · 100% confirmed [SUSPENDED]
one charge the gateway never admitted. fifty clean ones don't outweigh it.
```
```bash
SEAL_DSN="..." python3 license_demo.py # watch a path earn L3 and lose it
```
> **Want this checked on your own money path?** We do a fixed-price
> [Retry Safety Review](https://buy.stripe.com/28E7sL91C9naapQbBVdIA0l) — **$1,200, refunded in full if we find
> nothing.** Five days, written report, your own file and line numbers.
> [Book it](https://buy.stripe.com/28E7sL91C9naapQbBVdIA0l) · [what's involved](SUPPORT.md)
Slow to earn, instant to lose — the only shape that makes a track record mean
anything. The full level definitions: [docs/AUTONOMY-LEVELS.md](docs/AUTONOMY-LEVELS.md).
## Underneath: exactly-once admission
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:
```
INSERT ... ON CONFLICT DO NOTHING -- one row, one winner, no check-then-act window
```
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:
```bash
SEAL_DSN="..." python3 -m seal verify
# chain VERIFIED — 41 cert(s), every link intact (exit 0; broken chain → exit 1)
```
## The proof
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](STORM-PROOF.md).
Run it yourself:
```bash
pip install seal-kernel
export SEAL_DSN="host=... dbname=seal"
python3 -m seal verify # chain check, no network, no trust in us
```
To run the 1,000-thread storm proof yourself, clone the repo (the harness
ships with the source, not the wheel):
```bash
# Needs Python 3.10+. macOS ships 3.9 with pip 21, which fails an editable
# install with a misleading "setup.py not found" error — use a venv rather
# than debugging that.
git clone https://github.com/aurumflux20/seal && cd seal
python3 -m venv .venv && source .venv/bin/activate
python3 -m pip install -U pip && python3 -m pip install -e .
export SEAL_DSN="host=... dbname=seal"
python3 storm.py --n 1000
```
## Test YOUR server, not just ours
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:
```bash
python3 range_safety_test.py --n 1000
```
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](docs/RANGE-SAFETY-TEST.md).
## Usage
```python
from seal import Seal
seal = Seal(dsn); seal.setup()
adm = seal.admit("charge", {"order_id": "123", "amount": 4900})
if adm.fresh: # you won — run the effect, then seal it
result = stripe_charge(...)
cert = seal.seal(adm.intent, adm.fence, result)
elif adm.cert is not None: # already done — here is the receipt
return adm.cert
else: # someone else is mid-flight — stand down
raise InFlight()
```
If the effect fails **before anything irreversible happened**, release the claim
so a retry is legitimate: `seal.fail(adm.intent, adm.fence, reason)`.
## World confirmation — measured against live Stripe, not mocked
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.
```bash
export SEAL_DSN="host=... dbname=..."
export STRIPE_TEST_KEY="sk_test_..." # your own test-mode key, Dashboard -> API keys
python3 stripe_demo.py
```
What it does, against your real Stripe test account, no mocks:
1. **Two agents fire the same charge at the same instant.** Seal admits one.
Exactly one real `PaymentIntent` is created.
2. **The witness asks Stripe:** *"how many charges carry this intent?"* Stripe
says one → the cert upgrades to `WORLD_FINAL`.
3. **A rogue charge is created outside the gateway** — the thing no local fence
can stop on its own. The witness asks again; Stripe now says two → the cert
becomes `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.
## Pre-commit world freeze — don't act on facts that already moved
`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.
```python
from seal.freshness import CallableChecker
fresh = CallableChecker(lambda rs: current_cart_total(rs["order_id"]) == rs["total"])
adm = seal.admit("charge", {"amount": 5000}, key="order-777",
read_set={"order_id": "777", "total": 5000}, checker=fresh)
# StaleWorldRead is raised BEFORE a fence is granted if the checker says no —
# nothing runs on facts that already changed. Gateway.propose() takes the
# same read_set/checker kwargs and passes them straight through.
```
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.
## Clearance — permission that has to be earned, not declared
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.
```python
from seal.clearance import Clearance, CLEARED
cl = Clearance(seal)
cl.set_policy("charge", CLEARED) # an operator's intent
cl.record_proof("charge", green=True, storm_n=1000, executions=1) # from CI
cl.status("charge")["effective"] # CLEARED — but only because both are true
```
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.
## Exclusive Authority — agents get tickets, never the credential
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.
```python
from seal.authority import Gateway
gw = Gateway(seal)
gw.register_executor("charge", lambda args: stripe_charge(args)) # secret lives HERE only
prop = gw.propose("charge", {"amount": 4900}, key="order-777")
if prop["status"] == "cleared":
result = gw.execute(prop["ticket"], {"amount": 4900}) # gateway calls Stripe, not the agent
```
An agent calls `propose()` and gets back a **ticket** — proof an intent was
admitted, cleared, and budgeted — What people ask about seal
What is aurumflux20/seal?
+
aurumflux20/seal is tools for the Claude AI ecosystem with 0 GitHub stars.
How do I install seal?
+
You can install seal by cloning the repository (https://github.com/aurumflux20/seal) or following the README instructions on GitHub. ClaudeWave also provides quick install blocks on this page.
Is aurumflux20/seal safe to use?
+
Our security agent has analyzed aurumflux20/seal and assigned a Trust Score of 62/100 (tier: OK). See the full breakdown of passed checks and flags on this page.
Who maintains aurumflux20/seal?
+
aurumflux20/seal is maintained by aurumflux20. The last recorded GitHub activity is dated 2026-08-26, with 0 open issues.
Are there alternatives to seal?
+
Yes. On ClaudeWave you can browse similar tools at /categories/tools, sorted by popularity or recent activity.
Deploy seal to your cloud
Ship this repo to production in minutes. Each platform spins up its own environment with editable env vars.
Maintain this repo? Add a badge to your README
Drop the badge into your GitHub README to show it's tracked on ClaudeWave. Each badge links back to this page and reflects the live Trust Score.
[](https://claudewave.com/repo/aurumflux20-seal)<a href="https://claudewave.com/repo/aurumflux20-seal"><img src="https://claudewave.com/api/badge/aurumflux20-seal" alt="Featured on ClaudeWave: aurumflux20/seal" width="320" height="64" /></a>More Tools
A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.
An AI skill that provides design intelligence for building professional UI/UX across multiple platforms.
🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman
CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies
The best-benchmarked open-source AI memory system. And it's free.
The fastest, litest AI Gateway. Rust core with Python SDK. Call 100+ LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]