Introduction
What Sealr is, what it proves, and what it deliberately does not.
Sealr sits in the path between your AI agents and your production systems. It records what they actually execute — the SQL statement, the Terraform plan, the git push — and, where you ask it to, refuses the operation before it runs.
The problem it addresses
An agent that reports "I cleaned up the stale rows" has told you its intent, not its
action. The two diverge, and the gap is invisible in an agent transcript. Meanwhile the
database sees a DELETE with no WHERE clause and no memory of who asked for it.
Sealr closes that gap from the side that cannot be talked around: the operation itself.
What it does
Records
Every operation becomes a hash-chained record: who, what, the verdict, a salted commitment to the payload — never the payload itself.
Decides
Guards parse the operation with the real grammar (PostgreSQL, Terraform plan JSON, git argv). Policies turn that classification into ALLOW, WARN, REQUIRE_APPROVAL or BLOCK.
Proves
Export a .seal bundle and hand it to an auditor with the open-source verifier. They
verify it offline, without trusting us or you.
What it does not do
This matters more than the feature list, and it is stated the same way everywhere in these docs and in the product itself:
- Tamper-evident, not tamper-proof. Sealr proves the integrity, ordering, timing and origin of the stream it recorded. It cannot prove that unrecorded events did not happen.
- Coverage is a deployment property. An agent whose traffic never passes through a recorder produces no records. The GitHub App reconciliation makes that kind of bypass visible; it does not prevent it.
- Guards read operations, not minds. A guard classifies the statement in front of it. It has no opinion about why the agent produced it.
Read what Sealr proves before you rely on it for anything that matters.
Start here
- Quickstart — a recorded, blocked operation in five minutes, no account.
- Installation — every platform, agent surface and CI environment.