A new post from Trail of Bits — "Auditing in the age of (good enough) AI" — signals a meaningful shift in how rigorous security assessments are conducted, and defenders on both sides of the engagement (commissioning organizations and internal security teams) should pay attention. The industry conversation around AI in security has been dominated by one narrow use case: pointing an agent harness at a codebase and counting the bugs it surfaces. Trail of Bits' disclosure is more substantive. In a six-month preparation phase ahead of reviewing the Miden VM — a new zero-knowledge virtual machine with its own custom assembly language and essentially zero developer tooling — the firm had its agents build an LSP server, a decompiler, a static analysis engine, and a formal model of the VM executor in Lean. These agent-built tools found real security issues.
Why should a CISO or security engineering lead care about a vendor methodology blog? Three reasons. First, the economics of deep security review are changing: components that were previously unauditable within budget — novel languages, bespoke VMs, exotic cryptographic constructions — are now reachable. Second, the same capability asymmetry applies to adversaries; if defenders can stand up custom analysis tooling for obscure systems, so can well-resourced attackers. Third, organizations procuring audits or running internal review programs now have a concrete benchmark for what "good" looks like in 2026 — and a checklist of questions to ask anyone claiming to have audited their code.
Technical Analysis
What Trail of Bits Actually Did
The engagement centered on the Miden VM, a zero-knowledge virtual machine developed by Polygon Miden. ZK VMs occupy a uniquely difficult position in the security landscape:
- Custom instruction set and assembly language. Standard static analysis tooling (CodeQL, Semgrep, commercial SAST) has no coverage. Every analyzer must be built from scratch or the code is effectively opaque to automated review.
- Cryptographic correctness requirements. In a ZK VM, the executor must exactly match its mathematical specification. A divergence between the implementation and the proving system is not a conventional bug class — it is a soundness failure that can invalidate every proof the system generates.
- No existing developer tooling. No language server, no decompiler, no debugger ecosystem. Human auditors face a steep ramp-up cost before they can even navigate the codebase efficiently.
Rather than accept those constraints, Trail of Bits used AI agents over a six-month runway to construct the missing tooling stack:
- LSP (Language Server Protocol) server — giving auditors IDE-grade navigation, go-to-definition, and cross-referencing for Miden assembly. This compresses the manual "read and map the codebase" phase that traditionally consumes the first weeks of an engagement.
- Decompiler — enabling analysis at a higher abstraction level than raw assembly, which is where semantic bugs (as opposed to instruction-level bugs) become visible.
- Static analysis engine — custom-built for the target's semantics, since no off-the-shelf engine understands Miden's execution model.
- Lean formal model of the VM executor — the most significant artifact. A machine-checked model in the Lean proof assistant allows the team to reason about executor correctness against its specification rather than relying solely on adversarial test cases. In ZK systems, where a single constraint bug can be catastrophically exploited to forge proofs, formal modeling addresses the bug class that fuzzing and manual review are worst at finding.
The headline claim: these tools found real security issues before traditional code review even started. That inverts the usual audit pipeline — tooling was historically a byproduct of an engagement, not a precursor that shapes it.
The "Good Enough" Insight
The parenthetical in the title is the most important phrase for practitioners. The agent-built tools did not need to be production-quality software. A decompiler that handles 80% of the instruction set, an LSP server that occasionally crashes, a static analyzer with false positives — all of these are "good enough" if they shift the auditor's effective capability. This is the part organizations consistently underestimate: the value of bespoke, disposable tooling has collapsed in cost from "person-months of a specialist engineer" to "days of agent supervision."
The Adversarial Mirror
Defenders must also internalize the flip side. Nation-state operators and sophisticated criminal groups have the same access to frontier models and agent harnesses. An obscure internal DSL, a proprietary protocol parser, a custom smart-contract VM — none of these are protected by obscurity anymore. The historical defense of "no attacker will invest six months building tooling for our bespoke system" is eroding in real time. Any system whose security posture implicitly depends on the cost of building custom analysis tooling should be re-evaluated under the assumption that cost has dropped by an order of magnitude.
Executive Takeaways
This is a methodology disclosure, not a vulnerability advisory — there is no patch to deploy and no IOC to hunt. The defensive value is in how your organization adapts its assurance strategy. Our recommendations:
1. Re-baseline what "audited" means for your critical components. If your organization relies on novel cryptographic systems, custom VMs, interpreters, or DSLs, ask your audit providers (internal or external) specifically how they handled the tooling gap. An audit of a bespoke system conducted with generic tools and manual reading alone is now materially inferior to one backed by custom analyzers and formal models — and you should price that difference into procurement decisions.
2. Treat pre-engagement tooling as a deliverable, not overhead. Trail of Bits' six-month runway produced durable artifacts (decompiler, static analyzer, Lean model) that outlive the engagement. If you commission reviews of custom systems, negotiate for these artifacts to be delivered and maintained. A Lean model of your executor or a working decompiler for your bytecode is a permanent upgrade to your internal security team's capability.
3. Reassure your threat model on obscurity. Conduct a focused review of systems whose security currently benefits from being hard to analyze: proprietary firmware formats, internal RPC protocols, custom cryptographic implementations. Assume a motivated attacker can now build a purpose-built fuzzer, decompiler, or protocol model in days. Prioritize these systems for proactive review before someone else builds that tooling first.
4. Build an agent-assisted tooling capability in-house — with guardrails. Security engineering teams should pilot agent-driven development of internal analysis tooling: linters for internal frameworks, Semgrep/CodeQL rule packs for proprietary APIs, harness generators for fuzzing. Pair every agent-generated tool with human validation, because a subtly wrong static analyzer or an incorrect formal model creates false assurance — which is worse than no assurance. The Lean model in this engagement is instructive precisely because machine-checked proofs have an external correctness criterion; tools without one need adversarial review of their own.
5. For ZK and cryptographic systems specifically: demand specification-level verification. If you operate or depend on zero-knowledge infrastructure (rollups, privacy layers, ZK identity systems), ask whether the implementation has been checked against an executable or machine-verified specification. Differential fuzzing against a reference implementation and formal models of the constraint system are the two techniques that reliably catch soundness bugs — the class that drains funds and forges proofs. Trail of Bits' approach of modeling the executor in Lean is the emerging bar.
6. Update vendor and team evaluation criteria. When assessing MSSPs, audit firms, or red teams in 2026, "how do you use AI" is too vague to be a useful question. The differentiating questions are: Do you build custom tooling per-engagement? Do you produce formal or executable models for correctness-critical components? Do your agent-built artifacts get validated, and how? The gap between firms doing this and firms running a generic agent harness over your repo will show up directly in findings quality.
The Bottom Line
The Trail of Bits Miden VM engagement is an early, concrete demonstration that the highest-value application of AI in security review is not replacing the auditor — it is industrializing the preparation phase that used to make deep review of exotic systems economically impossible. Defenders should respond on two fronts: raise the bar for what assurance looks like on their own custom and cryptographic components, and stop assuming that obscurity or bespoke design buys meaningful time against adversaries who now have the same leverage. The organizations that internalize this shift earliest will be the ones whose "unauditable" systems get audited — by their own side, on their own terms.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.