DEV Community

Imran Siddique
Imran Siddique

Posted on • Originally published at Medium on

The industry scheduled the proof. Here is what provable inference has to prove.

#machinelearning #confidentialcomputin #attestation #agents

Something quiet and remarkable showed up on the frontier labs’ safety roadmaps this year. Not a bigger model. Not a new benchmark. A commitment to provable inference: a technique to cryptographically sign a model’s output so it can be tied back to a specific, unmodified set of weights. In plain terms, a proof that this output came from that model, and not from a tampered copy, a quietly quantized substitute, or someone else’s fork wearing the same name.

For a newsletter called Proof not Promises, I could not let that pass. A frontier lab writing “the proof” onto a dated roadmap, with a prototype targeted inside the next year, is the most on-the-nose thing to happen in this field all year. It is also, today, a promise. So let me do the useful thing and walk through what a real proof would actually have to deliver, and where the whole ecosystem honestly stands. Because the gap between the roadmap bullet and a shipped artifact is exactly the thing worth understanding.

What a proof of inference actually has to bind

Strip it to the claim you want to make: these exact weights, given this exact input, produced this exact output, and a hostile operator could not have faked any of it. To be a proof rather than a promise, one verifiable statement has to bind four things at once:

  • the weights (a hash of the specific, unmodified checkpoint),
  • the input (the prompt and context that went in),
  • the decode parameters (temperature, seed, sampling, everything that makes the run reproducible),
  • the output (the tokens that came out).

Miss any one and you do not have a proof; you have a story. Bind all four in a way that does not require trusting the machine that ran it, and you have something new. Nobody ships that today. Here are the three ways people are trying, and where each honestly lands.

Option 1: prove the math. Real, and far too slow.

The cryptographic gold standard is a zero-knowledge proof of the forward pass: prove the computation ran with committed weights, with no trust in the hardware at all. This is the real thing, and it is genuinely advancing. But be honest about the numbers. Proving a 13-billion-parameter inference takes on the order of fifteen minutes, and the newest work (zkComposer, July 2026) buys roughly a 6.8x speedup on GPT-2-scale models. Real-time proof of a frontier-scale (100B+) model is explicitly beyond the state of the art, the proving overhead is still orders of magnitude over just running the model. zkML is real for small models and settlement-style checks. Anyone selling “zero-knowledge proof of frontier-class inference, in production” is selling the roadmap, not the artifact.

Option 2: trust the hardware. Fast, and forgeable by the one adversary that matters.

The pragmatic path is a hardware attestation: run the model inside a confidential-computing enclave and have the chip sign a statement that it loaded the right thing. Fast, production-ready, and it is what most “confidential AI” is built on. The catch is what the signature actually means. Its entire trust root is the hardware vendor’s key, and TEE.fail showed a sub-$1,000 memory-bus interposer extracting those keys and forging attestation quotes that pass the vendor’s own verifier, across Intel TDX, AMD SEV-SNP, and NVIDIA’s GPU confidential computing. The vendors’ on-record response was that physical attacks are out of scope. Read that plainly: against a party who owns the box, which is precisely the on-prem and sovereign deployments where this matters most, a signed quote is not a proof of anything. That is not my opinion, it is the vendors’ stated threat model.

Option 3: watermark the output. A courtesy, not a proof.

The third path is content provenance: watermark the generated text or image so it can be traced. The big convergence landed in May 2026, with the major players committing to embed watermarks alongside C2PA content credentials. Useful for disclosure. Not a proof. The metadata layer is strippable, open-source watermark removers appeared within days, and the majority of models in the wild are unwatermarked and cannot be watermarked after the fact. Provenance that the generator opts into and an adversary can strip is transparency, not attestation. It is a courtesy signal, and worth having as one, but do not mistake it for the thing on the roadmap.

The honest synthesis

Today, the strongest thing anyone can truthfully attest is “this hardware, under this vendor’s threat model, said it ran something.” Binding “these exact weights produced this exact output, and a hostile operator could not have faked it” is unsolved at frontier scale. That is not a knock on the labs. It is the actual frontier, and it is why putting it on a roadmap is honest and welcome. A promise made in public is still a promise worth making.

The half you do not have to wait for

Here is the part I care about. Provable inference is the output-attribution half of the problem. There is an input-attribution half you can have today: proving which weights are loaded, and that they are the unmodified, certified checkpoint, before a single token is generated. That is weight integrity, custody, and derivative lineage, and it is open source and installable today, pip install weight-custody-manifest, not a roadmap item. The logic is simple. You cannot prove an output came from certified weights if you cannot first prove the weights are certified. Start there, because it is available, and because it is the foundation the output proof will have to stand on.

And keep the honesty that this newsletter is named for: even that foundation is accountability-grade, not silicon-proof, against someone who physically owns the hardware, for exactly the TEE.fail reason above. We say so out loud, because leading with the limit is what separates a proof from a pitch.

Try it out

The input half is one install away. Bind the exact checkpoint into a signed manifest, and the decryption key releases only into the attested, builder-signed serving stack. A tampered fork gets nothing.

pip install weight-custody-manifest

verify_manifest(m, ctx).ok # True -> this is the certified manifest
kbs.verify_and_release(m, certified).released # True -> key releases into the attested stack
kbs.verify_and_release(m, tampered).released # False -> a tampered fork never decrypts
Enter fullscreen mode Exit fullscreen mode

That is real, open code, not a mock. Runnable end-to-end examples, for open-weight and closed-weight models, threshold release, transparency log, and derivative lineage, are in the open at github.com/agentrust-io/examples.

The line

Transparency is not attestation. A roadmap is a promise. A proof binds the artifact. The labs scheduled the output half, and that is good news. The artifact-integrity half, you can verify in the open today. So, verify the weights you can, name the limits you cannot yet beat, and build the layer that proves it, in the open, while the proof of the rest gets written.

Sources

Top comments (0)