DEV Community

Pulkit Srivastava
Pulkit Srivastava

Posted on

I built a cryptographic audit receipt for Claude Mythos (and any AI model) — here's how it works

Anthropic's Mythos model can autonomously find zero-day
vulnerabilities. Their CVD disclosure process uses manual
SHA-3-512 hash commitments to prove findings existed.

I built something that automates that in one line of Python.

What AetherProof does

One function call generates a 128-byte Ed25519-signed receipt
that proves:

  • What model ran — FNV-1a hash of provider/model ID
  • What it produced — hash of the output
  • When — cryptographic nanosecond timestamp
  • Tamper-evident — flip any byte anywhere → INVALID

python
import aetherproof

receipt = aetherproof.for_anthropic(
    "Find vulnerabilities in this binary.",
    finding_text,
    model="claude-mythos-preview"
)

receipt.save("CVE-2026-001.receipt")
print(receipt.verify())  # True
Try it in 30 seconds

pip install aetherproof
python -c "
import aetherproof
r = aetherproof.for_anthropic('question', 'answer')
print(r.verify())   # True
print(r.pretty())
"
The unusual part — invisible Unicode watermarking
Receipts embed invisibly into any text using Unicode
Private Use Area codepoints (U+E000–U+E0FF).

AI output carries its own audit trail. Works in any language —
Arabic, Chinese, Devanagari, Hebrew, Thai, Japanese all tested.


signed_output = aetherproof.embed(ai_response, receipt.to_bytes())
# Text looks identical. Receipt is inside.

aetherproof.verify_embedded(signed_output)  # True
Numbers
187 tests, 0 failures
128/128 byte flips all detected
1000/1000 tamper probes pass
Cross-language: Python generates, Rust CLI verifies
15,446 receipts/sec (Python) · 5,472/sec (Rust)
Why AGPL-3.0
Free for open source. Commercial use needs a license.
This is the compliance layer under your AI stack —
it should be open, auditable, and not vendor-locked.

GitHub
https://github.com/pulkit6732/aetherproof

Built by Pulkit. Feedback welcome.
Enter fullscreen mode Exit fullscreen mode

Top comments (2)

Collapse
 
harjjotsinghh profile image
Harjot Singh

A cryptographic, tamper-evident receipt for an AI interaction is exactly the primitive the agent world is missing - "what did the model produce, from what input, when, and can I prove it wasn't altered after the fact." As agents start taking real actions, you need provenance you can't repudiate: signed proof of the prompt, the output, and the context, so a dispute ("the AI told me to do X" / "no it didn't") has a verifiable answer instead of a he-said-she-said. That's the audit/non-repudiation layer that every serious agent deployment will eventually need and almost nobody's building yet.

This maps directly onto the trust problems I care about - attribution and verifiability for AI actions. In Moonshift, the thing I work on (a multi-agent pipeline that takes a prompt to a deployed SaaS), every step emits a trace so there's always an answer to "what did the agent do and on what basis"; a cryptographic receipt is the hardened version of that, turning the trace into proof. Genuinely forward-looking work - this becomes essential the moment agents touch money or compliance. Multi-model routing keeps a build ~$3 flat, first run free no card. Real question: what's the receipt binding over - just prompt+output hashes, or the full context/tool-calls too? And is it anchored anywhere (a transparency log/chain) or self-contained signatures? Anchoring is what makes it survive a hostile dispute.

Collapse
 
pulkit_srivastava_8ce4f05 profile image
Pulkit Srivastava

Both questions go to the heart of the design.
Binding scope: The receipt covers model identity (SHA-256 Merkle root of weights — so model version is part of the proof, not just a string), input commitment, output hash, timestamp, and a hardware evidence array from the attestation chain. Tool-call / agent chain binding is the next layer — architecturally it's receipt chaining where each step signs over the previous receipt's hash, so you get a provenance graph for the full pipeline, not just leaf outputs. That's the piece that makes it useful for something like Moonshift.
Anchoring: Current receipts are self-contained — Ed25519 + ML-KEM hybrid, offline verifiable forever, no dependency on any server. A transparency log (3-witness network, think Certificate Transparency but for inference) is on the roadmap; you're right that anchoring is what makes it survive a truly hostile dispute where the receipt issuer is the disputed party. Self-contained signatures cover the "prove it wasn't altered" case; anchored inclusion proofs cover "prove it was issued before time T and not backdated." Both matter in different threat models.
The Moonshift use case — every step in an agent pipeline emitting a chained receipt — is exactly the deployment pattern I'm building toward. Would be interested to talk.