Breach Paths
5 min read

Open Offensive AI Is Compressing the Exploit Window. CVE Counts Won't Tell You What's Exposed.

Published on
November 10, 2026
A printer spills a long vulnerability findings report across the floor while the door to a server room stands open.

By Om Moolchandani, Co-Founder & CISO/CPO, Tuskira

What Changed

Open-source agentic frameworks built for offensive security are already showing up in real intrusions. Google Threat Intelligence Group and Mandiant report that since late August 2026, extortion groups and suspected state-backed espionage clusters have used frameworks such as ARTEX and PentAGI for reconnaissance, credential theft, privilege escalation and lateral movement. Google describes this use as early and low in sophistication, noisy but still successful. Speed is the advantage. In one case an actor went from a first compromised account to deep system access in about 15 minutes.

Capability is rising underneath those tools. Academic benchmarks now show frontier models turning known vulnerabilities into working exploits, including against targets with standard mitigations enabled.

For a CISO, the access model matters more than the benchmark. When exploit development gets cheap, attackers can turn a published CVE into a working attack faster, and they can afford to try many more of them.

Why CVE Counts Fall Short

Scanners give you findings. CVSS gives you severity. Remediation SLAs give you weeks. None of those tell you whether a finding can be reached in your environment, or whether a control you already run stands in the way. Those timelines assumed exploit development was slow and expensive. That assumption is getting weaker.

Finding counts were already a weak board metric. When exploits are cheap to produce, they understate the risk, because the number that matters is how many of those findings an attacker can reach and use today.

What Defenders Should Measure

Defenders need a current model of the paths through their environment and the controls deployed along each one. That model has to be refreshed as the environment changes, because a path that was closed last week can open after one configuration change.

How Tuskira Approaches It

Kairo, our breach path agent, works over a live digital twin built from the tools you already run. Deterministic path analysis maps the routes an attacker could take. A neural graph simulates which of those routes an attacker is most likely to use. Control validation then tests each route against the controls you have deployed today and shows which ones are open. The result is a current, prioritized list of breach paths an attacker could use right now, along with the changes to controls you already own that can close each one.

Kairo breach graph showing six routes from the internet through exposed services, misconfigurations and over-permissioned roles to crown-jewel systems
The breach graph in Kairo. Each line is a route an attacker could take from the internet to a crown-jewel system, in this case a customer data lake, the production API plane, source and CI/CD, a secrets vault, and mail and files. Kairo tests each route against the controls deployed today to show which ones are still open. Demo environment, illustrative data.

The gap between what your vulnerability program considers addressed and what Kairo still shows as reachable and undefended is your real exposure.

In one global financial-services deployment, Tuskira reduced 12.3 million findings to 0.46% requiring action, giving the team a far shorter priority list.

Three Moves to Make This Quarter

First, change the number your board tracks. Replace “how many critical CVEs” with “how many breach paths are open right now into the systems that matter.”

Second, measure the gap. Take the findings your program has marked addressed in the last quarter and check which of them are still reachable and undefended. That list is where your reporting and your real exposure disagree.

Third, test one crown-jewel environment the way an attacker with an offensive model would. Pick your customer data path or your production CI. Run Vector, our autonomous red team agent, against it within a scope you approve. Kairo validates what Vector finds against the controls you have deployed and shows which paths are open. Close those paths through controls you already own, then have Vector re-run the same attacks to confirm each one is closed. The count of open paths into that environment, before and after, is the number to take to your board.

Govern Your Own Agents

Open offensive AI also makes governing an organization’s own agents more urgent. An agent with access to privileged tools and data can be talked into misusing them through prompt injection. For agents routed through it, Tuskira’s open-source AI Agent Gateway checks every tool call passing through the gateway before it runs, limits each agent to approved tools, holds the underlying credentials, and sends a log of every call to your SIEM. The code is at github.com/Tuskira/ai-agent-gateway.

See Kairo and Vector working against your own environment →

Sources: Google Threat Intelligence Group and Mandiant, “ARTEX and Friends: Enter Agentic Offensive Frameworks,” Google Cloud Blog, October 30, 2026. Berkeley RDI, “ExploitGym,” UC Berkeley, May 13, 2026 (paper: arXiv 2605.11086).