OpenAnt: Two-Stage LLM Vulnerability Discovery, From Detection to Attack Verification
OpenAnt from Knostic is the leading open source LLM-based vulnerability discovery product, helping defenders proactively find verified security flaws while minimizing both false positives and false negatives. Stage 1 detects. Stage 2 attacks. What survives is real.
At a glance
- What is it?
- Knostic's OpenAnt is an Apache-2.0 Python tool that runs LLM-driven vulnerability discovery in two stages: detection followed by attack verification, with per-phase model routing across Anthropic, OpenAI, Google, Bedrock, OpenRouter, or local Ollama. The README calls it a productized research project with beta features, so the honest question is where the two-stage design earns its token cost and where it does not.
- Who is it for?
- OpenAnt is worth evaluating if you maintain a Go or Python repository and want an LLM pipeline that attempts to verify its own findings before you triage them. It is the wrong tool if you need one-command CI integration today or if your codebase is in one of the beta languages.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The False Positive Problem OpenAnt Targets
Static analysis tools have always produced findings that a human then has to disprove. LLM-based scanners changed the wording of the findings but not the underlying problem: a model reading a function can describe a plausible vulnerability without any evidence that the path is reachable or the input is attacker-controlled. OpenAnt's stated premise is that defenders need verified flaws, and its tagline describes the mechanism: Stage 1 detects, Stage 2 attacks, and what survives is real. The audience is named directly in the README. Open source maintainers are the primary target, with a free scanning service offered for repositories, and the project explicitly positions itself as complementary to OpenAI's Aardvark (now Codex Security) and Anthropic's Claude Code Security rather than as a competitor to them. Knostic's own commercial focus is agent and coding-assistant protection, which explains why a vulnerability research tool was released under Apache-2.0 rather than kept internal.
How the Two-Stage Pipeline and Per-Phase Model Routing Work
The architecture visible in the material is a pipeline of seven phases, each routed through its own (provider, model) pair. The README does not enumerate all seven by name, but it does describe the split in capability: stronger reasoning models are recommended for detection, verification, and reachability review, while lighter models are suggested for context, report, and test generation. Two of the phases, enhance and verify, run an agentic tool-use loop, which means the model calls tools rather than only reading text. This is the load-bearing design decision. Verification is not a second opinion from a different prompt; it is an agent that can act on the code. Any shipped adapter can drive those phases because all of them support tool calling, with the README warning that very small local models may not handle tool calls reliably. The practical consequence is that model choice per phase is a cost and reliability dial you control, not a fixed property of the tool.
Getting OpenAnt Running: Build, Configure, Scan
The CLI is written in Go, not Python, despite the repository's primary language being Python. Building it requires Go 1.25 or later and two commands from the repository root: `cd apps/openant-cli && make build`, which outputs the binary to `apps/openant-cli/bin/openant`, followed by `ln -sf "$(pwd)/apps/openant-cli/bin/openant" /usr/local/bin/openant` to put it on your PATH. The README notes the symlink must be run from the repo root so `$(pwd)` resolves correctly. Configuration is the interesting part. `openant setup llm` is an interactive wizard that names a config, asks you to pick a provider per pipeline phase, collects an API key once per provider, probes each unique provider and model pair with a 1-token request, and writes `~/.config/openant/config.json`. You then scan with `openant scan /path/to/repo --llm-config my-llm`. If you only use Anthropic, there is a shortcut: `openant set-api-key sk-ant-...` followed by `openant scan /path/to/repo`, which uses the built-in `openant-default` config compiled into the binary, with Claude Opus 4.6 for detection phases and Sonnet 4 for the rest. Hand-edited configs are supported, and every llm-config must list all seven pipeline phases.
Provider Choices and What Each One Actually Costs You
Six adapter types ship: anthropic, openai, google, bedrock, openrouter, and ollama. The README is unusually direct about billing, stating three separate times that API access is not included in consumer subscriptions. Claude Pro and Max do not cover the Anthropic adapter. ChatGPT and Codex subscriptions do not cover the OpenAI adapter. Gemini Advanced does not cover the Google adapter. Bedrock takes no api_key at all and instead reads the AWS credential chain from `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, or a `~/.aws` profile, with the region from `AWS_REGION`; model IDs are inference profiles such as `us.anthropic.claude-sonnet-4-6`, and they must be enabled under Model access in the Bedrock console and listed with `aws bedrock list-inference-profiles`. OpenRouter gives one key and one prepaid balance across many providers, with `vendor/model` slugs like `anthropic/claude-sonnet-4.6`. Ollama runs locally with no key, defaults to `http://localhost:11434/v1`, requires models to be pulled first with `ollama pull <model>`, and reports $0 cost. That last option is the only one where the token-cost question disappears, at the price of local hardware and the tool-calling reliability caveat.
Language Coverage Is Uneven and the README Says So
Nine languages are listed, but only Go and Python are presented without qualification. JavaScript/TypeScript, C/C++, PHP, Ruby, Zig, Swift, and Rust are all marked beta. That is a meaningful distinction for adoption, because a scanner that produces unverified or lower-quality output in a beta language is exactly the false-positive generator OpenAnt claims to replace. If your repository is primarily Rust or TypeScript, the two-stage verification story is a claim about the pipeline, not a guarantee about your language's parsing and context quality. The README does not explain what beta means per language, whether it is tree-sitter coverage, prompt tuning, or test generation support, and that gap is worth resolving before a trial. Go and Python users are on the strongest footing; everyone else is an early adopter by the project's own labeling.
Where OpenAnt Is the Wrong Tool
The README states plainly that this started as a research project and that some features are still in beta. That sentence should govern expectations. There are no retrieved releases, which means there is no versioned artifact to pin, no changelog to read, and no upgrade path documented in the material. The last push date suggests active development, but active development on master is not the same as a stable interface. The CLI is Go while the core is Python, so a contributor touching detection logic and a contributor touching the command surface are working in different languages and build systems. Verification through an agentic loop is also not free: it multiplies model calls per candidate finding, and the README points to an external blog post for token costs rather than stating them inline. If your constraint is a fixed CI budget or a hard latency ceiling, a two-stage agentic pipeline is structurally the wrong shape. And if you need findings to be actionable without human review, no LLM scanner including this one offers that.
How This Differs From Semgrep and CodeQL
The obvious comparison is Semgrep or CodeQL, and the difference is in where the reasoning happens. Those tools compile rules, either hand-written or generated from a query language, and match them against a parsed representation of the code. Detection is deterministic, reproducible, and cheap to run repeatedly; the cost is that someone has to write and maintain the rules, and novel vulnerability classes are missed until a rule exists. OpenAnt inverts this. There are no rules to write. The model reads the code, proposes findings, and then a second agentic stage attempts to attack them. That means coverage extends to patterns no one wrote a rule for, and it means every scan costs tokens, produces different output on different runs, and depends on model behavior that can change when a provider updates a model. Semgrep gives you a stable, auditable result set. OpenAnt gives you a broader but probabilistic one. For a maintainer with limited review time, the second stage is the part that matters, because it is the only thing standing between the model's suggestions and your issue tracker.
Licence, Maintenance, and What to Verify First
OpenAnt is Apache-2.0, which permits commercial use, modification, and redistribution with the usual attribution and notice requirements, and it includes a patent grant. That is a permissive choice consistent with the README's stated intent of helping open source maintainers, and it means you can embed the tool in an internal pipeline without a licensing conversation. It is not legal advice; if you plan to redistribute a modified version, read the licence text and your own obligations. On maintenance, the material supports only a limited read: no releases have been retrieved, the default branch is master, and the project describes itself as having moved from research to product with beta features remaining. The practical verification steps are concrete. Run `openant setup llm` and confirm the 1-token probe succeeds for every provider and model pair you selected, because a phase that silently fails to reach its model will produce a weaker scan rather than an error. Then scan a small Go or Python repository with a known vulnerability and check whether the verify phase reports it as surviving. Until that holds on your own code, the two-stage claim is a description of the design, not a result you have observed.
Editorial conclusion
OpenAnt is worth evaluating if you maintain a Go or Python repository and want an LLM pipeline that attempts to verify its own findings before you triage them. It is the wrong tool if you need one-command CI integration today or if your codebase is in one of the beta languages. Before adopting it, run `openant setup llm` against a small repository, confirm the tool-use loop actually completes with your chosen model, and measure token spend on a single scan before pointing it at anything large. The README itself states this started as a research project with features still in beta, and that is the correct frame for deciding.
Community notes