"Prove to me that this content was generated by your AI system, at this specific time, without modification, under these specific conditions."

Not approximately. Not probably. Cryptographically, with a verifiable proof that doesn't require trusting the organisation making the claim.

This is not an exotic requirement. It's the same standard we apply to HTTPS certificates, code signing, and financial transaction records. We have solved this problem in every other domain where trust matters at scale. We have not solved it for AI outputs.

This article is about why that matters technically, what a correct solution actually requires architecturally, and why the problem is significantly harder than it first appears.

Why provenance matters more than detection

The dominant approach to AI content trust today is detection, training classifiers to identify whether content was AI-generated. This approach has a fundamental limitation that makes it unsuitable for high-stakes use cases: it produces probabilities, not proofs.

A detection model saying "87% likelihood this was AI-generated" is legally useless in a court filing, a financial audit, or an FDA documentation review. These contexts require non-repudiation, a cryptographically verifiable record that cannot be produced retroactively, cannot be forged without access to a private key, and can be independently verified by any party holding the public key.

Watermarking approaches including Google's SynthID improve on pure detection but still fall short. Watermarks can be stripped through paraphrasing, translation, or format conversion. They're embedded in the content, meaning any transformation risks destroying the provenance signal. And they require access to the watermark detector, there's no independent verification pathway without trusting the watermark issuer.

The correct mental model is not detection. It's attestation. The difference is architectural.

What cryptographic attestation actually requires

A correct AI output attestation system needs to solve several distinct technical problems simultaneously.

The binding problem

You need to cryptographically bind the output to the generation event in a way that's verifiable without storing the content itself. SHA-256 hashing solves this, the hash is a fingerprint that proves content integrity without requiring the attestation infrastructure to hold actual content. Privacy by design, not by policy.

The hash binding works both ways: given a hash in an attestation certificate, any party can verify whether a specific piece of content matches it. Given the content, any party can independently compute the hash and compare. No trusted intermediary required for verification.

The identity problem

The attestation needs to carry a verifiable cryptographic identity for the AI system that produced it, not a name string, but a certificate rooted in a hierarchy that can be independently validated. This means X.509 v3 certificates, a CA hierarchy with proper constraints, and OCSP revocation support.

The certificate hierarchy looks like this:

Root CA (offline, HSM-protected) │ ├── Provider CA │ ├── Anthropic Signing Certificate │ ├── OpenAI Signing Certificate
│ ├── Google Signing Certificate │ └── [Enterprise Deployment Certificates] │ └── Timestamp Authority (RFC 3161 compliant)

Verification of any attestation requires only the root CA public key, exactly how your browser verifies HTTPS. Independent, offline-capable, no trust required in the attestation infrastructure beyond the root certificate.

The timestamp problem

A timestamp embedded in a signed object is only meaningful if it's independently verifiable and provably cannot be backdated. This requires RFC 3161 Timestamp Authority integration, the TSA issues a signed timestamp token over the hash of the data being timestamped. The token is verifiable against the TSA's public key independently of the attestation provider.

Without RFC 3161, any claimed timestamp in an attestation can be set to any value by whoever controls the signing key. With RFC 3161, the timestamp is independently anchored.

The modification chain problem

AI-generated content is almost always edited by humans before use. A provenance system that only attests to generation and treats any subsequent modification as invalidating the attestation is practically unusable.

The correct approach is delta attestation, a chain of attestation objects where each modification event produces a new attestation that references its parent:

{ "attestation_id": "uuid-v4-002", "modification_chain": { "parent_attestation_id": "uuid-v4-001", "modification_type": "human_edit", "human_modified": true, "modifier_identity": "" } }

This maintains the full provenance chain through the content lifecycle while accurately representing what happened at each step.

The open-source model problem

Closed AI providers can integrate attestation at the API layer, their infrastructure issues certificates as part of the generation response. Open-source models deployed on private infrastructure have no centralised authority to issue provider certificates.

The solution is a sidecar attestation agent, a trusted module deployed alongside the model that:

• Holds a signing certificate issued under an enterprise CA sub-hierarchy

• Intercepts generation requests and responses

• Issues attestation objects for each generation event

• Maintains a local append-only audit log anchored to the enterprise's PKI

This means an organisation running Llama on their own infrastructure can issue attestation certificates under their own CA, with certificates traceable to the AI Notary root through the enterprise CA chain.

The multi-model pipeline problem

Modern AI workflows chain multiple models. A document drafted by GPT-4, edited by Claude, with images from a diffusion model, assembled by an agent, no current approach handles this.

The correct data structure is a provenance DAG, a directed acyclic graph of attestation objects where each node references its parents:

{ "attestation_id": "uuid-final", "provenance_graph": { "parents": [ "uuid-gpt4-draft", "uuid-claude-edit", "uuid-dalle-image" ], "assembly_agent": "uuid-agent-session" } }

This enables full reconstruction of the generation pipeline and attribution of each component to its source model.

The core attestation object specification

Pulling these requirements together, the Attestation Object looks like this:

{ "aon_version": "1.0", "attestation_id": "550e8400-e29b-41d4-a716-446655440000", "timestamp": { "iso8601": "2026-06-09T06:00:00Z", "rfc3161_token": "", "unix_epoch": 1780000000 }, "ai_system": { "provider_id": "anthropic", "model_id": "claude-sonnet-4-6", "model_version_hash": "sha256:3a4f...", "deployment_environment": "cloud_api", "provider_certificate": "<X.509 cert chain>" }, "content_hashes": { "input_hash": "sha256:7b2c...", "output_hash": "sha256:9d1e...", "hash_algorithm": "SHA-256" }, "generation_context": { "authorizing_entity": "", "policy_version": "v2.3", "constraints_active": [ "safety_filter_v3", "output_length_4096" ], "agent_session_id": null }, "modification_chain": { "parent_attestation_id": null, "modification_type": "original", "human_modified": false }, "cryptographic_proof": { "signature": "", "signing_certificate": "", "certificate_chain": "", "revocation_check": "ocsp_stapled" } }

The signature covers the canonical JSON serialisation of all fields except cryptographic_proof itself. Verification is straightforward: serialise the object without the proof field, verify the signature against the signing certificate, validate the certificate chain to the root CA, check OCSP status, verify the RFC 3161 timestamp token.

The three genuinely unsolved problems

Zero-knowledge attestation properties

There are cases where you need to verify that a generation had specific properties, "safety filtering was active," "this was generated within an authorised policy scope," without revealing the content or the full generation context.

ZK-SNARKs can theoretically solve this: prove properties of the generation context without revealing the context itself. The practical implementation for high-throughput AI attestation, millions of attestations per day with sub-100ms latency, hasn't been built. The constraint is prover performance: current ZK proof generation is too slow for inline attestation at this scale.

The open questions: Can recursive SNARKs (Plonky2, Nova) bring prover time down sufficiently? Is there a simpler commitment scheme that provides sufficient privacy guarantees without full ZK proof generation?

Algorithm agility for post-quantum transition

ECDSA P-384 is correct today but has a known quantum vulnerability horizon. NIST has standardised CRYSTALS-Dilithium (ML-DSA) for post-quantum signatures. The challenge is building an attestation infrastructure with genuine algorithm agility, able to issue certificates under multiple signature schemes simultaneously, verify either scheme, and migrate existing certificate chains without invalidating historical attestations.

The certificate extension design for algorithm agility isn't standardised. How do you encode a dual-signature certificate that's valid under both ECDSA and ML-DSA? How do you handle the certificate chain when intermediate CAs have been re-keyed under a new algorithm?

Agent action attestation

When an autonomous agent executes a sequence of actions across multiple sessions, API calls, file modifications, communications, web interactions, attesting to individual outputs isn't sufficient. You need a tamper-proof causal chain of the agent's decision process.

The data structure for this is closer to an append-only ledger than a certificate. Each action produces an entry that references the previous entry's hash, creating a chain where any modification of a historical entry invalidates all subsequent entries. The root of the chain is anchored periodically to a public, independently verifiable record.

The open question is the verification model: who holds the chain, how is it anchored, and how do you handle distributed agent systems where multiple agents contribute to a single task?

Why this window is short

The history of internet infrastructure shows a consistent pattern: the window between "a trust standard needs to exist" and "one implementation owns the standard" is short, and the winner is usually the implementation that achieves regulatory recognition first, not the one with the best technology.

Certificate Authorities became entrenched when browsers adopted trusted root programs. DNS registrars became entrenched when ICANN delegation became the standard. In each case, technical merit mattered less than timing and regulatory positioning.

The EU AI Act's audit trail requirements are in enforcement. The C2PA standard exists as a technical foundation. No dominant commercial implementation of horizontal AI attestation infrastructure has emerged.

That window is open. The technical problems are tractable. The regulatory forcing function exists. The question is whether someone builds this with the right combination of cryptographic rigour and standards body engagement to claim the position before a hyperscaler decides to own it by default.

I'm currently building this infrastructure and thinking through the unsolved problems above. If you're working on ZK proof systems, post-quantum cryptography, or distributed audit logs and have thoughts on any of these problems, I'd genuinely like to hear from you in the comments.

I'm also looking for a technical co-founder with cryptography and backend engineering depth. If this problem space resonates with how you think about systems, feel free to reach out.

#cryptography #security #ai #distributedsystems