Anthropic’s FlashProve Could Make AI Model Identity Verifiable

In today’s AI market, model identity is usually a matter of trust. An API customer selects a model name, sends a request and receives an answer. The provider may route traffic through different systems, replace one model with another or use a cheaper model for some requests. In most cases, the customer has no independent way to verify what happened behind the interface.

That gap may become more important as AI systems move into settings where the model itself is part of the product promise. A company might pay for access to a particular system because it expects a certain level of reasoning, safety testing or regulatory review. An insurer might want to show that an approved model assessed a claim. A cybersecurity team could need evidence that a designated system performed a scan.

TechCrunch reported that Anthropic researchers are working on a cryptographic system intended to prove which model produced a specific output. The project, called FlashProve, points toward a new layer of AI infrastructure in which model identity could be checked alongside accuracy, safety and price.

A receipt for the model behind an answer

“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.”

Anthropic said in its research paper on provable inference that FlashProve is an open-source prototype based on zero-knowledge succinct non-interactive arguments of knowledge, commonly called zkSNARKs. The system is designed to let a user verify whether a response came from a committed model.

The idea is easier to understand as a digital receipt. Before a model is used, its operator commits to a particular model. When the model later produces an answer, a proof can be generated to demonstrate that the output came from that committed system. The proof is intended to reveal enough to establish the model’s identity without exposing the model’s private parameters.

That distinction matters because simply publishing a model name does not establish what generated an answer. A provider could advertise one system while routing some requests to another. A model could be updated without every customer noticing. An attacker could also claim that an answer came from a trusted system when it did not.

FlashProve does not solve every one of those problems today. Anthropic describes it as a prototype, and its own account emphasizes substantial technical limits. The system currently supports integer greedy decoding, rather than the broader range of sampling methods commonly used in language models. It is also designed for mixture-of-experts, or MoE, models, which divide computation among specialized groups of parameters.

The project also generates proofs after inference rather than proving the computation as it happens. That means a user may still need to wait for a separate proving process after receiving an answer. In a high-volume API environment, that extra work could affect both latency and cost.

Why proof could matter beyond the API dashboard

A model’s identity is not normally visible to the person using it. People see a chat window, an API response or an automated report. They do not see which weights were loaded, which routing decisions were made or whether a provider quietly changed the underlying system.

A verification layer could make those invisible choices more observable. An enterprise could store a response together with a proof and later demonstrate that an approved model produced it. A software company could show customers that a premium feature used the model promised in its documentation. A regulator or auditor could inspect evidence without relying entirely on a provider’s internal records.

These are possible applications, not capabilities FlashProve has already delivered as a production service. Anthropic presents the project as research into provable inference, rather than as a finished commercial guarantee.

The value of such evidence would also depend on what has been committed. A proof can show that an answer came from a particular committed model, but it does not automatically establish that the model was accurate, unbiased or appropriate for the task. It would not by itself prove that a cybersecurity conclusion was correct or that a business decision was fair.

That distinction could shape how AI systems are sold. Model identity may become one of several attributes attached to an answer, alongside the prompt, time of execution, safety policy, retrieval sources and version history. In that world, an AI response would look less like an anonymous message and more like a record with provenance.

The cost of making inference provable

Anthropic’s official FlashProve repository releases the project’s code and formal artifacts. The repository documents a workflow built around committing to a model, generating a proof and verifying that proof. It also identifies the project as an unmaintained research artifact, a warning that the released code should not be treated as a supported production tool.

The computational burden is one of the largest obstacles. Lagrange described FlashProve as an important step toward verifiable AI, but said the approach can require roughly 70 to 95 times the computing cost of ordinary inference. Lagrange also characterized the current design as limited to one-token proofs, with post-hoc verification, narrow model support and no ongoing maintenance.

Those constraints change the practical picture. A single proof may be manageable for a research demonstration or a high-value transaction. Generating one for every token in a long conversation would be much more demanding. A provider serving millions of requests would need to decide who pays for the additional computation and whether customers would accept the resulting delays.

The design also creates a tension between broad usefulness and verifiability. Modern language models often use probabilistic decoding, in which several possible next tokens are considered and one is selected using a sampling process. FlashProve’s reliance on integer greedy decoding narrows the kinds of generation it can currently prove. The most flexible or natural model behavior may not be the easiest behavior to certify.

Mixture-of-experts models present another boundary. These systems activate only parts of a larger network for each input, potentially improving efficiency. But proving exactly what happened can require tracking the model’s routing and computation. A system that works for one architecture may not transfer easily to another.

Lagrange contrasted FlashProve with its own DeepProve project. That comparison is an assessment from a company working in the same area, not an independent industry consensus. The material available for this report includes no opposing response from Anthropic to Lagrange’s criticisms, and no other outside view was provided.

From model labels to model provenance

The most consequential change could be cultural rather than technical. If proofs become cheap and fast enough, customers may begin treating model identity as a property that should be verified by default.

That would alter the relationship between AI providers and their users. Today, a provider can describe a model through a name, version number and set of performance claims. Tomorrow, a customer might expect the response itself to carry evidence of origin. The model name would no longer be only a product label. It would become a claim that can be tested.

This could be especially useful when several systems produce similar-looking answers. A cheaper model may be adequate for routine formatting, while a more capable model may be reserved for complex analysis. If the customer is charged differently for those services, proof could help confirm that the promised tier was used.

It could also support accountability when models are updated. A provider might commit to a particular version for a regulated workflow, then issue a new version for general customers. Cryptographic commitments could help distinguish those versions, provided the commitment process itself is transparent and the relevant parties agree on what must be proven.

Yet verification could introduce its own questions. Customers would need to know who created the commitment, how it was stored and whether the committed model was itself evaluated. They would need to understand what a proof covers and what it leaves out. A cryptographic guarantee can be precise while still being misunderstood.

FlashProve therefore marks an early step toward a possible provenance system for AI. It does not make every answer trustworthy, and its current costs and restrictions stand in the way of routine deployment. But it frames a problem that will become harder to ignore as companies rely on model-specific promises.

In a future workplace, a manager might not ask only whether an AI system gave a useful answer. The manager might also ask which system gave it, whether that system was authorized and whether the record can prove both. FlashProve suggests one way to build that evidence. The larger question is whether the AI industry will decide that model identity deserves the same attention as performance, safety and cost.