When a model answers you, there is no way to check that the answer really came from that model. Anthropic’s Frontier Red Team published a research post on Monday and shipped a tool with it: FlashProve.
The problem has three faces
A routing service can quietly swap in a cheaper model. An independent evaluator cannot tell whether the model it tests is the model that later gets served. And an attacker who tampers with the token stream leaves no trace in the output. Quality is no help here. A good answer says nothing about where it came from.
Checking it yourself is not an option either. Frontier weights are not public, and anyone who had them would also need the provider’s hardware to run them.
What FlashProve does
The provider commits to a model and ships a short cryptographic proof with every response. Technically it is a zkSNARK: a proof that stays small and reveals nothing about the weights. Verifying it takes seconds on an ordinary CPU. If the response deviates from the committed model, the check fails.
The numbers from the post:
| Measure | Value |
|---|---|
| Test model | Llama 4 Maverick, 400B parameters, 4-bit |
| Proving speed | about 110 tokens per second on one H100 |
| Proof size | roughly 19 MB per 1,024 tokens |
| Overhead vs. vLLM | 70 to 95 times the GPU time |
What stays hidden are the weights, not the architecture. Anthropic says that is by design, not an oversight.
Claude did the optimising, Lean checks the result
The most interesting part is how the post treats its own tool. Claude found the optimisations, and the authors say plainly that such decisions are hard to judge inside a large system. So the security claims also exist as machine-checked proofs in Lean, with a visualiser for anyone who wants to audit them.
Five artifacts went out: the post, a technical report, a protocol specification written by Claude, executable code with a prover and two verifiers, and the Lean proofs. All under Apache 2.0.
The proof still costs more than the answer
Seventy times the compute means this is useless for everyday traffic. For the cases Anthropic names, it may already be enough. An evaluator who checks once a quarter can afford it. So can a company that wants to know which model handled a handful of critical requests.
What I like about it: Anthropic does not pretend this is finished. The post says outright that it is intermediate progress and invites other people to take it further. For a problem that regulators will eventually care about, that is the right order of events.