OpenAnt: closed-loop LLM vulnerability discovery cuts false positives and cost

What is this?

OpenAnt is an open-source vulnerability-discovery system from Knostic (Nahum Korda and Gadi Evron) that combines static program analysis with large-language-model reasoning, then validates each finding through an automated adversarial step and a sandboxed exploit run. The accompanying paper, “OpenAnt: LLM-Powered Vulnerability Discovery Through Code Decomposition, Adversarial Verification, and Dynamic Testing” (arXiv:2606.19149), was first pre-released on March 11, 2026 and made public on June 17, 2026. The tool ships under the Apache 2.0 license.

The point is not a new attack. It is a measured demonstration that the cost of finding real, exploitable bugs across a whole repository is dropping fast — and that careful verification, not raw model output, is what makes the results trustworthy.

How it works

OpenAnt runs a six-stage pipeline that narrows the search space before spending any model tokens, then increases scrutiny on what remains.

1. Code parsing. Functions are extracted via language-specific ASTs into a bidirectional call graph (Python, JavaScript/TypeScript, Go, C/C++, Ruby, PHP). No LLM cost.
2. Reachability filtering. Only functions reachable from external entry points (HTTP handlers, CLI parsers, WebSocket handlers, file readers) are kept. This alone removed about 97% of code in large projects. No LLM cost.
3. Exposure classification. A Claude Sonnet 4 agent traces callers and data flow to label each unit exploitable, vulnerable-internal, security control, or neutral.
4. Vulnerability detection. Claude Opus 4 reasons about each exposed unit: what it does, where input originates, and what could go wrong.
5. Adversarial verification. This is the differentiator. Instead of asking a model “can you exploit this?” — a prompt to which agreeable models almost always say yes — OpenAnt forces a constrained attacker persona: browser-only access, no server-side privileges, no admin credentials, no local file access. Every exploitation step must be traced explicitly, and a valid finding must harm a party other than the attacker. About half of flagged findings were eliminated here as impractical.
6. Dynamic verification. For survivors, the system generates a Dockerfile and test script, runs the exploit in an isolated container (read-only filesystem, memory and CPU caps, 120-second timeout), and discards every artifact afterward. The container must report CONFIRMED, NOT_REPRODUCED, BLOCKED, INCONCLUSIVE, or ERROR.

Across eight real projects (OpenSSL, Flowise, n8n, WordPress, Rails, paperless-ngx, eShopOnWeb, object-browser) totalling 64,132 functions, filtering cut the set to 2,281 reachable units, then 586 externally exploitable units. Detection flagged 376, adversarial verification confirmed 190, and dynamic testing independently reproduced 144 of them — a 75.8% reproduction rate — spanning more than 30 vulnerability classes including IDOR/missing authorization, mass assignment, SSRF, path traversal, and injection.

Why it matters

Two numbers tell the story. First, the full run cost about $1,461; without reachability filtering the same analysis would have cost roughly $23,700, so disciplined scoping made repository-scale LLM analysis affordable. Second, three-quarters of confirmed findings came with an automatically generated, working proof of concept — not a speculative “this looks risky” warning.

That combination matters because traditional static analysis (SAST) drowns teams in false positives — empirical studies report rates from low single digits to over 40%, and only about 20% of developers actively use SAST as a result. OpenAnt’s closed loop attacks exactly that problem: the adversarial persona and the dynamic run filter out theoretical findings that cannot be reached by a remote attacker. It sits alongside industry efforts like Google’s Big Sleep, OpenAI’s Aardvark, and Anthropic’s Claude Code Security.

The defensive flip side is unavoidable: the same economics that let a maintainer scan their own code let an attacker scan it too. When verified, exploitable findings can be produced for the price of a few API calls, the window between public disclosure and in-the-wild exploitation keeps shrinking.

Defenses

For maintainers and security teams, the practical takeaways are concrete:

• Use closed-loop tooling on your own repositories first. OpenAnt is free and defensive by design; Knostic also offers no-cost scans for open-source projects. Running it on code you own — and only code you own — turns the asymmetry back in defenders’ favor.
• Never trust a raw LLM “vulnerable” verdict. Agreeable models confirm almost anything. Require a constrained-attacker trace and, ideally, a reproduced exploit before triaging a finding as real.
• Prioritize externally reachable entry points. Reachability filtering reflects how attackers actually think; harden HTTP handlers, CLI parsers, and file readers before internal utilities.
• Shorten your patch cadence. Assume verified findings against disclosed bugs can appear within hours. Pair this with coordinated disclosure when you find issues in others’ code.
• Keep complementary methods. OpenAnt targets input-to-sink flaws (injection, SSRF, path traversal, authz bypass, XSS). It is weaker on logic bugs, race conditions, memory-safety classes, and protocol violations — keep fuzzing and, for critical components, formal methods.

Status

Item	Detail
Paper	arXiv:2606.19149, public June 17, 2026 (first pre-release March 11, 2026)
Code	github.com/knostic/OpenAnt, Apache 2.0
Eval models	Claude Sonnet 4 (stages 3, 6) and Claude Opus 4 (stages 4, 5)
Scope	Input-driven flaws across 6 languages; not logic/race/memory-safety bugs
Maturity	Released as research, several features in beta

The authors note OpenAnt provides empirical evidence of exploitability, not formal proof, and that the absence of a reproduced exploit does not prove a vulnerability is impossible.