A company may pay for a particular model because it has been evaluated for security, licensed for a sensitive workflow or approved by a regulator. An auditor may need to know that the system tested in a lab is the system used in production. A government may want evidence that scarce computing capacity is being used for inference rather than secretly redirected to train a more capable model.
Today, all of them mostly rely on the provider’s word.
That is the trust gap Anthropic is trying to narrow. On November 2, 2026, Anthropic introduced FlashProve, an open-source research prototype for “provable inference.” In plain language, it is a way for a provider to attach cryptographic evidence to a model response, allowing someone else to check that specified model weights produced specified output tokens from a specified prompt.
The claim is deliberately narrower than it sounds. FlashProve can help answer, “Did these committed weights generate this token?” It cannot, on its own, answer “Was the model safe?”, “Was customer data protected?”, “Was this server compromised?” or “Was the provider training another model at the same time?” Keeping those questions separate will be the difference between a useful new layer of assurance and a misleading new marketing label.
“We will develop a prototype by September 30, 2026 of provable inference, a technique for reliably, provably 'signing' AI model outputs in a way that makes them attributable to a specific set of model weights.”
The problem is not whether the answer sounds smart
Imagine a procurement officer buying access to a high-end model through an API broker. The broker has incentives to manage cost. If a cheaper model produces an acceptable answer, the buyer may never notice a substitution. The same ambiguity haunts model evaluations. An external testing group can assess one system before release, but how can it be confident that the company keeps serving that same system after the test?
Output quality is a poor identity check. A substitute model can be eloquent. A tampered server can preserve most of an answer while inserting one harmful instruction. And a model provider normally cannot publish its full weights simply to prove a point: the weights may be proprietary, enormous, and expensive for the customer to run independently.
FlashProve proposes a digital equivalent of a sealed supply chain. Rather than reveal the contents of the shipment, the provider publishes a cryptographic commitment to the model. The commitment is a compact fingerprint. Later, when the provider returns text, it supplies a proof tied to that fingerprint and the request.
The customer does not receive the weights or the entire calculation. It receives enough cryptographic evidence to verify the claim quickly. That is the “zero-knowledge” part: the system is intended to show that the calculation was done correctly without disclosing the secret model parameters or intermediate computation.
The relevant analogy is less like reading a restaurant review and more like checking a tamper-evident seal. The seal does not tell you whether the food was nutritious. It answers a narrower question: did the package arrive with its claimed contents intact?
What FlashProve actually proves
Anthropic’s technical report describes FlashProve as a two-stage commit-and-prove protocol, built around a cryptographic proof system called a zkSNARK.
First comes an offline stage. The provider takes a defined set of weights, converts them into the representation FlashProve expects, and publishes a hiding commitment. The report describes that commitment as a short digest that a comparatively modest client can keep. In Anthropic’s evaluation, the initial commitment and related offline material totalled about 6.5 MB.
Then comes the online stage. For a user’s request, the provider must establish that the committed model, given the relevant token sequence, selected the claimed next token. The verifier checks the proof using the prompt, claimed response, commitment and proof. The verifier does not need a GPU, the full model, or access to the weights.
That setup produces three central guarantees, under the protocol’s stated cryptographic assumptions:
Completeness: a correct computation should produce a proof the verifier accepts.
Soundness: a dishonest provider should be unable to make a verifier accept a false claim, except with negligible probability.
Zero knowledge: the proof should not reveal model weights or the hidden calculation trace beyond what follows from the accepted claim.
This is a real change in the relationship between provider and customer. A buyer no longer has to infer model identity from a brand name, benchmark result or contractual promise. They can verify a precise computational statement.
But “precise” matters. The statement is not simply that a familiar commercial model answered. It is that an exact, committed, integerized version of a model produced the selected token under the specified procedure.
Why the model has to become more mechanical
Modern language model serving is not naturally suited to cryptographic proof. Production models commonly use floating-point arithmetic, where tiny differences in calculation order or hardware can alter a score at the margin. They may also use sampling, intentionally choosing among plausible next words to create varied answers.
Proof systems prefer deterministic arithmetic.
FlashProve therefore works with an integer-quantized form of the model. Quantization converts weights and activations into smaller integers. This can reduce memory use and make the calculation compatible with the finite mathematical fields used in the proof system. Anthropic’s prototype also focuses on greedy decoding: at each checked position, the model must choose the token with the highest score.
Close behavior is tested, but not mathematical identity for every prompt
That engineering choice solves one problem while creating another. A proof can be exact about the integer model. It does not mean every token from a conventional floating-point production run will match exactly. Anthropic says the integer version is generally expected and empirically tested to have a small error rate relative to floating-point inference, but notes that this expectation does not cover adversarially designed prompts.
This is not a footnote. It is the central operational issue for any customer assessing an “attested inference” offer. Ask: attested relative to what, exactly? A named model family is not enough. The provider should identify the quantization method, decoding rule, context window, versioned weight commitment and what happens when the served output and proved output differ.
For applications that demand reproducibility, deterministic decoding may be a fair trade. For creative writing, conversation, or applications that depend on sampling, it may be much less natural.
The speed figure is impressive, and still expensive
Anthropic’s headline result is substantial progress compared with earlier published open systems. It reported proving performance of about 110 tokens per second for Llama 4 Maverick, a 400B-parameter mixture-of-experts model, using one H100 GPU, 4-bit weights and batches of 24 requests. The reported proof size was about 18.78 MB per request, and CPU verification took 17 seconds using 24 threads.
Those numbers need to be read as a systems result, not as a promise of normal API latency. The system generates proofs after the model response has already been served. It recomputes the finished transcript in a parallel pass. That makes it easier to use GPUs efficiently, but means a user may receive an answer before receiving evidence that the answer was authentic.
The comparison shows why the research matters. Proof generation at 110 tokens per second for a model of this scale is a large improvement over earlier open demonstrations cited by Anthropic. Yet the more commercially revealing figure is the overhead: Anthropic estimates that proving consumed about 70 to 95 times the GPU time of ordinary inference through vLLM in its tests.
In other words, progress has made the task conceivable. It has not made it cheap.
The prototype also relies on a favorable model structure. Llama 4 Maverick is a mixture-of-experts model. Although it contains 400 billion parameters, Anthropic says roughly 17 billion are active for a given token. FlashProve can make its proving work proportional to the experts actually used rather than every parameter in the full model. It also hides which experts were selected.
Batching is another source of efficiency. Instead of opening its commitment afresh for every customer request, the prover handles a batch together. This lowers cost, but it changes the security conversation. Batching improves hardware use precisely because multiple users’ work is processed together.
That caveat is not theoretical. Google DeepMind researchers described a class of architectural backdoors that can exploit batched inference to leak or manipulate other users’ requests. Their work is independent context, not a direct criticism of FlashProve. Still, it illustrates the boundary of the guarantee: a proof that one output came from committed weights is not automatically a proof that requests inside a batch were isolated from one another.
The DeepMind authors propose formal information-flow controls to establish non-interference between batch entries. That is a different proof obligation. It is also a useful reminder that an AI service needs more than one kind of assurance.
Identity is not safety, and detection is not prevention
FlashProve is strongest when the disputed fact is model identity. That could matter in regulated APIs, where a customer needs evidence that an approved model rather than a lower-cost substitute handled a decision. It could matter in licensing, where a rights holder wants to confirm use of the agreed model. It could matter for frontier-model monitoring, where evaluators want assurance that a deployment matches the system they tested.
It may become particularly valuable in high-assurance agents. If an agent is permitted to initiate a payment, query an internal database or operate industrial software, an organization may want a verifiable record of the model computation behind each action. That record could support audit, incident response and contractual accountability.
Still, an attestation is not a behavioral guarantee. It cannot establish that the committed model was harmless, unbiased or aligned with a company’s policy. A faithfully executed unsafe model remains unsafe.
Nor does the proof establish that the surrounding infrastructure behaved properly. Anthropic explicitly says inference proofs do not demonstrate that the provider was not training on the side. Its post-hoc design also cannot prevent a compromised server from sending a malicious response before later failing to generate a valid proof. If an attacker can alter logs, they may even record a correct output internally while sending something different to the customer.
The release has another important assurance boundary. Anthropic has formally specified protocol properties in Lean, a proof assistant, but it does not claim formal equivalence between the fast executable implementation, the report and the Lean specification. The technical report says an error in the prover code should not let it forge a false proof, because the verifier does not have to trust the prover. But bugs could still affect whether correct proofs are generated or whether implementation details leak information.
That is a serious and candid limitation. It also makes this an unusually useful research prototype: it distinguishes the mathematical protocol from the code that people will actually run.
How to judge the next attested-inference claim
Customers and regulators should resist a simple checkbox marked “cryptographically verified.” Instead, they should ask six questions.
What exact model is committed? Seek a versioned commitment, an architecture description and a definition of the quantized weights.
What exact output is proved? Is every token covered, a random subset, or only one token after a prompt window?
Which decoding method is included? Greedy decoding, fixed-seed sampling and ordinary sampled production output carry very different implications.
When does the proof arrive? Inline proof can block an unverified response. Post-hoc proof detects problems later, which may be sufficient for audit but not for immediate prevention.
What does the cost model look like? Proof size, verification time, GPU overhead, batching requirements and context limits determine whether the assurance can extend beyond a premium workflow.
What remains outside the proof? The answer should explicitly cover training activity, tool use, customer-data handling, batch isolation, server compromise, logging and policy compliance.
Only one external perspective was provided for this story, and it is independent security research rather than a published rebuttal to FlashProve. No direct outside objection to Anthropic’s work was supplied. That absence should not be mistaken for a completed debate. The important questions are practical: whether the prototype’s assumptions hold in production, whether the costs keep falling, and whether buyers learn to distinguish proof of identity from proof of safety.
FlashProve’s deeper significance is that it begins to turn AI model identity from a promise into a checkable property. That will not settle the broader question of whether we should trust an AI system. But as models become more consequential, knowing which one actually answered is a necessary place to start.
Daniel Reyes is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna and qwen3-max. Out on the live web: gpt-5.6-luna and gpt-5.6-terra. Pictures: gpt-image-1 and gpt-image-1-mini. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Daniel Reyes's usual length and in Daniel Reyes's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
This article was generated using AI and published automatically without human pre-publication review.
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.