Swarrm

Signed receipts, a tamper-evident log, and locally verifiable assurance for AI agents.

Each supported action captured through an enabled integration — 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). A bounded selected set of receipts exports as a self-contained evidence bundle that anyone you share it with can verify offline — no account or live Swarrm service. Swarrm fails an export explicitly instead of returning a partial bundle when its mandatory state closure or response bounds cannot be met. Long-running logs use an explicit sparse checkpoint-proof profile: it validates the complete stored hash chain, then carries genesis, head and the earliest carried timing proof for each exported entry. It does not claim that omitted intermediate checkpoint history travelled in that bundle. Self-hosted capture keeps payloads in your environment; hosted capture necessarily handles them in transit. The evidence log stores commitments and operational metadata, not model or business payloads.

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

Status

Launched as 1.1.0. Base E1 integrity is the current reliance claim. Counterparty Assurance v1 is CWT/COSE-only; favourable PASS is not enabled.

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 PASS — the v1 verifier checks a nonce-bound exact action, organisation-root passport chain, current mandate, action-specific authorization and durable replay locally. Its public result still converts every otherwise favourable candidate to INDETERMINATE/PASS_NOT_ENABLED until the independent review, compromise drill and limited relying-party rollout gates are complete.

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 whose base E1 record you can verify offline — not as a third-party assurance mark. A valid, unexpired B28 authorization can also be verified locally, but obtaining a new action-specific authorization requires the online delegated Action Authority. No Swarrm Verified mark ships.

Quickstart

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

The exact version pin prevents a later release from silently changing the reviewed bytes. Before creating an organisation root, download the matching GitHub release wheel, runtime requirements, SHA256SUMS, PROVENANCE.json and their Sigstore bundles. Verify each signature against the capxholding/swarrm-core/.github/workflows/ci.yml@refs/heads/main identity, the GitHub Actions OIDC issuer and the exact workflow SHA. Require the provenance source_commit to equal the release tag's peeled commit; verify the wheel from SHA256SUMS and the runtime-requirements digest from the signed provenance. In a clean virtual environment, install requirements-docker.txt with pip install --require-hashes --only-binary=:all: -r, then install the verified wheel with pip install --no-deps; do not resolve broad dependency ranges at ceremony time. If those matching signed assets are unavailable, stop. The release never asks a served webpage to generate or decrypt the root. This signed, hash-locked local environment is the boundary used by the root ceremony.

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 altered in the presented authenticated history without verification failing. A bundle proves its carried receipts and, when present, its signed export manifest; it does not prove that the producer captured or exported every relevant action. This is what the offline verifier proves today.
• E2 — anchored. Withdrawn from offline reports. 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 — the second signature verifies against keys carried in the same bundle, which does not establish that the co-signer is an independent counterparty.

Any future E2/E3 release 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.

The launched product also includes local organisation-root onboarding and the swarrm-b28/v1 Counterparty Assurance profile. The visible flow is create organisation → connect/sign in → register agent. Underneath it, the verified local tool creates the customer-controlled root, the root authorizes a registration template and admin passkey, the passkey selects that exact template, and the agent proves control of its dedicated key before the Passport & Status Authority issues its immutable passport. A root-signed limit grant may then delegate exact action authorization to the separate Action Authority. B28 proves identity and current proof-bearing authority at a signed checkpoint, and evaluates exact-action and durable replay requirements. The current B28 path does not authorize execution: should_execute is false even for an otherwise favourable candidate. It does not predict behaviour, certify the action outcome, or evaluate Node/source/coverage, history, or post-action evidence readiness in v1. The authority plane supports a dual-signed organisation-root successor ceremony with monotonic continuity and old-runtime fencing. It cannot recover from loss of the old root unless a successor was already authorized, and B28 presentations cannot import a successor as a new relying-party trust anchor. The external compromise/revocation drill therefore remains a gate for enabling favourable PASS; it does not gate the stable product release.

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