August 11, 2026 (Ulrich Lang) — AI has changed the economics of vulnerability discovery. Work that once required scarce expertise, specialized tooling, and hours or days of expert effort can increasingly be automated. Frontier models can read unfamiliar code, generate vulnerability hypotheses, write proof-of-concept exploits, and in controlled environments chain those steps together without human direction.

That is genuinely good news for defenders. It also creates an asymmetry that defenders should think carefully about.

Attackers and defenders do not need the same accuracy. An attacker can explore a thousand hypotheses, discard the ones that fail, and keep searching. False leads cost compute, time, and some risk of detection — but the objective is asymmetric: find one viable way in. Defenders face the inverse. Every credible finding must eventually be evaluated, prioritized, mitigated, or consciously accepted. And AI now generates candidate findings far faster than organizations can absorb them.

The offensive side of this is no longer speculative. In April 2026, the UK AI Security Institute reported that Claude Mythos Preview became the first model to complete “The Last Ones,” a 32-step simulated corporate network attack running from initial reconnaissance to full network takeover — a chain AISI estimates takes a human expert around 20 hours. The model finished it end-to-end in 3 of 10 attempts and averaged 22 of 32 steps; the next-best model averaged 16. A later checkpoint completed the range in 6 of 10 attempts and became the first model to complete AISI’s operational-technology range, solving it in 3 of 10.

The caveat belongs in the same breath, because AISI states it plainly: these are small, undefended networks with initial access already obtained, run without active defenders or defensive tooling and without penalty for triggering alerts. The results demonstrate autonomous capability against weakly defended environments, not that a model can walk through a hardened enterprise network.

That distinction matters. The claim here is not that autonomous AI is about to conquer segmented industrial networks. It is narrower and harder to argue with: the same underlying capabilities that make offensive discovery cheaper are also scaling defensive discovery and vulnerability reporting, creating more findings competing for finite verification and remediation capacity.

The funnel is the story

Anthropic’s open-source vulnerability work makes the shape of the problem visible. Its coordinated vulnerability disclosure dashboard, snapshotted May 22, 2026, reported:

• 23,019 candidate findings across more than 1,000 open-source projects
• 1,900 of those findings reviewed by external security firms
• 1,726 of that reviewed subset confirmed valid — a 90.8% true-positive rate on the 1,900 reviewed, not on all 23,019 candidates
• 1,596 findings reported to maintainers across 281 projects
• 97 patched upstream, with 88 published advisories

It is tempting to read the last line as evidence that AI produces noise. It isn’t. Anthropic gives three reasons the patch count was low, and all three are worth taking at face value: the disclosures were still early in the 90-day window, patches applied without a public advisory are undercounted, and — in Anthropic’s own framing — the work was adding to an already-overloaded security ecosystem.

Within the externally reviewed subset, precision was high, although Anthropic cautions that this metric includes duplicates and valid findings maintainers may ultimately choose not to fix. The more obvious constraint was human review, coordination, and remediation capacity. Anthropic itself describes triage as a rate-limiting step.

Discovery scaled. Verification and remediation did not.

Two different problems, often conflated

The industry is currently absorbing two distinct pressures, and it helps to keep them separate.

The first is low-quality volume. In March 2026, Bugcrowd reported that its triage queues grew by more than 334% in three weeks — excluding legitimate reports produced through traditional researcher workflows. The submissions shared a profile: thin evidence, templated write-ups, and no verification before sending. Bugcrowd later described the pattern as “sloptimism”: trusting the model’s output more than the underlying evidence.

The curl project ended its paid bug bounty in January 2026 after its confirmed-vulnerability rate fell below 5%, amid a surge in low-quality AI-generated reports. Apple’s Security Bounty terms now address repeated high-volume submission of AI-assisted claims that have not been validated through human review, while its bounty guidelines emphasize reproducibility and concrete proof.

None of these are bans on AI-assisted research. They are demands for verification before handoff.

The second pressure is high-quality volume, and it is the harder one. Even if nearly every escalated finding is real, ten thousand real findings are still ten thousand findings. Each competes for scarce engineering time. Each requires context, code changes, testing, deployment, and regression analysis. Perfect accuracy does not solve this.

The industry response reflects that. In June 2026, the Linux Foundation and a group of founding members launched Akrites, focused specifically on coordinated remediation and disclosure — including a shared incident response team, a standardized disclosure process, and a “maintainer of last resort” role for critical unmaintained packages. Endor Labs, a founding member, put the gap plainly: of the thousands of validated open-source vulnerabilities surfaced in recent months, fewer than 5% had been patched.

Note what Akrites is not. It is not another discovery tool.

The center of gravity is moving.

The question has changed

Security has counted findings for years. SAST tools, dependency scanners, CVE feeds, SBOM platforms, and cloud-security products all produce queues. If generating one more candidate approaches zero marginal cost, raw finding counts become an increasingly weak measure of security effectiveness.

Identifying 10,000 weaknesses does not make an organization safer than identifying the 20 that are reachable, exploitable, and present in the software as actually deployed. As Bugcrowd recently argued, the real leverage increasingly comes from identifying the relatively small number of fixes that cut off the most meaningful attack paths.

For each finding, someone still has to answer: Is the affected code reachable? Under what conditions? Does it affect our build, our configuration, our deployment? Is another control already mitigating it? What justifies spending engineering time here rather than on the other 999?

Every one of those is a verification question, and every one of them is expensive.

Probabilistic discovery, deterministic evidence

Large language models are probabilistic, and that is a large part of their value. They reason across unfamiliar code, connect unrelated signals, and explore directions rule-based systems would never consider. Defenders should use that.

But a decision to spend engineering time is deterministic. Can this input actually reach this operation? Can this execution path occur? What conditions are required? What concrete behavior demonstrates the issue?

This is where deterministic analysis earns its place. Symbolic execution reasons mathematically about feasible execution paths and the constraints required to reach them. It is not magic and it is not exhaustive — complex software creates real scalability and path-explosion problems, which is why practical symbolic-execution systems constrain and target exploration.

That creates a natural division of labor: AI can orchestrate the investigation — deciding where to look, selecting analyses, following results, and coordinating tools — while deterministic analysis establishes repeatable technical evidence about what the software can actually do.

Reproducible evidence is exactly what a flooded triage queue is short of.

Where BinLens fits

ObjectSecurity BinLens 4.0 applies this architecture across compiled binaries, bytecode, and source code. Its AI layer is primarily used for agentic orchestration rather than as the sole source of vulnerability conclusions: agents can decide which analyses to run, follow up on findings, correlate results across tools, and let an analyst steer an investigation conversationally. Underneath that orchestration layer, BinLens uses analysis techniques including symbolic execution, static analysis, disassembly, decompilation, and other integrated analyzers to establish the technical evidence behind a finding — without requiring the LLM itself to be the final source of truth.

Real software estates are heterogeneous in practice: a project may contain source code, bytecode, third-party libraries, native executables, containerized applications, firmware, and components for which source is unavailable. Each representation provides different security information, and in many cases it is useful to analyze more than one.

Binary analysis can be important even when source code is available. In a DevSecOps workflow, the binary, shared library, container payload, or other compiled artifact is ultimately what gets deployed and executed. Analyzing that build product provides assurance on what will actually run, rather than only on what the source was intended to produce. It can also expose security-relevant behavior associated with the compiled artifact, bundled third-party components, build configuration, linking, and platform-specific execution that may not be apparent from source analysis alone.

The same capability becomes even more important in OT/ICS, embedded, supply-chain, legacy, and defense environments, where the deployed binaries may be the only artifact available or where software cannot be rebuilt or patched on a normal development cycle. In those cases, remediation may involve a compensating control — network segmentation, input filtering, a configuration change, or accepting the risk with documented justification — rather than simply changing source code and shipping a new build.

You cannot make those decisions from a list of suspected weaknesses alone. You need evidence about what the software can actually do.

One concrete example is BinLens symbolic execution: a finding can include the program’s function call stack at the point where a vulnerability is encountered, together with an “Input to Reproduce” showing the inputs that drive execution to that condition. Depending on the software, that can include command-line input, file content, stdin, or ordered TCP/UDP packets.

That changes the analyst’s starting point. Instead of “an AI or scanner thinks this code may be vulnerable,” the analyst has reproducible evidence that can be compared against the interfaces, configuration, operating environment, and controls of the deployed system. That helps determine whether a path is practically reachable, what an attacker would need to control, which findings deserve immediate remediation, and where a compensating control or evidence-backed risk acceptance may be appropriate.

What to ask

For decades, finding vulnerabilities was one of security’s scarcest capabilities. AI is rapidly reducing that scarcity, and the metrics built around it are aging quickly.

The question for security leaders is no longer simply how many vulnerabilities their tools can find. It is:

Which vulnerabilities are real, reachable, and important enough to act on first — and what evidence supports that decision?

Because attackers need one vulnerability.

Defenders face thousands.