raucle

2026-05-29  ·  Craig McWilliams  ·  12 min read

Cryptographic provenance for AI workflows — a draft standard

Every prompt-injection mitigation in production today is a filter sitting in front of a model. We keep building better filters and the attacks keep getting through. The category has a structural problem and it isn’t solved by another classifier. Today we’re publishing a draft of what we think a real fix looks like: the Raucle Provenance Receipt v1 specification — a JWS-encoded, content-addressed, signed receipt of every action an agent takes.

The pattern keeps repeating

In 2023 a junior engineer pasted “ignore previous instructions” into a customer-service chatbot and got it to print its system prompt. The vendor added a filter.

In 2024 attackers hid the same instruction inside a PDF the agent retrieved from a vector store. The vendor added a filter.

In 2025 the same payload arrived as homoglyphs, then as base64, then as ASCII art, then as instructions encoded in the alt-text of an image. The vendor added filters.

Each filter is a model. Each model has an error rate. The composition of N independent classifiers each with a 5% false negative rate doesn’t give you 5% — it gives you whatever the highest single rate is, and the highest is the newest attack class no-one has seen yet. The output of every published red-team benchmark since 2023 is “state of the art models catch 92% of these prompts; we don’t know what they do on the 8%.”

That gap exists because the filter is the wrong primitive. It’s trying to answer “is this text bad?” when the question the user actually needs answered is “was this action authorised, by whom, on what evidence, and can I prove that to my regulator?”

The wrong primitive

Think about how this maps to a problem we already solved. Twenty years ago software supply chains had the same shape: a build artefact arrived, you ran it, and you had no way to know what code went into it, who compiled it, against what dependencies. The fix wasn’t a better antivirus scanner. The fix was SLSA, Sigstore, and the SBOM — cryptographic statements of where the bytes came from, verifiable offline, hard to forge.

AI agents need exactly that. A receipt for every action that says: this agent, signing with this key, executed this operation on this input, against this policy, with this verdict. The receipt is small (a few hundred bytes), signed (Ed25519), content-addressed (its identifier is the hash of its own signed bytes), and chains backward to its parents — the receipts of the actions that produced its inputs.

Stack those receipts together and you have a directed acyclic graph: the provenance graph of the agent’s behaviour. Hand that graph to anyone and they can verify, with no network call, that:

None of that asks the filter to be smarter. It asks the system to be honest about what it did. Honesty is cheaper than intelligence.

Four invariants the spec locks in

The draft is short — a single document with four MUST-level invariants:

  1. Offline verification. Anyone holding the issuer’s public key and the receipt can verify it without contacting any service. No call-home. No availability dependency. Critical for regulators reading historical evidence.
  2. Content addressing. A receipt’s ID is the SHA-256 of its own signed bytes. Two parties produce the same ID for the same receipt. This is what makes the provenance graph globally addressable without a registry.
  3. Taint monotonicity. Untrusted-input labels flow forward through every receipt. They can only be removed by an explicit, signed sanitisation step that names the labels it removed. A verifier that sees a taint silently disappear rejects the chain.
  4. Privacy by default. Receipts carry hashes, never prompt or output plaintext. A deployment that needs full disclosure attaches a separate encrypted content envelope; the receipt itself stays publishable.

Everything else — operations, fields, key bindings, capability statements, JWS envelope choices — flows from those four. The full draft is here, written with RFC 2119 conformance language and intended for public comment.

Why JWS, why Ed25519, why content addressing

A receipt is wrapped as a Compact JWS with typ=provenance-receipt/v1. That choice is deliberate. JWS is boring, well-implemented in every language, and easy for a verifier to inspect. The typ plus a crit=["raucle/v1"] header are specifically there to prevent a generic JWT library from accidentally accepting a receipt as a bearer token — that bug class has cost the industry enough.

Ed25519 because it’s small, fast, has no known catastrophic failures, and an Ed25519 signature is 64 bytes — a receipt-and-signature fits comfortably in a single MTU. SHA-256 because every auditor already trusts it. There’s a v2 slot for algorithm agility; v1 picks the boring options.

Content addressing — making the receipt’s identifier the hash of its own bytes — is the move that makes the format compose. With it, two independent organisations can refer to the same parent receipt by ID and arrive at the same answer with no shared infrastructure. Without it, you need a registry, a service, an SPOF.

What this lets you do that you couldn’t before

Once you have receipts for everything, a number of capabilities that today require trust suddenly require only verification:

What it deliberately doesn’t do

The spec does not define how chains are stored, how keys are distributed, how policies are evaluated, how receipts are exchanged between organisations. Those layers are out of scope on purpose. A standard that tries to define everything ships nothing. A standard that nails the wire format and leaves the rest to implementers ships a working ecosystem.

It is also not a filter, a classifier, or a replacement for one. The model that decides whether to ALLOW or BLOCK still has to be good. The spec just makes that decision auditable instead of asking you to take its word for it.

How to read this draft

If you build an agent framework, a guardrail engine, a retrieval layer, or a tool gateway, we’d like you to read the spec and tell us what would prevent you from emitting these receipts. If you’re a regulator, an auditor, or a SOC engineer, we’d like to know whether what it gives you is usable for the kind of evidence you actually look at. Either way:

What we’re asking for

The spec is small on purpose. It can be implemented in 500 lines of any language. The reason to make it a standard is not that it’s complex; it’s that the value is in everyone emitting the same format. If LangChain emits one shape, LlamaIndex another, and Bedrock a third, we’re back where we started — every verifier has to be every parser. So:

We’re submitting the draft to the OWASP AI Exchange and filing comment against the NIST AI RMF generative-AI profile. We’ll be presenting at AI security venues this autumn. If you ship any kind of AI agent infrastructure and you’d like to talk about adopting receipts, we’d love to hear from you.

Twenty years ago we figured out that software supply chains needed cryptographic provenance. Two decades later we’re shipping AI agents into regulated industries with less audit machinery than a Debian package. The next ten years of this industry are going to be a lot less painful if we get this part right early.

Read the spec →  ·  raucle-detect on GitHub  ·  raucle Cloud