Topic starter
09/07/2026 9:33 am
TL;DR: Static analysis and fuzzing alone miss too much at repository scale, so the system combines reachability-filtered units, adversarial verification, and sandboxed dynamic validation to reduce attack surface by up to 97% while finding previously unknown vulnerabilities, according to Knostic’s OpenAnt research. The result is a stronger model for secure code review, but one that also exposes how cost, context, and verification now shape LLM-assisted vulnerability discovery.
Editorial analysis by NHI Mgmt Group, based on content published by Knostic: “OpenAnt: Read the LLM Vulnerability Paper”.
By the numbers:
- OpenAnt reduces the attack surface by up to 97% through reachability-filtered analysis units.
Key questions
Q: How should security teams handle AI-generated vulnerability findings in the release pipeline?
A: Security teams should treat AI-generated findings as inputs, not decisions.
Q: Why do reachability filters matter in LLM-based code review?
A: They reduce the search space to code paths that an attacker could plausibly hit, which lowers compute cost and cuts down irrelevant findings.
Q: What are the signs that AI-assisted vulnerability hunting is becoming noisy?
A: The clearest signs are a surge in low-confidence findings, duplicated issue reports, and a growing backlog of items that no one can verify quickly.
Practitioner guidance
- Define a verification threshold for AI-assisted findings Require every LLM-generated vulnerability candidate to pass an explicit exploitability check before it enters triage or remediation workflows.
- Gate repository-scale analysis with reachability Filter code into reachability-based analysis units so expensive reasoning and sandboxing only run on paths that an attacker could plausibly reach.
- Use disposable sandbox environments for validation Run dynamic exploit tests in isolated containers and destroy the environment after validation to prevent residual state or accidental reuse.
Bottom line: LLM-assisted bug hunting becomes materially useful only when runtime verification separates plausible defects from false positives.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 9:34 am
Runtime verification is becoming the deciding control in AI-assisted vulnerability discovery. LLMs can reason semantically about code, but semantic reasoning alone does not prove exploitability. Once repository scale enters the picture, verification quality becomes the factor that determines whether AI output is operationally useful or just another stream of false positives. For practitioners, that means the governance question is no longer whether to use LLMs, but where to place the proof boundary.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How do teams keep sandboxed validation from becoming a security risk itself?
A: Use isolated, disposable environments with no persistence between runs, tightly scoped inputs, and clear teardown after each test. Validation systems should exist only to prove exploitability, not to accumulate state or expand access. The control objective is containment, reproducibility, and short-lived execution.
👉 Read our full editorial: OpenAnt shows why LLM vulnerability discovery needs runtime verification