swarrm
A flight recorder for AI agents

Capture what your AI did.
Verify the record.

Your agents take real actions on their own — approve refunds, move money, make calls for your customers. Swarrm gives each captured action a signed receipt in a tamper-evident log. If a decision is questioned, you hold a self-contained tamper-evident bundle whose integrity anyone can check offline, without an account.

Verify a bundle →
The problem

“Our logs say so” isn’t proof.

Editable logs ask a later reviewer to trust whoever controlled them. A signed, checkpointed log gives that reviewer integrity checks they can rerun.

Your logs can be edited

Whoever controls a conventional database may be able to rewrite it. That weakens the record precisely when its history matters.

The AI vendor can’t vouch for itself

A platform grading its own AI’s homework is not enough. A separate verifier can test signatures and log structure without calling the producer.

Integrity checks have to survive the wait

Incidents and reviews show up months later. A self-contained bundle keeps the base integrity checks available to someone who was not there.

How it actually works

Four steps. No black box in the black box.

Plain enough to follow, real enough to hand your engineer or your auditor. The technical name for each step is on the right.

1
Sign each captured action
Each action the recorder captures becomes a canonical DSSE receipt signed with the recorder key.
signature: Ed25519, DSSE envelope, at capture time
2
Link it into a checkpointed log
Each signed receipt is included in an RFC 6962 Merkle log. Altering the presented receipt or its authenticated log path makes base verification fail.
structure: Merkle transparency log (RFC 6962); inclusion + consistency proofs
3
Label external claims honestly
The bundle may carry a Base Sepolia anchor transaction and a non-qualified RFC 3161 timestamp. Today the offline verifier checks their binding to the checkpoint, but not the chain or an independently supplied TSA trust root.
claims: Base Sepolia staging + non-qualified RFC 3161; recorded but not independently confirmed offline
4
Verify the presented history offline
Whoever holds the bundle can check receipt signatures, key history, Merkle inclusion and consistency, and the checkpoint chain with an open-source verifier. That is technical integrity, not an audit or legal conclusion.
verifier: open-source, browser-local (Rust→WASM); bundles never upload

Recording is designed to stay outside the agent's critical path, and the gateway supports fail-open operation. Validate capture, persistence, and failure behaviour in your own setup before relying on those deployment-specific properties.

What Swarrm can show

Evidence you can check yourself.

Each answer stays tied to the exact record and trust roots used.

Prove a captured receipt is intact

Every captured action is signed and placed in an authenticated log. Any change to the presented receipt or its authenticated path makes verification fail.

Make cyber tampering loud, not silent

Change the presented history and its checkpoint chain or Merkle proofs stop matching. Verification fails visibly.

Document and share the evidence trail

A bundle is self-contained. Whoever you share it with re-runs every base check offline, on their own machine, without asking Swarrm to vouch for it.

EXTERNALLY GATED · NON-AUTHORIZING

Confirm an agent comes from a trusted source

Counterparty Assurance checks an agent against an organisation root the relying party pins locally, plus current authority for the exact action. Favourable results remain non-authorizing until the external gates close.

Executive briefing

A one-page summary: what Swarrm proves today, how verification works, and what higher assurance requires.

Download (PDF)

Start free, on your own machine.

No account, no cloud bill, no sales call. Install it, run the demo, and inspect a locally verified tamper-evident record.

Install →
FAQ

The questions everyone asks.

What is this, in one sentence?
A flight recorder for AI agents: it puts signed receipts for captured actions into a tamper-evident log and exports a self-contained bundle whose presented authenticated history anyone can verify offline.
Was every action captured?
Capture failures that reach the recorder create an explicit gap and degrade health. A recorder cannot reconstruct traffic that never reached it; captured Edge receipts are signed and fsynced to customer-controlled disk before hosted sync.
Can I require durable capture for high-risk actions?
Selective per-action-class fail-closed capture is in development. The intended opt-in lets chosen high-risk actions — such as payment approval — wait for a durable customer-local receipt while other classes stay fail-open. Because the write is local, that gate need not depend on Swarrm-hosted uptime.
What if someone bypasses or stops the recorder?
Internal failures create an explicit gap. If the recorder is stopped or its route or base URL is changed around it, that recorder sees nothing; a separately configured Evidence Node can later surface an unmatched downstream effect as ORPHAN — showing that something happened outside the recorded path, not what happened or who changed it.
How does trusted-source confirmation work?
Externally gated and non-authorizing. The relying party pins an organisation root locally; Counterparty Assurance checks the agent credential, current authority, exact-action authorization and replay state against it. It does not predict behaviour or authorize execution: favourable results remain PASS_NOT_ENABLED with should_execute=false.
Will it slow down or break my AI?
The recorder is designed to run out of path and the gateway supports fail-open operation, so a capture failure need not block the agent call. Swarrm has no paid production deployment yet; test the exact failure behaviour and evidence gaps in your configuration.
Do you see my data?
The evidence log stores fingerprints and operational metadata, not prompts, outputs, tool arguments, or customer payloads. The hosted gateway relays payloads in transit and is designed not to persist them. Self-hosting keeps payloads inside your network; you control whether hashes and metadata egress.
What happens if we get hacked?
If an attacker changes a presented receipt or its authenticated log path, verification detects the mismatch. Activity outside every observed path remains outside that proof; Swarrm cannot reconstruct an uncaptured or lost action or make a forensic, legal or insurance determination.
Who can verify a record?
Anyone you share the bundle with. The verifier is open-source and runs in a plain browser — no account or API access. Python and Rust implementations are checked against the same adversarial tamper-evidence fixtures.
Is this blockchain?
There is no token or proprietary chain. Offline verification checks an anchor claim's binding to the checkpoint but does not query the chain. The report's explicit live mode can award the public-commitment level only after re-reading a covering Base or Base Sepolia anchor and verifying its RFC 3161 token to a TSA root the relying party supplied independently.
What does it cost?
Running it yourself and verifying bundles are free. Hosted access is invitation-based and currently carries no contractual SLA; self-hosting remains available when you need direct control of the deployment.