A formal proof needs an ownership envelope, not a security halo
Anthropic and Theorem report machine-checked assembly-level properties across 123 open-source libraries. Adoption should preserve the property, assumptions, trusted base and reviewer.
What happened
Anthropic published research with Theorem describing Claude-generated, machine-checked no-crash proofs for compiled RISC-V entry points across 123 open-source libraries.
Why it matters
A valid proof can be misread as broad software safety when it covers a stated property, model and environment rather than every build and threat.
Preserve what was actually proved
Anthropic's research note says a collaboration with Theorem used Claude to generate formal proofs at the RISC-V assembly level for more than 100 real open-source libraries. The detailed account describes 239 entry points across 123 libraries and focuses on bounded no-crash properties. These are participant claims backed by machine-checkable artifacts, not evidence that every library is generally secure.
Formal verification can answer a stronger question than sampling: whether a precisely modelled property holds for all inputs within stated assumptions. The reported setup used inputs below 64 MB, single-threaded statically linked RISC-V/Linux programs and fixed memory assumptions; it did not cover every entry point in every library. The result also depends on processor semantics, proof assistant, supporting libraries and the connection to deployed software.
Only a subset of the proofs was public. Independent coverage described the work but did not run it. Buyers should distinguish machine-checked, inspectable and independently replicated; each answers a different governance question.
Create a proof envelope
For each accepted result, store the source revision, build recipe, compiler and flags, binary hash, architecture semantics, exact theorem, assumptions, input bounds, proof-assistant version and checker output. Name the team responsible for each layer. If no owner can explain why the verified binary matches production, the proof belongs to research evidence, not the release gate.
Run three adversarial reviews. Ask which failures the theorem excludes and which it cannot see: confidentiality, authentication, side channels, resource exhaustion and unsafe integration may sit outside a no-crash result. Rebuild from source and compare the binary. Then perturb an assumption or bound and confirm that the proof fails or requires revision rather than silently carrying forward.
AI can draft lemmas and search proof paths, but it does not remove review. A machine checker can reject an invalid proof under its logic; it cannot decide whether the selected theorem expresses the product's real safety requirement. Product, security and formal-methods owners retain separate responsibilities.
The practical decision is a narrow pilot on one critical component with a reproducible proof envelope and an independent rerun. Compare engineering time, review burden, defect class and maintenance after a code change—not only time to the first proof. This article treats the work as a promising method whose value depends on retaining scope and ownership when it enters a release decision.