Swarrm

Signed receipts, a tamper-evident log, and offline verification for what AI agents do.

Every action an AI agent takes — a model call, a tool run, a refund, a payment — becomes a signed receipt in an append-only, tamper-evident log (RFC 6962 Merkle tree, Ed25519 / DSSE). Any set of receipts exports as a self-contained evidence bundle that anyone you share it with can verify offline — no account, no server, no trust in you or in Swarrm. Payloads stay in your environment; the log holds hashes and operational metadata, never the content.

Ordinary application logs are editable, so they are testimony, not evidence. These records are verifiable: flip a single byte and the bundle fails.

Status

Beta. The evidence log is solid; the higher assurance layer is withdrawn pending rebuild.

What is genuinely proven, offline, today — this part is the product's foundation and it holds up: signed receipts, canonical (RFC 8785) encoding, RFC 6962 Merkle inclusion and consistency, checkpoint and key-log validation, hostile-input limits, and base evidence-bundle verification — all independently implemented twice (Python here, Rust in the open swarrm-verify repo) and pinned by a shared adversarial fixture suite. Flip one byte and the bundle fails.

What is withdrawn (an internal audit on 2026-08-03 found these could be derived from a subject's own declarations rather than from verified proof, so they are disabled rather than shipped weak):

• the Swarrm Verified mark — it read declaration-derived inputs, so a subject could award it to itself; it now renders UNMARKED_ASSURANCE_WITHDRAWN;
• the E2/E3 assurance badges in offline reports — anchor transactions are never checked against a chain and the RFC 3161 certificate chain travels inside the bundle, so neither was independent of the subject. Anchors and timestamps are now shown as claims. E1 is unaffected and real;
• the "qualified" timestamp label — it was an unsigned producer boolean, not derived from an EU trusted-list root;
• B28 counterparty assurance (agent-to-agent handshake) — it had unauthenticated PASS routes and can no longer return PASS at all.

Claims ≤ mechanism: anchoring runs on a public staging chain (Base Sepolia), timestamps are non-qualified, and no external security audit or paid production deployment has been completed. Use this today as a tamper-evident flight recorder you can verify offline — not as a third-party assurance mark.

Quickstart

pipx install swarrm                   # Python 3.11+  (or: pip install swarrm)
swarrm demo                           # synthetic agent traffic → receipts → bundle → VERIFIED
swarrm verify demo_out/bundle.json    # the demo flips one byte → NOT VERIFIED

Two minutes, no account, fully local. One config knob — EVD_PROFILE (for example dev, trial, edge, node, or the KMS-only managed production profile) — sets every default; swarrm doctor prints what's effective and whether it is actually recording. The CLI is one word: up (dev stack), demo, verify BUNDLE, wrap -- CMD (capture an MCP tool), node, incident, status, doctor.

Verify it yourself — offline, and open

swarrm verify <bundle.json> checks a bundle entirely locally. So does the in-browser verifier at swarrm.ai/verify — client-side, nothing leaves the page.

The verifier is open source and independent: a second implementation in Rust (github.com/capxholding/swarrm-verify, Apache-2.0) that must agree with this package's Python verifier on a shared adversarial fixture suite. Two implementations, one answer — the verdict does not depend on trusting a single codebase. The normative wire-format specifications (evd/*) are published openly in that repository.

The evidence ladder

Each receipt carries the assurance it has actually earned:

• E0 — signed. The receipt exists and is intact, signed by a known key.
• E1 — in the log. Included in an append-only, checkpointed log; it cannot be silently altered or dropped. This is what the offline verifier proves today.
• E2 — anchored. Withdrawn from offline reports pending rebuild. The intent: the checkpoint is committed to a public chain and independently timestamped (RFC 3161). The problem: offline verification never checked the transaction against a chain, and the RFC 3161 certificate chain travels inside the bundle — so both rested on material the subject supplies. Anchors and timestamps still appear, labelled as claims.
• E3 — co-signed. Withdrawn from offline reports pending rebuild — the second signature verifies against keys carried in the same bundle, which does not establish that the co-signer is an independent counterparty.

Re-enabling E2/E3 means verifying against trust roots supplied independently of the bundle (a known chain endpoint, a known TSA/trusted-list root, a known counterparty key). That work is in progress; until then the honest claim is E1.

What's in the package

The cryptographic log and receipts; capture surfaces (proxy, recorder, MCP wrapper, SDK, OpenTelemetry); L2 anchoring + RFC 3161 timestamping; the offline verifier; evidence-report rendering; and an out-of-path Evidence Node for independently reading an authoritative source. The wire-format specifications and the second independent verifier are open source (Apache-2.0) in the swarrm-verify repository.

License

The swarrm package is proprietary — © 2026 Capx Holding, all rights reserved. The published wire-format specifications and the independent verifier are Apache-2.0.

Homepage: swarrm.ai