Format of record: Decision Receipt v1.0 · Evidence Bundle Canonicalization JCS-lineage (not literal RFC 8785) Signature Ed25519 Algorithm Ed25519-SHA256-JCS Format frozen at v1.0

Verifiable decision records for AI agents

Inspect the signed record. Then challenge it.

Each decision AGA records is a signed Decision Receipt: tamper-evident, hash-chained, sealed under a signed checkpoint, exported as one portable Evidence Bundle. Verify it offline against a published format with the gateway's public key, pinned in advance. No account. No callback. No faith in the vendor's logs required: trust reduces to the key you pinned, and its holder can re-sign.

Try to break a receipt ↓ Run the static evaluation or request info

The bench · the one you run

Watch it verify. Then try to break it.

Below is this site's real sample Evidence Bundle: four Decision Receipts and a signed checkpoint, the same file the offline verifier ships. Nothing here is a screenshot of verification. Your browser runs the site's own verifier, recomputing every hash and re-checking every Ed25519 signature in this tab, every time you change anything. Pull a lever and watch which check catches it.

sample-bundle.json·loading…·signed with the published sample-bundle key, which no gateway holds

Verifier console · runs in this tab

RUNNING…

computing on the real sample bundle

Scope of proof

A verified bundle proves the integrity of every receipt present. It does not prove the operator recorded every action.

This bench runs the site's shipped verifier (compiled from lib/verifier.ts, the same code path behind /verify) against /sample-bundle.json, with no network calls after the file loads. The verdict and every check are computed here, not asserted. The downloadable zero-dependency verifier runs the same published checklist offline.

“Policy without proof is just a suggestion.”

The position, in one sentence

The argument

A customer's reviewer may ask what decision was recorded for an agent's tool call and whether the retained record has changed. Signed logs, protected storage and other gateways can provide overlapping evidence. This bench explores AGA's specific format: what its signatures bind, how the exported sequence is checked, and what a passing result cannot establish.

We think the answer should be evidence: records built so that believing them is unnecessary. Six claims follow. Each comes with an exhibit, and one exhibit is the bench you just used.

An agent cannot vouch for itself.

Agents act through a gateway, a runtime boundary process. With the gateway under its own OS identity the agent holds no signing keys, and on aga-proxy it has no tool that changes its policy. Each decision the gateway records is a Decision Receipt (known issue 7 on /security describes the tool calls aga-proxy refuses without one): exactly fifteen canonical fields, signed Ed25519 over JCS-lineage canonical JSON (not literal RFC 8785). The receipt states what was decided, PERMITTED or DENIED, for which tool call, why, and under which policy: aga-proxy signs the SHA-256 of its policy’s canonical JSON, and aga-mcp-server 3.6.0 through 3.6.2 signs an empty policy_reference.

Exhibit A · the receipt, anatomized. Fifteen fields, no more, no less.

receipt_id

one record, one identity

receipt_version

the format, pinned in-band

algorithm

Ed25519-SHA256-JCS, inside the signed body; this page's verifier, like /verify, checks the bundle's and checkpoint's labels, not this one (see /security)

timestamp

when the gateway decided

request_id

ties the receipt to the request

method

the protocol method invoked

tool_name

the tool the agent asked for

decision

PERMITTED or DENIED as aga-proxy emits it; verifiers check the signature over it, not the value

reason

why, in plain text

policy_reference

the SHA-256 of the policy’s canonical JSON on aga-proxy; empty in aga-mcp-server 3.6.0 through 3.6.2

arguments_hash

unsalted SHA-256 of the arguments, so a guessed argument set can be confirmed. In 3.6.0 through 3.6.2 a path-constraint denial’s signed reason names the path, and a denied-pattern denial’s names the matched pattern.

previous_receipt_hash

the chain link, inside the signed body

gateway_id

which boundary produced this

public_key

the key the record must answer to

signature

Ed25519 over the canonical body

Order is part of the record.

Each receipt carries the SHA-256 leaf of the receipt before it, inside its own signed body. Reorder two receipts and verification stops passing. Without the signing key, there is no quiet way to resequence this history. There is a detected way.

Exhibit B · the chain, drawn live from the sample bundle above

loading the chain from /sample-bundle.json…

Because the link sits inside the signed body, swapping two receipts is not a formatting change. Use the reorder lever on the bench above and watch chain integrity and the Merkle root stop matching.

A bundle cannot lose its tail without saying so.

Every leaf commits to a Merkle tree, and a required, gateway-signed checkpoint binds the root, the leaf count, and the chain head under one signature. Drop the last receipts and the checkpoint contradicts what remains. Truncation is not prevented. It is detectable, and detectable is the property a reviewer can actually use. One limit: an earlier genuine export presented as the current one verifies, because the verifier has no freshness input, so keep the latest checkpoint you received.

Exhibit C · the signed checkpoint from the sample bundle. Three bindings, one signature.

loading the checkpoint…

Proof does not require disclosure.

Arguments are committed by SHA-256 hash: a receipt carries arguments_hash, not the payload. In 3.6.0 through 3.6.2 (3.6.1 and 3.6.2 carry 3.6.0’s runtime), a path-constraint denial records the offending path in its signed reason, and a denied-pattern denial records the matched pattern. Hand an Evidence Bundle to whoever is checking you without handing over argument payloads beyond that. Verification never requires disclosing argument contents.

Exhibit D · what a receipt carries in place of the arguments

At runtime (the arguments; the record keeps their hash)

{ "query": "site status", "max_results": 5 }

SHA-256

SHA-256 of the illustrative arguments

loading…

The preimage on the left is illustrative, and the hash on the right is its SHA-256, checked against a digest fixed in this page, so a changed preimage shows a mismatch. Receipt 1’s real arguments_hash from the bundle is printed below it. What ships in the record is the digest, not the arguments (in 3.6.0 through 3.6.2 a path-constraint denial names the path in its signed reason, and a denied-pattern denial names the matched pattern).

Verification owes the vendor nothing.

The recorded history exports as one portable Evidence Bundle file. Once you have downloaded a compatible verifier, verification runs offline without an account or a callback to Attested Intelligence. Retain the bundle, verifier and independently obtained expected gateway key to preserve that verification path if our service becomes unavailable.

Exhibit E · what the verifier checks, in order

01Bundle structure, canonical receipt field names and bundle algorithm label. Not every signed field's value is validated; see known verifier limits.
02Every signature, receipt by receipt.
03Hash chain and ordering, link by link.
04Every Merkle proof to the signed root, with a complete index bijection.
05The signed checkpoint: root, leaf count, chain head.
06Envelope consistency.
07Provenance, additionally, when a gateway key is pinned. A pass means the record is intact. What a pass does not mean is stated plainly below.

Agreement is measured, not promised.

Three verifier implementations, written in three languages (JavaScript, Go, Python), return one verdict on all 61 classical cross-stack cases as the harness feeds them. Separately, 28 post-quantum cases are specified and reference-verified: an ML-DSA-65 plus Ed25519 hybrid, implemented and cross-verified as a library export, not the live default. Classical Ed25519 is the live profile. The published Python verifier, aga-governance, rejects nesting deeper than 100 levels and leaf indexes written as non-integers (1.0, 1e0), which the JavaScript verifier accepts, and one corpus case is spelled that way; in other cases the JavaScript verifier fails what the Python one accepts, and /security lists both. On the literal bytes of the corpus's float-spelled leaf_index case (0.0), aga-governance returns FAILED while aga-verify, aga-proxy verify and the reference verifiers return VERIFIED; the harness re-serializes object-level cases, so it exercises that case as an integer.

Exhibit F · the verification corpus, counted the way we count it

classical cross-stack cases in the public repository, runnable offline on your machine with Node, Go and Python. The downloadable zip carries three bundle vectors, not the corpus.

post-quantum cases, specified and reference-verified. ML-DSA-65 plus Ed25519 hybrid, a library export, implemented and cross-verified. Classical Ed25519 is the live profile.

verifier implementations in three languages, returning one verdict on every corpus case as the harness feeds them. The published Python verifier fails one float-spelled corpus case given its literal bytes; outside the corpus the verifiers differ in both directions.

The limits

What we will not claim.

A confident argument states its own limits before you find them. Here are ours, in the plainest words we have.

Limit 01 · coverage

“A verified bundle proves the integrity of every receipt present. It does not prove the operator recorded every action.”

Coverage is an operational property of a deployment. Integrity is what the math gives you. We prove integrity, and we say the coverage limit out loud.

Limit 02 · the record, not the act

AGA records and proves. In-path, the published aga-proxy does not forward a call it denies; its default profile, permissive, denies nothing on policy grounds, and policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode. Whether the agent has another route to the tool is a property of your deployment.

A Decision Receipt is the record of a decision. Beyond aga-proxy’s own forwarding, acting on that decision is wired per deployment, by you, and we will not pretend otherwise in a sales conversation.

Limit 03 · tamper-evident, not tamper-proof

Anyone can alter a receipt. Without the gateway key, no one can alter a signed value the verifier reads and leave verification against the pinned key passing. The key holder can re-sign a different history. A field name repeated in the file still verifies, because the verifiers read the last copy; read the verifier’s output (known issue 5 on /security).

You watched this on the bench. The red verdict is not a failure of the product. It is the product.

If a pitch in this category claims more than the above, ask for the verifier and run it offline. You now know what it should check.

Distribution · named, fetchable objects

/specThe published construction: fields, canonicalization, the six verification checks (seven with a pinned key), and why the prefix-free Merkle tree is safe here. /verifyThe in-browser verifier. Load any Evidence Bundle and check it here, with nothing sent anywhere. /sample-bundle.jsonThe bundle this bench runs on. The same file, byte for byte, that the verifier above checks. /verify#offlineDownload the zero-dependency verifier and the sample bundle. One command, offline, on your machine.

The invitation

The invitation stands.

You have read the argument and pushed on a live exhibit. Two ways to keep pushing, both built for people who do not take vendors at their word.

Static files · your machine · offline after download

Run the static evaluation.

Download the verifier and sample Evidence Bundle while online. Then use the documented Node.js command locally, with no package dependencies or network calls during verification. No gateway runtime is needed. Report any difference from this page's verdict.

Run the static evaluation

Bring your skepticism

Request info.

Ask us the question you would ask a vendor you do not trust yet. That is the correct posture. We answer with the format, the corpus, and the checkpoint math, not adjectives.

Request info