Proof of value · In-browser verifier

Verify the record yourself.

One real AGA SEP Evidence Bundle: four agent decisions, a hash chain, a Merkle tree, and a signed checkpoint. Seven cryptographic checks run live in this browser. Then tamper with it and watch the exact check catch you.

Open your network tab. This page makes zero requests to verify. A decision record you can check anywhere, offline.

Zero AGA imports Ed25519 + SHA-256 Works offline

Watch it verify

The clean bundle below is checked live and returns VERIFIED. All seven cryptographic checks pass, provenance included.

Break it yourself

Press a tamper button to flip one byte or drop one receipt. Watch the exact check that catches it turn red, then reset.

Bring your own bundle

Scroll to Verify your own bundle, paste or drop any AGA SEP bundle, and run the same six structural and cryptographic checks on your data.

Loading the sample bundle…

The honest differentiator

Don't trust this page? Independently implemented in three languages, one verdict.

A single verifier is one witness. AGA ships reference verifiers in three languages, JavaScript, Go, and Python, plus a zero-dependency Ed25519 path inside Python. The clean bundle verifies on all of them. Every tamper below fails on all of them, and they agree on which internal check catches it. Re-run any one and reach the same verdict. The table is a real captured run.

Mutation	Check(s) that FAIL, identical on every stack	JS	Go	Py (audited)	Py (stdlib)
sample bundle (unmodified)	all 7 steps pass	VER	VER	VER	VER
Flip one signature byte	receipt_signatures, chain_and_ordering, merkle_and_bijection	FAIL	FAIL	FAIL	FAIL
Drop a receipt	structural, merkle_and_bijection, signed_checkpoint	FAIL	FAIL	FAIL	FAIL
Reorder receipts	chain_and_ordering, merkle_and_bijection	FAIL	FAIL	FAIL	FAIL
Alter a decision field	receipt_signatures, chain_and_ordering, merkle_and_bijection	FAIL	FAIL	FAIL	FAIL
Corrupt the checkpoint root	signed_checkpoint	FAIL	FAIL	FAIL	FAIL
Corrupt the envelope root	envelope_consistency	FAIL	FAIL	FAIL	FAIL

Captured run: 1 clean + 6 tampered bundles × 4 verifier engines = 28 verifications, plus the published npx @attested-intelligence/aga-verify on the clean bundle. Zero disagreements.

Post-quantum · Reference profile

The spec corpus carries ML-DSA-65 vectors. The live signer does not use them.

Everything you verified above is classical Ed25519-SHA256-JCS, what the gateway signs and what this page checks. Separately, the AGA conformance corpus also carries NIST FIPS 204 ML-DSA-65 post-quantum known-answer vectors, and the ML-DSA-65+Ed25519 composite profile is specified and reference-verified across two language oracles (a @noble/JavaScript engine and a CIRCL/Go oracle) in the reference implementation. The live gateway and the aga-verify CLI sign and verify classical Ed25519 only. Those are a reference and specification profile, not the live signing default. No ML-DSA code path runs on this page.

ML-DSA-65 known-answer vectors (NIST ACVP, FIPS 204)

Reference profile, not the live default

These are the standardized NIST ACVP known-answer vectors the composite profile is tested against. The reference verifier backend runs them as a gate: accept every valid signature, reject every invalid one.

KeyGen KAT

✓ PASS

SigGen KAT

✓ PASS

SigVer KAT

✓ PASS · 15 cases

Parameter set

ML-DSA-65

SigVer accept / reject

3 valid, 12 invalid

Interface

external / pure

Read this precisely. The bundle above, the live gateway output, and this in-browser checker are all classical Ed25519. The ML-DSA-65 result shown here is a captured run of the reference backend against the NIST vectors, evidence that the spec and corpus profile exists and passes. It is not a claim that the gateway signs post-quantum.

Honest scope

What this proves, and what it does not.

This demo proves the integrity of the records present: nobody outside the gateway can alter, reorder, or trim this bundle without detection, and that detection is available to anyone, offline, in any of three stacks. It does not constrain the gateway itself. One key signs both the receipts and the checkpoint, so a gateway that is also the party under audit can drop trailing receipts, rebuild the tree, re-sign a shorter checkpoint, and pass every check on this page including the pinned-key check. A PASS establishes what was recorded and signed. It does not prove that every action an agent took was recorded. That capture property is separate.

Classical Ed25519, not post-quantum in the live path.
The live signing default here, in this bundle, in the live gateway output, and in the interactive checks above, is Ed25519-SHA256-JCS. No ML-DSA signature path runs on this page. The ML-DSA-65 panel above is a captured reference-corpus result, clearly labeled as a spec profile.
Integrity, provenance, and order, not runtime blocking.
Tampering with a decision record is detectable. This does not show runtime blocking or quarantine of a live agent, which is a separate and more limited capability.
Tampers are structurally realistic but synthetic.
They are programmatic single-field or single-byte mutations of a real signed bundle, chosen to hit each distinct check class, not captured from an in-the-wild attack.
One gateway key.
Every receipt here is signed by a single demo gateway key (aga-demo-001). Multi-issuer and key-rotation scenarios are out of scope for this demo.

Verify us without trusting us

The verifier is published. Check us with it.

The same Ed25519-SHA256-JCS construction the gateway signs with is published as a standalone command-line verifier on npm. It is our own package, so the point is not that we vouch for it: run it yourself, or run the VerifyBundle offline verifier in your browser. The format is specified so you can re-implement it. The package ships with SLSA build provenance; verify the attestation on /provenance.

$ npx -y @attested-intelligence/aga-verify@2.1.1 evidence-bundle.json

Offline verifier (VerifyBundle) aga-verify on npm

What you get depends on the key. Without a pinned key the verifier confirms integrity only: that the bundle is internally consistent under its own key. Pin the gateway key to also prove who issued it and to rule out whole-bundle re-signing.

The demo gateway key is a published fixture, and a live deployment uses a persisted key (the server’s default key is ephemeral).

Prefer the upload-first tool? Open the offline verifier.