Verify this packet yourself.

ActaSeal is a policy gateway that sits in front of AI-agent payment actions and produces a signed, tamper-evident evidence record for every decision. When a dispute happens, that record can be exported as a self-contained packet. This page walks through checking one yourself — no ActaSeal install, no account, no call to us.

Verify a real packet in under 60 seconds

pip install cryptography
unzip demo-packet-anchored.zip -d packet
python verify.py packet

Expected output:

VERIFIED: 3 ledger events, receipt signature valid, chain intact
  action_id: refund-demo-001
  decision: ALLOW (APPROVAL_GRANTED)

Two demo packets, two settlement states

The difference matters for a dispute: an anchored packet lets a counterparty check that the recorded decision and the actual payment-rail settlement are bound to the same mandate, not just asserted to be related. An unanchored packet is still a fully valid, fully verifiable evidence chain — it just doesn't carry that additional rail binding.

What this packet proves

Not a field-by-field dump — the specific claims a verified packet lets you check, each traced to what's actually inside it:

• Who delegated authority A specific delegation mandate authorized this action. The receipt and, when present, the settlement anchor both carry the same mandate_hash — you can confirm they refer to the same delegation, not two different ones asserted to match.
  fields: receipt.json → mandate_hash, manifest.json → settlement_anchor.anchor.mandate_hash
• What scope was granted, and what actually happened The packet records both the intent scope the agent was granted and the action it actually executed, each hashed independently, plus the verdict comparing them.
  field: receipt.json → scope_conformance
• In-scope or breach A single verdict — IN_SCOPE or a named breach — and, if it's a breach, which dimension of the granted scope was exceeded. Not a probability score; a re-derivable yes/no.
  field: receipt.json → scope_conformance.verdict, .breaches
• When it happened, in what order Every event in the packet is chained to the one before it by hash, so the sequence and timing can't be reordered or have events inserted without breaking the chain — the verifier checks this explicitly.
  field: ledger_slice.ndjson (chained via previous_event_hash)
• Anchored to which payment rail (if settled) When present, the settlement anchor names the rail, an anchor id, and a settlement timestamp, and its hash is recomputed by the verifier from that content — it isn't just a string someone typed in.
  field: manifest.json → settlement_anchor

Read more