A separate product from Attested Intelligence
VerifyBundle seals files.
AGA records decisions.
Seal a file or note in your browser and retain a portable record you can check offline. VerifyBundle shares AGA's cryptographic construction, but uses its own format and verifier. It is not an AGA bundle viewer.
Two formats, two verification paths
Choose the record for the task.
- AGA decision records
- Retains signed governance decisions in a hash-linked receipt chain and evidence bundle. The operational default and live gateway use Ed25519. Use the AGA verifier and an expected gateway key obtained through a separately trusted channel. Architecture and deployment limits.
- VerifyBundle file records
- Seals file or note content client-side in a portable record. Its durable path uses an ML-DSA-65 + Ed25519 composite seal. A record has one seal, not AGA's multi-receipt history. The file contents stay in your browser; online time attestation sends the content hash to VerifyBundle's time service. Use VerifyBundle's own pinned verifier.
AGA also specifies a hybrid library profile, shipped in aga-mcp-server but not implemented by aga-verify. Its ML-DSA-65 primitive is checked against NIST FIPS 204 known-answer vectors in the private reference runtime's test suite. That profile is not the live AGA signer. Profile and conformance scope.
Published fixture
Inspect the downloadable record.
- Title
- VerifyBundle sample record
- Data
- content.txt, 234 bytes of text
- SHA-256 of the data
- 918492be4f7a4892a9e0d64512df7a58c991249e0d844f667777337a584b7cf1
- Merkle root
- b4ffcc4005f6a511ed896b2ac55ba2251326dfd0b14c39e28ec3f4bfd5a08910
- Signature
- ML-DSA-65+Ed25519-SHA256-JCS
- Public key
- composite key, carried in the file
- Sealed
- 2026-08-30 20:47:32 UTC, server-attested
- File
- sample-record.vbundle, 17,264 bytes
- File SHA-256
- bdf13c3ae9f4a2eb6e58d72597c745f36bc7a52b612e0d9b2294b7f2e52ccb2c
Every line above is read from sample-record.vbundle, the sample record verifybundle.com serves for download. Its one receipt is the Merkle tree’s only leaf, so the root equals that leaf’s hash. Download it, compare the file’s SHA-256, and verify it offline with VerifyBundle’s verifier. The verifybundle.com homepage shows a different record, a build-time Ed25519 sample.
Current release
Bounded verification with a retained offline artifact.
The September 30 release refuses ambiguous JSON and unsupported ZIP structures, verifies in a cancellable worker and clears prior verdicts when the expected key changes. A supplied malformed key fails; omission remains integrity-only. The previous verifier, specification and vectors retain their original bytes and terms. Verification tests do not establish authorship, capture completeness or independent time-service qualification.
What verification establishes
Integrity, key identity and time are different checks.
- Sealed-content integrity
- A passing check establishes that the sealed content matches the signature under the record's key. Changing covered bytes fails that check. The archive README is not signed, and other metadata is not automatically covered. Anyone can seal changed content under a different key, so retain an independently obtained expected key or record hash to detect substitution.
- Who made the record
- The seal uses an ephemeral key and carries no verified issuer identity. Its public key remains in the record; discarding the private key does not remove that public key. Matching a key authenticates only the key. Connecting it to a person or organization requires a separately trusted exchange. The same identity-mapping requirement applies to AGA gateway-key pinning.
- Online time attestation
- For supported records, VerifyBundle's time service signs a timestamp bound to the sealed content hash using Ed25519. Verification against the published time key authenticates that service's statement. Relying on the stated time also requires trusting the service and its clock. The statement does not cover the title, filename, private fields or sealing key, and is not an accredited timestamping service.
- Offline sealing time
- An offline-created record has a self-reported device timestamp. Its seal can still be checked, but the timestamp is not an independently corroborated existence time.
- Later offline verification
- After obtaining the record, compatible verifier and expected trust material, verification can run locally without contacting the producer. Obtaining those files initially may require a connection. Keep the verifier and its published SHA-256 with the record; the record alone does not supply an independently trusted implementation.
What a pass does not establish
It does not establish that the contents are true, that the creator had authority, or that a legal requirement is met. The hybrid seal is intended to resist classical and quantum forgery under its cryptographic assumptions; the optional time attestation remains Ed25519. Do not describe the entire record's time and identity assurances as post-quantum.
Use the matching verifier.
aga-verify does not verify VerifyBundle records. VerifyBundle's standard page provides its format, offline verifier and published trust-root instructions. A shared construction does not make the two formats interchangeable.