AI vs. ZK: How an LLM Found Real Bugs in OpenVM’s Verifier

The Bug Hunt: What Actually Happened

A security researcher fed the source code of OpenVM’s zero-knowledge virtual machine (zkVM) verifier to a large language model. The result wasn’t a vague, hallucinated warning. The LLM identified two distinct, real bugs in the cryptographic constraint system—the mathematical rules that ensure a zero-knowledge proof is valid without revealing the underlying data.

These weren’t low-hanging syntax errors. The first bug involved an under-constrained modular arithmetic operation, which could allow a malicious prover to forge a valid proof for a false statement. The second was a missing range check on a field element that, under specific conditions, leaked information about the witness—breaking the core “zero-knowledge” property.

The researcher documented the full process in a detailed write-up, showing the exact prompts, model responses, and the vulnerable code sections. The OpenVM team confirmed both findings and issued fixes.

What makes this remarkable is the domain. Zero-knowledge cryptography sits at the intersection of advanced mathematics, low-level systems programming, and formal verification. It’s a field where bugs are notoriously subtle and expensive to find. An LLM spotting them without specialized fine-tuning signals a genuine shift in what’s possible for automated security review.

The Setup

The researcher used a straightforward approach: feed the entire verifier implementation to the model in chunks, ask targeted questions about constraint completeness, and follow up on any flagged sections. No custom embeddings, no retrieval-augmented generation pipeline—just raw prompting with careful context management.

The model flagged the under-constrained operation because it recognized a pattern: a modular multiplication result was used directly in a constraint without verifying that the intermediate value stayed within the expected range. This is the kind of bug that a human auditor might spot by asking “what prevents this value from wrapping around?”—and the LLM effectively asked the same question.

The Technical Deep-Dive: A Constraint System Gone Wrong

To understand why these bugs are so dangerous, you need to grasp what a zkVM verifier does. In a zero-knowledge proof system, the prover executes a computation and generates a proof that the execution was correct. The verifier checks that proof against a set of constraints—mathematical equations that must hold if the computation was honest.

If a constraint is missing or incomplete, a malicious prover can construct a proof that passes verification but corresponds to an invalid computation. This is the cryptographic equivalent of a SQL injection: the attacker slips through because the validation logic has a gap.

Bug 1: Under-Constrained Modular Arithmetic

The verifier used a constraint that checked a * b = c mod p, where p is a large prime. But the constraint only enforced the equality modulo p—it didn’t check that a, b, and c were properly reduced (i.e., in the range [0, p-1]).

A malicious prover could set a = p + 1, b = 1, and c = 1, and the constraint would still pass because (p+1) * 1 ≡ 1 mod p. The verifier would accept a proof built on values that violated the intended field arithmetic, potentially enabling a complete proof forgery.

The fix: add explicit range-check constraints that force each variable to be less than p. Simple in hindsight, but easy to miss when you’re deep in a complex constraint system.

Bug 2: Missing Range Check on a Witness Element

The second bug was subtler. A witness element—a private value known only to the prover—was used in a constraint that mixed public and private inputs. The result of this computation was exposed in the proof transcript without sufficient masking.

An observer analyzing multiple proofs could, under certain conditions, extract information about the witness by solving a system of equations derived from the leaked outputs. This breaks zero-knowledge: the verifier (or anyone watching) learns something about the secret input.

The fix: add a blinding factor—a random value that masks the witness element before it enters the public-facing computation—and constrain the blinding factor’s range to prevent wrap-around attacks.

Why This Matters for Engineers and FDEs

If you’re a forward-deployed engineer (FDE) or a technical practitioner working with security-conscious customers, this event changes the conversation in three concrete ways.

1. AI-Assisted Code Review Is Now a First-Class Tool

This isn’t about replacing human auditors—it’s about multiplying their effectiveness. An LLM can scan an entire codebase for constraint-completeness patterns in seconds, flagging suspicious sections for human review. The human then spends their limited attention on the high-signal candidates rather than exhaustively reading every line.

For FDEs working on customer deployments, this means you can run an AI pass over integration code before it ships, catching issues that might otherwise surface in a security incident six months later. The AI doesn’t need to be perfect; it just needs to surface enough true positives to justify the review time.

2. Cryptographic Code Is No Longer a Black Box

Zero-knowledge proofs, multi-party computation, and other advanced cryptographic protocols have historically been auditable only by a tiny pool of specialists. That pool is expensive and bottlenecked. An LLM that can reason about constraint systems—even imperfectly—democratizes access to initial security review.

This is particularly relevant if you’re building or deploying systems that use ZK proofs, like private transaction layers, verifiable computation platforms, or identity protocols. You can now run a first-pass audit in-house before engaging specialist auditors, catching the obvious issues early.

3. The FDE Value Proposition Just Expanded

Forward-deployed engineers sit between product and customer, often owning the technical validation that closes enterprise deals. Being able to say “we run AI-assisted security review on every release, and here’s how it works” is a powerful trust-building tool. It demonstrates technical sophistication without overpromising—especially when paired with a clear explanation of the AI’s limitations.

If you’re preparing for an FDE role, understanding this capability and being able to articulate it to both technical and non-technical stakeholders is increasingly table stakes. For more on that, see our deep-dive on how FDEs build trust with non-technical stakeholders in enterprise deals.

How to Replicate This: Your AI Audit Playbook

You don’t need a custom model or a PhD in cryptography to start using AI for security review. Here’s a practical, engineer-to-engineer playbook based on the approach that found the OpenVM bugs.

Step 1: Scope the Target

Pick a well-defined, self-contained module. The OpenVM researcher chose the verifier because it was ~2,000 lines of Rust implementing a specific mathematical specification. Avoid sprawling codebases where context windows become unmanageable.

Step 2: Chunk and Contextualize

Feed the code to the model in logical chunks—functions, structs, trait implementations—with enough surrounding context to understand the call graph. For each chunk, include a brief comment explaining what it’s supposed to do. This reduces the model’s chance of misinterpreting intent.

Step 3: Use Targeted Prompts, Not Open-Ended Ones

The researcher didn’t ask “find bugs.” They asked specific, constraint-focused questions:

• “Does this constraint fully enforce that the output is in the field?”
• “Is there any path where this value could be outside the expected range?”
• “What assumptions does this function make about its inputs, and are they checked?”

These prompts guide the model toward the class of bugs you care about, rather than generating a flood of false positives.

Step 4: Build a Verification Loop

For every flag the model raises, ask it to generate a proof-of-concept exploit or a counterexample. This serves two purposes: it filters out hallucinations (if the model can’t construct a valid attack, the flag is likely noise), and it gives you a concrete test case to validate the finding.

Step 5: Integrate Into CI (Carefully)

Once you’ve validated the approach on a few modules, you can embed it into your CI pipeline as a non-blocking check. Run the AI audit on every PR, post the results as a comment, and let human reviewers decide what to act on. This keeps the feedback loop tight without introducing a gating step that might block legitimate changes.

If you’re interested in building similar AI-assisted tooling for codebases, our guide on building a codebase Q&A tool with LlamaIndex and Cloudflare Workers walks through the retrieval architecture you’d need for larger repositories.

Step 6: Know When to Escalate

AI-assisted review is a triage tool, not a replacement for formal verification or specialist audit. If the model flags something in cryptographic code, and you can’t immediately dismiss it, escalate to a human with domain expertise. The cost of a false negative in ZK code is catastrophic; the cost of a false positive is a few hours of an expert’s time.

The Balanced Take: Limitations and Risks

Let’s be clear about what this is and isn’t. The OpenVM findings are impressive, but they don’t mean LLMs are ready to replace human security auditors. Here’s what to watch out for.

Hallucination Is Real, and Dangerous

An LLM can confidently describe a bug that doesn’t exist, complete with a plausible-sounding exploit scenario. If you act on a hallucinated finding—say, by adding an unnecessary constraint—you might introduce new bugs or degrade performance. Always verify before patching.

Pattern Matching ≠ Understanding

The model found these bugs because it recognized patterns in the code that correlate with vulnerabilities in its training data. It doesn’t understand the mathematical guarantees of the proof system. For novel attack vectors that don’t resemble known patterns, the model is likely to miss them entirely.

Context Window Limits Mean Coverage Gaps

Even with 200K-token context windows, you can’t feed an entire large codebase to a model and expect it to reason about cross-module interactions. The OpenVM verifier was small enough to fit; most real-world systems aren’t. You’ll need to chunk strategically, and that means you might miss bugs that span chunk boundaries.

The Overconfidence Trap

This finding could easily lead teams to over-rely on AI audits, skipping human review for “low-risk” changes. That’s a mistake. As we covered in our analysis of how AI advice made engineers 3x less accurate but 2x more confident, the confidence boost from AI assistance can mask real gaps in understanding. Treat AI findings as input to human judgment, not as a substitute for it.

What This Means for the Industry

Expect to see AI-assisted review become standard practice in security-critical codebases over the next 12-18 months. The tools will improve, the prompting patterns will mature, and the integration patterns will solidify. But the fundamental dynamic—AI as amplifier, human as decision-maker—will remain.

For FDEs, the implication is clear: learn to use these tools now, understand their limitations deeply, and be able to explain both to customers. The engineers who can wield AI effectively in security contexts will be the ones closing the hardest deals.

FAQ: AI-Assisted Security Review

Q: Can I use any LLM for this, or do I need a specialized model?

General-purpose models like GPT-4, Claude, and Gemini have all shown the ability to reason about code constraints. No specialized fine-tuning is required for initial triage. However, for production use, you may want to experiment with prompt engineering specific to your codebase’s patterns.

Q: How do I know if a flagged issue is real or a hallucination?

Ask the model to generate a concrete test case or exploit that demonstrates the issue. If it can produce a specific input that triggers the bug, the finding is more likely to be real. If it waffles or produces circular reasoning, treat it as low-confidence. Always reproduce independently before filing a bug report.

Q: Will this work on non-cryptographic code?

Yes, but the value proposition differs. For business logic bugs, AI review can catch missing validation, off-by-one errors, and race conditions. The key is to adapt your prompts to the bug class you’re hunting. Constraint-completeness checks are particularly effective for cryptographic code because the specification is mathematical and precise.

Q: How does this fit into a formal verification workflow?

AI-assisted review is a pre-filter. Run it before formal verification to catch low-hanging issues, so the formal tools (which are computationally expensive) can focus on deeper properties. Think of it as linting for security—fast, broad, and imperfect.

Q: What’s the FDE angle here?

If you’re in a customer-facing technical role, being able to run an AI audit on integration code before a deployment—and explain the results to both engineers and executives—is a superpower. It builds trust, reduces risk, and demonstrates the kind of technical depth that distinguishes top-tier FDEs. For a broader view on what FDE roles demand in 2025, check our guide on the FDE interview loop and how to prepare.

Q: Where can I learn more about building AI-assisted tools?

Start by building something small—a code review bot for your team’s repo, or a security scanner for a specific module. Our tutorials on building a Discord FAQ bot with Pinecone and Gemini and creating a multi-agent research assistant with Groq and Serper cover the fundamental patterns you’ll need to scale up to code analysis.