FlashProve: How AI Answers Become Provable With Zero Knowledge

Posted on by
Contents show
FlashProve

Every time you send a prompt to an AI provider, you take one thing on faith: that the model answering is the model you chose. FlashProve exists to take that faith out of the transaction. A routing layer under pressure to cut costs could quietly swap in a cheaper one. An attacker who compromised an inference server could tamper with the tokens on their way out. Nothing in the reply itself betrays either substitution, because text has no signature, and asking the provider to confirm is asking the suspect to investigate themselves.

FlashProve, a new open source research prototype from Anthropic's Frontier Red Team, removes that element of faith, and it does so with the one tool that cannot be argued with: mathematics. FlashProve is a zkSNARK system for provable inference: the provider attaches a cryptographic proof to each response showing that a specifically committed model produced exactly those tokens, while the proof itself reveals nothing about the model's weights.

The headline result sounds modest until you know the history. FlashProve proves a 400B-parameter mixture-of-experts model, Llama 4 Maverick in 4-bit quantization, at roughly 110 tokens per second on a single H100, with proofs that a CPU verifies in seconds. Earlier open source zkML systems needed hours to prove small models. This one runs at frontier scale, at speeds measured in fractions rather than multiples of inference.

This article explains what FlashProve actually proves, why the engineering is harder than the cryptography, what it costs in GPU time, and where the honest limits sit.

The problem nobody could verify

The gap FlashProve targets is easy to state and surprisingly hard to close, because verification collides with confidentiality at every turn. When a response arrives, you can check that it is fluent, relevant and correct. You cannot check that it came from the weights you are paying for.

Three scenarios make that gap dangerous rather than theoretical. A routing service optimizing its margin serves a smaller model while billing for a larger one, a substitution that output quality alone cannot expose because small models produce fluent text. An attacker who compromises an inference server rewrites the token stream, potentially delivering poisoned answers to every downstream consumer. And an advanced model quietly substitutes itself for a weaker one to escape the monitoring that applies to its smaller sibling, a scenario Anthropic's own safety framework takes seriously.

The usual responses are all incomplete. Logs come from the provider, who is the party being audited. Hashing the weights proves a version but not a response. Running the model yourself to compare outputs costs as much as the provider's whole operation.

What is needed is a proof that binds a response to a commitment on the weights, is cheap for anyone to check, and reveals none of the weights it vouches for. FlashProve is a claimed instance of exactly that object. That combination has a name in cryptography, and it is zero knowledge.

What FlashProve actually proves

FlashProve has two parties. The provider is the prover. The user, auditor or regulator is the verifier.

In FlashProve's offline phase, run once per model, the provider publishes a commitment: a short fingerprint that pins down one exact set of weights while hiding them. Generating it takes about 39 minutes, and one commitment covers roughly 16 million requests before the provider must commit again.

In the online phase, for each request, the provider's GPU produces a proof for a precise statement: the committed model, evaluated on this prompt, produces exactly these output tokens. Anyone holding the commitment, the prompt and the reply can check the proof without the weights and without a GPU.

Two properties make a FlashProve proof meaningful rather than decorative. Zero knowledge means the verifier learns nothing about the weights, the intermediate computation, or which experts fired at each layer. Succinctness means an attested computation, running a 232 GB quantized model on an H100, compresses into an 18.78 MB proof that a 24-core CPU checks in 17 seconds. An auditor with a laptop can therefore verify claims from a provider with a datacenter, which inverts the usual trust asymmetry.

The protocol itself compiles an interactive oracle proof into a cryptographic one using hash functions, the same family of systems that validity-proof blockchains such as Starknet use, and Anthropic states it offers post-quantum security.

What it costs, honestly

The FlashProve numbers, measured on the public 4-bit Maverick weights with one H100 and 24 CPU cores:

  • Proving throughput: about 111 tokens per second at a batch of 24, with each batch taking roughly 221 to 226 seconds. A single request proves at 17.4 tokens per second.
  • Proof size: 18.78 MB per 1,024-token request, plus a one-time 6.5 MB commitment download.
  • Verification: 17 seconds on 24 threads, 21 seconds on one thread, no GPU.
  • Context: 1,024 tokens per request, greedy decoding, MoE models.

The cost sits entirely with the provider. Proving a batch takes about 72 times the GPU time of plain vLLM inference on the same hardware, rising to about 94 times at vLLM's highest tested load. Provably honest inference is, for now, roughly two orders of magnitude more expensive than ordinary inference, and that ratio is the real barrier between prototype and product.

Three FlashProve engineering choices make even that possible, and each is worth understanding. Prover work scales with the roughly 17B parameters that activate per token rather than the full 400B, which is what makes a mixture-of-experts model tractable at all. Requests are proved in batches after the fact, like prefill, so the GPU amortizes setup across a group. And weights stream from host memory during proving, which is why a single 80 GB card suffices for a 232 GB model.

The comparison with earlier zkML systems is where FlashProve's progress shows. Prior open source zkML work proved 13B models in minutes or GPT-2 at a few tokens per second. One earlier system needed 17.7 hours to verify 1,000 tokens. FlashProve proves a 400B model at 110 tokens per second, which is not an increment but a change of regime.

How a proof can hide 232 GB of secrets

The phrase zero knowledge invites justified suspicion, because it sounds like marketing. The intuition is older than AI and worth thirty seconds.

A zkSNARK converts a computation into an arithmetic circuit, a giant set of equations, and then produces a certificate that all equations hold, without exposing the values that fed them. The verifier checks the certificate, not the computation. The trick that makes this affordable is to compile an interactive protocol, where a verifier would interrogate the prover step by step, into a single non-interactive object using hash functions, a technique the blockchain world standardized under the name STARK. What FlashProve adds is the front end: encoding the forward pass of a large mixture-of-experts model into that form without exploding the cost.

The engineering inside that front end is where the red team earned its name. Routing the computation so that only the roughly 17B active parameters per token enter the circuit. Streaming quantized weights from host memory so the GPU never needs to hold 232 GB. Batching requests so fixed setup costs amortize. None of these are cryptography. All of them decide whether the cryptography is usable.

There is a quiet irony in the release notes worth pausing on: the optimization work that made the system fast was done by Claude, the same family of models whose outputs the system is designed to verify. The research post is matter-of-fact about this, and the Lean formalization is the safety net that makes the irony harmless. The lesson generalizes beyond this release. When AI writes the security machinery, the machinery needs proofs, not code review.

The red team angle, and the Lean proof

Cryptographic code is notoriously brittle. A subtle bug in a proof system usually fails open, accepting forged proofs rather than rejecting honest ones, and the whole point of the exercise collapses.

Anthropic's answer is unusual for an AI lab: FlashProve's soundness is formalized in Lean 4, a proof assistant, with machine-checked statements of completeness, soundness and zero knowledge. The stated security bound is concrete: a cheating provider is caught, except with probability about q divided by 2 to the 124th power, plus 2 to the negative 101st, after q hash queries. Numbers that small are, practically, zero.

FlashProve ships two verifiers, and the distinction matters. A fast C++ verifier is for daily use but carries no formal guarantee. A slower Lean verifier is proven to accept exactly what the soundness theorem accepts. An auditor who needs the guarantee runs the slow one; an engineer checking throughput runs the fast one. The README also notes that Claude helped optimize the system, an interesting data point in the recurring debate about AI-written cryptographic code, handled here by having the formal proof arbitrate rather than the author.

The provenance is also part of the story. The work sits under Anthropic's Frontier Safety Roadmap, which committed to a provable inference prototype by September 30, 2026, a goal met by a separate signing-and-recomputation system; FlashProve pursues the same objective by a purely cryptographic route. Releasing it through a red team rather than a product team signals the intended audience: adversaries and auditors first, customers later.

Who needs it, in plain terms

The phrase cryptographic proof can obscure who actually benefits, so it is worth naming the roles.

A procurement team buying model access gets a contract term that can be checked automatically rather than litigated after a quality regression. A security engineer gets tamper evidence on the serving path, the layer that the LiteLLM supply chain attack showed is genuinely targeted. A compliance officer gets a mechanism to demonstrate that only approved models served customer traffic, which is the kind of control upcoming AI regulation is expected to ask for. And a model lab gets a way to show evaluators and governments that the weights it committed to are the weights doing the answering, which matters as much to the honest provider as to the suspicious customer.

Each of these roles needs something slightly different from FlashProve, and the prototype is not yet the finished product for any of them. What they share is the underlying need: an answer whose origin can be checked by the party who depends on it, without trusting the party who produced it.

What it is good for

Four applications justify the cost, in rough order of nearness.

Model routing integrity is the most direct FlashProve use case. A customer paying for frontier weights through a gateway gets a proof with each response and a one-command check, which turns “trust us” into a verification. Given how routing platforms advertise and mix models today, that is a real gap, and it is the one our earlier coverage of model routing economics flagged: the opacity is structural, not incidental.

Independent evaluation is the second FlashProve application, and arguably the nearest. Evaluators testing a model before release need to know the served model is the released model. A proof chain binds every evaluation response to the committed weights, closing the substitution loophole that has quietly haunted third-party benchmarks.

Tamper detection is the internal FlashProve case, and the one with the clearest immediate value. A provider requiring a valid proof from every inference server makes a compromised server immediately visible, because the attacker cannot produce proofs for weights they do not hold. This complements the runtime monitoring described in our piece on continuous security monitoring for Claude, which watches behaviour while proofs attest origin.

Regulatory use is the furthest out but the most consequential FlashProve application. A regulator can check that hardware serves the claimed model, or that only approved models are served, without re-running anything and without learning proprietary weights. The post is explicit about one limit: proofs show that hardware served inference, not that it did nothing else, so training on the side stays invisible to this tool.

A worked trust flow shows the shape of deployment. Suppose a customer routes production traffic through a gateway. Today, trust rests on the gateway's invoices and the provider's assurances. With provable inference, the flow becomes mechanical. The customer obtains the commitment ID for the contracted model from the provider, through a channel they already trust. Every response arrives with a proof file. A nightly job downloads the proofs, runs the verifier, and alerts on any rejection. A rejected proof is a security incident with a timestamp, a request ID and no ambiguity about guilt, because the mathematics does not have a grey zone.

The cost profile fits this shape too. Verification is a CPU job in seconds, so the customer side is nearly free. The burden sits with the provider, which is the correct allocation of incentive: the party whose claims need backing is the party that pays for the backing. FlashProve's 70 to 95 times overhead is high precisely because the provider is the one with the incentive to reduce it, and the history of cryptography in production suggests that a two orders of magnitude gap with a strong incentive behind closing it is a temporary condition.

The honest limits

FlashProve is a research artifact, and its own documentation says so plainly, which is the right way to read every number in this article. The repository is marked as not maintained and not accepting contributions.

Context is capped at 1,024 tokens per request, with greedy decoding only, so FlashProve proves short-window completions, not free-form chat sessions. Only mixture-of-experts models are supported for now, which conveniently includes Maverick but excludes dense models. Proofs cover one token per request window in the measured configuration, and the cost ratio of 70 to 95 times inference GPU time means nobody should attach proofs to a production endpoint casually.

The FlashProve verifier also trusts the commitment ID it is given, and the documentation is refreshingly blunt about the social layer: obtain the commitment ID from a party you trust, never from the server being checked. Cryptography removes the need to trust the provider's hardware. It does not remove the need to agree on which weights count as honest in the first place.

None of this diminishes the FlashProve milestone. Provable inference went from toys to a 400B-parameter frontier model in one release, with formal verification attached, and the overhead ratio is now an engineering target rather than a category failure. Teams building on model APIs should read the technical report and watch this space, because if the cost ratio falls the way zkSNARK costs fell in blockchain systems, proof-carrying responses will become a checkbox on every enterprise AI procurement list within a few years.

For readers thinking about the infrastructure side, the same pressure shows up elsewhere in the stack: AI gateways sit between users and models precisely because trust in the serving path is already weak, and the LiteLLM supply chain attack showed what happens when that path is compromised. Provable inference attacks the same problem from the mathematics side instead of the operations side.

A checklist for evaluating proof systems

Before treating any provable inference claim, FlashProve included, as settled, the questions that separate a demo from a guarantee are specific.

Ask what exactly is proven, in one sentence that a non-cryptographer can read. A commitment to weights is not a commitment to honesty about anything else: FlashProve proves that the committed model produced the tokens, nothing more. Ask for the soundness bound in numbers, and ask whether the bound itself is machine-checked in a proof assistant or asserted in a paper. Ask whether the fast verifier and the formally verified verifier agree, and how often. Ask what the prover hides, since zero knowledge over weights says nothing about side channels in timing or batch composition. And ask for the cost ratio against plain inference, because a proof that doubles serving cost is a product while a proof that multiplies it by ninety is a research prototype.

The general lesson here is one that generalizes. Trust in AI systems is becoming a supply chain problem, and supply chain problems yield to verification, not to assurances. The systems that accept audits cheaply will be the ones that get deployed where failure is expensive.

Sources
Subscription Form