I hit the same question again: “Fixed it—but did we truly fix everything?”
At 10 p.m. last Tuesday, I was delivering an automated quoting system for a client in Hangzhou. The new version was live, and I had reviewed the old vulnerability three times, but I still wasn’t sure. What worried me wasn’t an obvious error; it was a piece of permission logic nobody was watching anymore. I used to keep burning the night away, sometimes buying more expensive testing services. This time, I looked at Google DeepMind’s AI math verification experiment and realized it could help a team check code with “proofs” rather than relying only on trial and error.
It doesn’t write code for you; it hunts counterexamples
The process starts with people writing the rules a program must follow. AI then generates large numbers of mathematical proofs, showing that the code satisfies each rule or finding a case that violates it. Signal’s research team even restored two previously fixed vulnerabilities to see whether the system could rediscover them. In four weeks, they generated roughly 6.5 million lines of proof.
One scenario stuck with me: in March 2025, a small New York medical software team wrote “only the doctor on call can view the full patient record” as an explicit rule, then used the system to check whether different roles could gain unauthorized access. Team lead Maya Chen said the system caught two paths that their test cases had missed that day. The name is fictional, but the setting is ordinary: not a major bank, but a ten-person team handling sensitive data every day.
Reproducing it today: modest budget, one business-savvy person
Money: Google’s public research doesn’t list a directly purchasable package. Based on my small trial, I’d reserve at least RMB 5,000 for formal verification, mainly for the test environment and security review, rather than model calls. Time: Connecting it to an existing codebase takes about 2–6 weeks, while a small rules-and-proof trial takes roughly 3–7 days. Technical barrier: Someone needs to articulate the business rules, and someone else needs to understand the code. A non-coder can help write rules, but it would be difficult to complete verification alone.
The first step isn’t clicking “Generate.” It’s opening the test page in your development tool, creating a minimal project, writing the three permission rules that must never be broken, and having an engineer help verify one module that handles only fake data. My earlier mistake was letting AI scan the entire system first; the noise was overwhelming. Once we narrowed it to one module, the business people could finally understand the report. Not every team needs this approach, and there’s no urgency if it doesn’t fit right now.
At different stages, here’s how I’d choose
If you’re just starting: I wouldn’t introduce this process yet. Turn the most critical permission rule into a test case and have someone familiar with the business review it manually. If the budget is tight, an external security check costing RMB 20–50 is more practical for now.
If you already have 1–2 clients: I’d pick one active project, run a 3–7-day verification trial with fake data, and attach the findings to the client update. I’d reserve RMB 5,000 initially rather than rush to expand.
If you’re scaling: I’d have an engineer create a “business rules library,” run verification automatically on every release, and retain a human sign-off step. At that point, stability and total cost matter more than how many proofs were generated.
AI math verification is worth watching, but it isn’t a security certificate. I’d start with one low-risk module and see whether it finds problems that neither my clients nor I had considered. If it doesn’t, I’d stop there rather than let the tool slow delivery down.