Somewhere between a security engineer's intention and a shipped binary, guarantees have a way of quietly evaporating. The design looked sound. The implementation compiled. The compiler optimized. And somewhere in that chain, an assumption slipped.
A short chapter posted to arXiv on 30 July 2026 takes up that problem. Gilles Barthe, its sole author, wrote it as chapter 19 of a forthcoming book, Proof Assistants and Their Applications in Mathematics and Computer Science. The chapter's subject is narrow and specific: what happens when you point a proof assistant at security.
A proof assistant is a piece of software that checks mathematical arguments step by step, refusing to accept a claim until every gap is filled. It is not an automatic theorem prover that goes off and finds proofs on its own. It is closer to an extremely literal-minded referee. You write the argument; the machine verifies that each inference genuinely follows, and complains when it does not. The appeal for security work is obvious once stated. Security properties are claims about what an attacker cannot do, and "cannot" is a strong word that human reviewers are historically bad at auditing.
What the chapter covers
Barthe identifies two motivations for bringing proof assistants to bear. The first is the one you would expect: validating that designs and implementations meet their expected security properties. The second is less discussed and arguably more consequential in practice. Proof assistants support certification, the formal process by which a system is assessed and approved against a security standard before it is deployed in a setting where failure is expensive.
That second motivation matters because certification is where security claims meet institutions. A machine-checked proof is a different kind of artifact from a report written by a reviewing team. It can be rechecked by anyone with the same tool, and it does not get tired at four in the afternoon.
From there the chapter surveys four application areas. System security covers the guarantees an operating system or hypervisor is supposed to enforce, the walls between one process and another. Language-based security concerns properties that can be established from the structure of a program itself, in the language it is written in, before it ever runs. Secure compilation asks a question that sounds pedantic and is not: when a compiler translates your carefully secured source program into machine code, does it preserve the security properties, or does an optimization pass silently destroy them? And cryptography covers the proofs that underpin encryption schemes and protocols, arguments that are notoriously delicate and that even expert human reviewers have gotten wrong.
Those four areas are what the abstract commits to, and it is worth being precise about the limits of what can be said here. The full text of the chapter was not available in the material reviewed for this article. What is available is the abstract, the metadata, and the framing. So this piece describes the shape of the work and its stated scope rather than its detailed conclusions, its examples, or whatever verdicts Barthe reaches about which techniques have worked and which have not.
It is also worth noting what kind of document this is. It is a survey chapter for a book, not a paper announcing a new result. There is no experiment, no dataset, no benchmark. The contribution is organizational: a researcher who has worked in this area gathering an account of where formal methods have been applied to security, aimed at readers of a book about proof assistants generally. The arXiv listing files it under cryptography and security, with cross-listings to logic in computer science and to programming languages, which is a reasonable map of the territory the abstract describes.
Why it matters
Most of the security failures that make the news are not failures of cryptographic mathematics. They are failures of the gap between an idea and its realization: a buffer that was one byte too small, a check that ran after the operation instead of before, a compiler that helpfully removed a memory-clearing routine because it could see the memory was never read again. The last of those is a real category of problem, and it is exactly the kind of thing the secure compilation work Barthe mentions exists to address.
What proof assistants offer against that class of failure is not cleverness but stubbornness. They will not let an argument through with a hole in it. The cost is substantial: writing machine-checked proofs of real systems is slow, demanding work, and the resulting proofs are only as good as the assumptions and threat models they start from. A verified system can still be broken by an attack outside the model it was verified against.
Still, the direction of travel in high-assurance software has been toward more formal verification, not less, and the certification angle Barthe raises suggests why. When a regulator or a customer asks how you know your system is secure, a proof that a machine will recheck on demand is a fundamentally more portable answer than trust in the people who built it. A survey like this one is a marker of a field that has accumulated enough results to be worth summarizing for outsiders.