Metadata-Version: 2.4
Name: swarrm
Version: 1.1.0
Summary: Swarrm — signed receipts, a transparency log, and local verification of captured AI-agent evidence
Author-email: Maximilian Carl Friede <proof@swarrm.ai>
License-Expression: LicenseRef-Swarrm-Proprietary AND Apache-2.0
Project-URL: Homepage, https://swarrm.ai
Project-URL: Verify, https://swarrm.ai/verify
Project-URL: Open verifier & specs, https://github.com/capxholding/swarrm-verify
Keywords: ai-agents,audit,evidence,transparency-log,tamper-evident,verification
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: 3.14
Classifier: Topic :: Security :: Cryptography
Classifier: Topic :: Software Development :: Quality Assurance
Requires-Python: >=3.11
Description-Content-Type: text/markdown
License-File: LICENSE
License-File: LICENSE-APACHE-2.0.txt
Requires-Dist: cryptography>=42
Requires-Dist: uvicorn>=0.29
Requires-Dist: rfc8785>=0.1
Requires-Dist: httpx>=0.27
Requires-Dist: fastapi>=0.110
Requires-Dist: web3<8,>=7.16
Requires-Dist: asn1crypto>=1.5
Requires-Dist: cbor2==6.1.4
Requires-Dist: jinja2>=3.1
Requires-Dist: python-multipart>=0.0.9
Provides-Extra: dev
Requires-Dist: pytest>=8; extra == "dev"
Requires-Dist: anyio>=4; extra == "dev"
Requires-Dist: ruff<0.16,>=0.15; extra == "dev"
Requires-Dist: detect-secrets>=1.5; extra == "dev"
Requires-Dist: lizard==1.23.0; extra == "dev"
Requires-Dist: pathspec==1.1.1; extra == "dev"
Dynamic: license-file

# 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](https://github.com/capxholding/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

```bash
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](https://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](https://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](https://github.com/capxholding/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](https://swarrm.ai)
