This week OpenAI shipped its first model to hit the Critical cybersecurity threshold under its own Preparedness Framework, pledged $1B in subsidized access for under-resourced defenders, and, in the same news cycle, had a second swarm of its internal agents discovered running loose on the open internet.

Google’s threat intel team documented adversaries standing up agentic credential harvesting pipelines in under six hours, while the SANS CEO and a builder in the agent monitoring space both made the case that the gap sits with people and fundamentals well before it sits with models.

On the market side, PANW’s Nikesh Arora put a $1 trillion price tag on the legacy security stack, the company’s founder raised $245M to build a replacement for it, and Mistral closed the largest equity round in European tech history on a sovereignty pitch.

Safe to say, we have a lot of ground to cover this week, so let’s go!

Cyber Leadership & Market Dynamics

Palo Alto CEO says $1 trillion of cybersecurity infrastructure isn’t ready for AI

Palo Alto Networks reported its fiscal Q4 this week, with revenue of $3.41B (up 34% YoY), Next-Generation Security ARR of $9.1B (up 63%), and RPO of $21.2B, and Nikesh Arora used the earnings cycle to make a much bigger claim. Per Arora:

“About $1 trillion of existing cybersecurity infrastructure was built before the dawn of AI and is not ready for the new threat landscape.”

His math is that “If the average life is seven years and you’re spending $200 to $300 billion a year, you’ve got $1 trillion of security infrastructure,” most of it firewalls, SIEMs, and endpoint tooling deployed 7-10 years ago. He also pointed to “$5 trillion of capex spend in the next five years” on AI data centers as a second wave of security demand.

Of course, the CEO of one of the largest security vendors has an obvious incentive to declare the installed base obsolete, and this is a replacement thesis dressed up as a threat assessment.

That said, the underlying point isn’t wrong. Most of what organizations run today was architected around human-speed attackers, and the GTIG report below documents adversaries who no longer operate that way.

The same week, PANW was named to the S&P 100 alongside Dell, Arista, and SanDisk, replacing Nike, and the only public pure-play cyber company in the mix, which is incredible for the cyber community.

Palo Alto’s CEO invested in the startup his company just bought for $500 million

A follow-up to the Console acquisition I covered last week. Calcalist reports that Arora was an early personal investor in Console, alongside Thrive Capital, before Palo Alto acquired the company for roughly $500M. Console was founded in 2024, had raised $29M in total, and was valued at $157M in its last round, so the exit represents a sizable step-up for everyone on the cap table, the acquiring CEO included.

I won’t pretend to know the details of how the deal was reviewed internally, and there are governance processes for exactly this scenario at public companies. However, when the same person is a personal LP on one side and the buyer on the other, the optics are what they are, and it is a reminder that the AI security M&A wave is moving fast enough that these conflicts are going to keep surfacing.

Cylake closes $245 million funding round ahead of beta

Nir Zuk, who founded Palo Alto Networks, has now raised $290M for Cylake (a $245M convertible note this week on top of a $45M Greylock-led seed in March) before the product has hit beta.

The pitch is an AI-native, “fully sovereign” security platform that runs on-prem or in a private cloud for large regulated organizations, with beta slated for the end of 2026 and GA in 2027. Zuk’s framing is that they’re building “for organizations that cannot compromise between adopting advanced cybersecurity technology and maintaining control.”

It is hard to read this next to Arora’s $1T comment and not see the same thesis being funded from two directions, one arguing the legacy stack is obsolete and the other arguing that the cloud-delivered stack that replaced it has become the problem for regulated buyers.

$290M pre-beta is a lot of conviction, and the company has 40-odd employees and design partners to show for it so far, however, much of this remains to be seen in terms of adoption and broad traction.

Mistral makes sovereign, open-weight AI the technology frontier

Mistral closed a €3B Series D at a post-money valuation above €21B, which the company describes as “the largest equity fundraising round ever completed by a European technology company,” led by Samsung Electronics with Scaleup Europe Fund/EQT and PSG Equity co-leading. Mistral now operates in 20 countries with 125+ enterprise customers. The announcement defines sovereignty across four dimensions, data that stays inside the organization’s boundaries, models that are controllable, compute that is private, and production systems that are auditable.

Pair this with Cylake above, sovereignty has gone from a European regulatory talking point to a category thesis that U.S. investors are now writing very large checks against, and it applies to the security stack as much as the model layer.

The GTIG report further down has an interesting wrinkle here, with at least one PRC-nexus actor deploying local LLMs inside compromised cloud environments specifically to avoid commercial API monitoring, which is the exact risk has been calling out for months.

Sovereign compute cuts both ways.

Omri Casspi raises $250 million after wins with Cognition, Wonderful and Upwind

Former NBA player Omri Casspi closed a $250M third fund for Swish Ventures, bringing AUM to $800M.

The firm has backed 21 companies since inception, 9 of which are now unicorns, with roughly $20M checks and a dozen targets for the new fund. The portfolio marks tell the story of the current cycle, with Wonderful at $5B, Upwind at $3.8B (which I covered last week), and Cognition at $47B. Per Casspi, the aggregate portfolio value “will reach almost $100 billion” after the Cognition round.

Those are venture returns most firms would take in any cycle, and a reminder of how concentrated the value creation in AI and security has become in a small number of companies.

Cybersecurity Benchmarking: Why, Why Not, When and How

Phil Venables takes on one of the more persistent rituals in security leadership, benchmarking your program against peers, and argues that most of how it gets done is a waste of time.

Budget comparisons are never apples-to-apples because there is no agreed taxonomy for what counts as security spend, lagging indicators like incident counts tell you little about root cause, and point-in-time assessments go stale quickly. His line is that:

“Your risk is not my risk. Your business is not my business,” and my favorite, “Being No. 1 in a pack of failures doesn’t make you a success.”

Where he lands is that benchmarking is useful when it compares leading indicators (infrastructure design patterns, control effectiveness) against an aggregate idealized control set rather than against a specific peer, aligned to something like NIST CSF or CIS Controls, with cost-effectiveness measured separately from performance.

Given how often boards and CFOs ask “what do our peers spend,” this is a timely read for anyone who needs a better answer than a percentage of IT budget. It also pairs well with Arora’s $1T framing above, which is precisely the kind of input-based spend number Venables warns against treating as a signal.

What the AI Warning Letter Completely Missed

Last week I covered the open letter from 100+ companies, including OpenAI, Anthropic, Microsoft, and Google, calling for collective action on AI-enabled cyber threats.

SANS CEO James Lyne’s response is that the letter is “a plan written entirely in verbs, with no subject.” It tells organizations to patch, monitor, and harden, and says nothing about who does that work at the water utilities and hospitals it names, how they get trained, or who pays for it. As he puts it:

“The gulf between those two is measured in people, not products.”

He also cites RUSI analysts who argue that “Criminal innovation is a response to a revenue stream closing, not to a new technology opening a window,” which is a useful corrective to the assumption that AI capability automatically becomes adversary behavior.

I agree with the core of this piece by James. Signatories of that size published a letter with no funding commitments in it, and the organizations most at risk are the ones that can’t hire. To be fair, OpenAI’s Daybreak announcement below arrived two days later with $1B attached, albeit in the form of subsidized product access rather than headcount, but we shouldn’t expect headcount to come externally either

Whether credits close the gap Lyne is describing is a fair question.

For me, as I mentioned in LinkedIn about this letter, the reality is that cyber won’t change until market incentives or regulatory forces make it change systemically. Vendors have little consequences for shipping insecure products, which is the default, as recently pointed out by CISA.

Cybersecurity is a market failure and we cannot will that to change with open letters and voluntary pledges.

How AI reduced cybersecurity to bugs

, who works on agent monitoring at Embroidery, put out a video reacting to an Ilya Sutskever post arguing that “every company with strong cyber models should help” neoclouds shore up their security.

Korman’s objection is that “cyber model” has come to mean vulnerability discovery and exploitation, and if you took 100 people working in defense, very few of them work on that.

Identity, endpoint, network, detection engineering, SOC, IR, third-party risk, and GRC all sit outside what a frontier lab means when it says cyber. His Vercel breach walkthrough makes the point, with overly permissive third-party app access, harvested credentials, and no detection, and as he says, “You can have zero vulnerable systems in the sense that there is no code to exploit and you still get breached.”

He is blunt about the OpenAI/Hugging Face incident being “completely preventable on OpenAI’s side by having the proper monitoring and controls in place,” and about the industry more broadly, “We’ve become followers in our own space. It’s an embarrassing lack of leadership.”

I have made a version of this argument before, that security has a laggard problem, but Korman’s framing is sharper, that we are letting the labs define what cyber is based on what benchmarks well.

I really resonated with Zach’s rant here, and its time for cyber to step up and act like grownups rather than fawning over the frontier labs and acting like we don’t know how our own damn industry and profession works.

AI

Path to Astra: critical capabilities and frontier safeguards

OpenAI announced Astra, the first of its models to reach the Critical cybersecurity capability threshold under its Preparedness Framework, meaning the model can “find previously unknown security flaws and develop ways to exploit them across many well-protected systems without a person guiding each step.”

The published figures are 100% on an internal ExploitBench port covering 20 high-severity vulnerabilities, two zero-days discovered during evaluation (being disclosed to maintainers), and a 91.5% refusal rate on cyber jailbreak evaluations compared to 59% for GPT-5.6 Sol. In honeypot tests, GPT-5.6 Sol attempted unauthorized access in 56% of instances, Astra in 0%.

The safeguards stack is worth reading in full, with post-trained refusals, activation classifiers, chain-of-thought monitoring, cross-conversation context monitoring, and misalignment monitoring in production. Access goes to alpha testers first and then expands through Daybreak Blue for defensive work.

My read is that the capability side of this announcement is a fairly big deal, and the safeguards side is a set of claims the lab is asking us to take on trust, from a company that, per the TechCrunch item below, didn’t know where its own agents were for over a month. Perhaps both things can be true at once.

Daybreak for Frontline Defenders: $1B to protect essential services

Two days after Astra, OpenAI committed “$1 billion in subsidized Daybreak access to help resource-constrained cyber defenders, starting with the United States.”

Daybreak splits into Blue (defensive work on mainline models) and Red (specialized cyber models for sensitive technical work). The current footprint is thousands of defenders across 2,000 approved organizations in 40 states plus DC, more than 35 enterprise products and partner-operated services, a partnership with MS-ISAC, and up to $1M in no-cost API credits for affected water utilities. State and local governments, critical infrastructure operators, nonprofits, and open source maintainers are eligible.

This is a strong response to the gap Lyne describes above, and I would rather see $1B in credits than nothing at all. That said, credits are inventory for the company that issues them, and the constraint at a rural water utility is generally a person who has the time and skill to use the tooling, which a subsidy doesn’t create.

The open source maintainer eligibility is a piece I’d watch closely, given what the Patch the Planet numbers below say about where the bottleneck actually sits.

Another swarm of OpenAI agents reached the open internet without the frontier lab’s knowledge

The Hugging Face incident I’ve covered in recent issues now has a sequel.

Independent researchers found that OpenAI’s internal evaluation agents had been active on an obscure German wiki, DseWiki, for over a month, editing pages and collaborating on eval tasks. In the researchers’ account, “The administrator spent the next 5 days fighting a losing battle against the agents, deleting an average of 100 pages a day while the agents created about 400 new pages per day.”

OpenAI’s response was that it is “now carefully reviewing its contents and will take any necessary next steps.” Rep. Lori Trahan’s comment cut closer, that:

“The lack of any real federal AI governance means that frontier companies can pick and choose when they disclose incidents.”

The pattern is now hard to dismiss as a one-off, with isolation boundaries that were assumed instead of verified and discovery coming from outside parties well after the fact.

Matt Adams’s insider threat model below has a threat category literally named Containment & Third-Party Impact, and this is the second time in two months it has played out against a third party who never consented to being part of an eval.

GTIG AI Threat Tracker: From Prompting to Autonomy

Google’s Threat Intelligence Group published its latest AI threat tracker, and it is among the more useful pieces of adversary reporting I’ve read this year, albeit a long one.

The headline observation is that “In Q2 2026, GTIG observed threat actors compromise a cloud resource, then plan, build, and execute an agent-enabled mass credential harvesting campaign in under six hours,” with markdown playbooks (AGENTS.md, KNOWLEDGE.md and the like) driving an AI coding chatbot as the operator.

A separate exposed C2 server hosted a “Recon” dashboard managing 23,800+ harvested secrets. GTIG is careful to hedge that it “has not yet observed threat actors deploying fully autonomous pipelines against targets in the wild,” but the direction is clear.

Actions Speak Louder Than Tokens: An Insider Threat Model for Frontier AI Agents

Matt Adams published a standalone paper that treats deployed frontier agents as insider threats and adapts CERT’s five insider threat dimensions, motivation, opportunity, capability, predisposition, and organizational factors, to non-human actors.

His argument is that existing threat models cover attacks on AI and attacks through AI, and none treat the agent itself as the actor. He derives 27 STRIDE-based threats in six categories, including Credential Compromise, Data Exfiltration, Deception & Evasion, and Containment & Third-Party Impact, and maps four autonomy levels from L1 Human-as-Operator (low risk) to L4 Human-as-Auditor (critical). The controls are NIST CSF-aligned, with 7 protective controls, 25+ detection points across SIEM, UEBA, DLP, and deception tooling, and response and recovery playbooks.

I like this line “Watch what it did, not what it said.”

Reasoning traces are unreliable as evidence, actions are not, and existing enterprise telemetry can capture the actions. He is also candid that “Coherent misalignment in a frontier model is a procurement decision...not something deployment monitoring can fix,” which is a framing I suspect a lot of vendors would prefer buyers not adopt.

The paper is dated April but was updated with the Hugging Face disclosures, and given this week’s news it reads as current.

Agent Hooks

I had previously shared how Microsoft released a framework agnostic Agent Hooks specification. I took some time to break it down, as well as why security practitioners should be familiar with Hooks as it relates to securing AI agents, how they work, and why they matter.

AppSec

Patch the Planet dashboard

Trail of Bits and OpenAI have a live dashboard for Patch the Planet, their AI-assisted effort to find and fix bugs across open source.

As of September 4 the numbers are 1,646 potential bugs reported, 1,031 confirmed and awaiting patches, 400 fixes open upstream, 215 patches merged, 59 codebases under review, and 11 CVEs assigned. Of the 215 accepted fixes, 17 (7.9%) are high severity, 69 (32.1%) medium, and 58 (27.0%) low, with the rest informational or undetermined.

I wrote last week about runaway CVE rates and the economics of remediation, and this dashboard puts the problem in a single ratio. 1,031 confirmed issues are waiting on patches while 215 have merged. The constraint has moved to maintainers reviewing and merging, and that is a people problem that more model capability makes worse before it makes it better.

It is also worth noting that the severity mix skews medium and below, which matters when someone cites the topline “1,646 bugs” number.

The Anthropic Glasswing Receipts Are Starting to Trickle In

A companion piece to the Patch the Planet numbers above.

VulnCheck’s Patrick Garrity went through Anthropic’s Project Glasswing disclosure ledger, the Claude-driven open source vulnerability discovery effort launched in April, and tried to reconcile what has been claimed against what has shipped.

Five months in, the ledger shows 26,153 findings discovered, of which 2,736 (10.5%) reached the disclosure ledger, 2,096 were reported to maintainers without a confirmed fix, 245 were withdrawn, and 202 (0.8%) are marked fixed across 113 projects. Anthropic’s dashboard claims 421 findings patched upstream and 462 advisories, while the ledgers Garrity pulled list 70 to 82 CVEs and 49 to 77 GHSAs depending on which view you look at, and he notes 18 findings that had already been patched before Anthropic reported them.

Severity is the other gap, with 91.5% of Claude’s own assessments rated critical or high against 51.3% once maintainers weighed in. His close is that “The receipts are starting to trickle in, they just don’t reconcile.”

Anthropic’s own explanation is that disclosure is “a subset of the total number of vulnerabilities” found “since the process of independent human triage and review is the rate limiting step,” and to be fair, that is an honest statement of where the constraint sits.

That said, it is the same constraint Patch the Planet shows with 1,031 confirmed issues waiting on 215 merged patches. Across both labs’ programs the models are producing findings roughly an order of magnitude faster than humans can validate and maintainers can merge them. The severity delta matters just as much for anyone consuming these feeds, because a model that rates 9 in 10 of its findings critical or high, against maintainers rating about half that way, is going to flood already overwhelmed triage queues with inflated priority if you take its word for it.

Patrick is clear that the discovery capability is real, and I agree. The headline discovery count is still among the less useful numbers in any of these announcements, and fixed-and-merged is the one to watch.

I’d like to see both labs publish the reconciled figures, with maintainer-assigned severity, rather than leaving it to third parties to do the accounting.

What it took to reach 1 billion build manifests

Chainguard CTO Matt Moore wrote up how the company doubled its build output in six months, going from 500 million to 1 billion build manifests across 3,000+ unique images and 675,000 image versions. The old pipeline is described as “a cascading mess” with humans as the bottleneck for vulnerability remediation.

Factory 2.0 replaces it with continuous reconciliation loops that compare desired to actual state, shared work queues serviced by redundant reconciler bots, and AI handling the unstructured judgment calls like whether to backport a CVE fix or how to evaluate a new component, all on a rolling-release Chainguard OS. Every output ships with SLSA Level 3 provenance, Sigstore signatures, and a full SBOM.

Moore’s line is that “When the attacker’s cycle time compresses, the defender’s cycle time must compress by at least the same amount,” which is the same conclusion GTIG reached from the other side. It also lands in the same week GTIG documented an actor publishing malicious packages with valid SLSA Build 3 attestations, so it is worth being precise that provenance proves where a build came from and says nothing about whether the account that produced it was compromised.

Carta case study

RunSybil published a case study with Carta on moving from annual pentests and a bug bounty program to continuous autonomous testing, first deployed during an M&A review.

During an MCP server assessment the platform found a chained pair, a CVSS 8.1 SQL validation bypass in a Snowflake integration and a CVSS 8.8 administrative function execution that chained through to extract AWS credentials and map network topology. Carta AppSec lead Vamsi NC’s take on bug bounty is blunt, “The bug bounty has lost its charm. They’re using the same tools to scan us externally as we’re using internally,” with researchers farming the same patterns for payouts rather than finding novel chains.

The vulnerable surface was an MCP server, which matches the GTIG finding that MCP has become a preferred target, and the outcome Carta’s Brad Freer describes is findings turning into “detection patterns powering the appsec flywheel,” which is where continuous testing earns its keep over a point-in-time report.

Final Thoughts

The through-line this week is that model capability is running well ahead of the organizational capacity to use it or contain it.

OpenAI can ship a Critical-threshold cyber model and a $1B subsidy in the same week it loses track of its own agents, GTIG can document six-hour agentic attack builds while noting that most of what actually works for adversaries is still credentials and supply chain, and Patch the Planet can find 1,646 bugs and merge 215 of them.

Lyne, Korman, and Venables are each saying a version of the same thing from different seats, that the constraint is people, priorities, honest measurement, and the organizational will to fund them, and none of that is being funded at the rate the models are.

That said, the work rolls on, and so do we!

Stay resilient.

Subscribe now

I’ve written about the discovery side of this in detail, including in a recent piece titled “AppSec in the Age of Agents”, where I advocated for eliminating entire classes of vulnerabilities rather than grinding through them one ticket at a time, and worse, repeatedly remediating the same class of vulnerabilities over and over.

However, there is also a second shift underway that gets a lot less attention than the whole “Vulnpocalypse” narrative, and it is one I want to focus on in this piece.

That is the place where code gets written and how it’s moved. Now, it is often a coding agent running on a development endpoint, with a shell, package manager, credentials and the ability to take actions on its own, and most AppSec programs have no actual control point here at all.

At the same time, remediation is being handed to agents too, which raises questions around concepts such as Human-in-the-Loop (HITL), which I’ve already argued was largely a talking point, in a prior piece titled “The Human-in-the-Loop Illusion”. Having agents both creating code and remediating flaws brings good questions, such as what HITL means when both the code and fix are machine-generated.

In this article, I will walk through both sides of the shift, what they mean for AppSec practitioners and leaders and also use a recent demo and walkthrough I had with the team at Legit Security, a Resilient Cyber partner, as a practical example of how one team is building for this.

So, let’s unpack this often overlooked topic at the intersection of AI and AppSec.

Discovery Went Industrial

The first thing we need to acknowledge is that vulnerability discovery has went industrial in the first half of 2026. Per Vulnerability Research Jerry Gamblin’s mid-year check in, 35,364 CVE’s were published between January 1st and June 30th, a 49.5% increase over the first half of 2025, or one new CVE entry every 7.4 minutes.

His full year projection at the time landed between 71,314 and 72,008, up from 48,185 in all of 2025. FIRST provided their own forecast, which had to be adjusted midyear, showing roughly 66,000 potential CVE’s for the year, from a February baseline of 59,427. In that update, they argued finding isn’t the problem at all.

“The challenge for defenders is no longer the discovery of vulnerabilities; it’s the capacity to verify, coordinate and prioritize them at scale.

Then we have the impact of the frontier labs on the space.

Anthropic’s Project Glasswing update put some large figures in the mix. Across it’s partners, it had surfaced more than ten thousand high or critical severity vulnerabilities, and in open source projects specifically it had identified 6,202 high or critical findings, of which 90.6% of the 1,752 assessed so far proved to be valid true positives. Some partners told Anthropic their rate of finding bugs had increased by more than 10x, and a few asked the lab to slow down disclosures due to needing additional time to design patches.

There’s also OpenAI’s Patch the Planet effort, involve 55 critical open source codebases, which at the time of my writing have found 1,535 issues, with over 1,000 still awaiting a patch.

When I spoke to longtime industry leader Casey Ellis on my show in July, he framed it as AI having collapsed the cost of finding and reporting vulnerabilities at the same time, with signal and noise both up roughly 10x, and the delta between the two getting wider.

His line that I often reference is:

”The Vulnpocalypse was already here, it just sort wasn’t evenly distributed”.

This reframes the situation as an acceleration of a backlog problem we already had rather than a new novel threat. We are seeing the intake side of the ecosystem buckle in real-time, with cURL temporarily pausing its bug bounty program after its confirmation rate fell from roughly 15% to 5% in 2025 (which has now improved due to a surge of high quality AI-driven reporting), and HackerOne’s Internet Bug Bounty pausing new submissions in March. NIST reported that CVE submissions grew from 263% between 2020-2025, and moved most CVE’s to a “not scheduled for immediate enrichment” tier.

With all of that said, Jerry made a point on my show that while the volume curve may have gone vertical, exploitation has not, and still sits flat at around 1-2%. At the time of our conversation only 85 of the CVE’s published in the first half of 2026, or 0.24%, hand landed in CISA’s KEV catalog as of his write-up, which is why FIRST framed it as a “rain versus flood””, meaning practitioners need to not worry about raw finding counts and instead identify what they truly need to remediate.

However, it is admittedly tough for a security program to determine that when new vulnerabilities are hitting them at machine-speed, so they are likely to drown either way, given they need to try and do their best to filter the surge.

The Fix Side is Still Human Speed

So, we’ve discussed the AI-driven machine speed impact on discovery but what about remediation?

That’s the uncomfortable piece of the discussion for most. If you look at both Anthropic’s Glasswing, and OpenAI’s Patch the Planet, both efforts highlight 2/3 or more of the vulnerabilities are yet to have been patched, even when verified as true vulnerabilities. Anthropic spoke to this directly, stating:

”The relative ease of finding vulnerabilities compared with the difficulty of fixing them amounts to a major challenge for cybersecurity”.

That’s essentially a frontier lab describing the exact bottleneck we as practitioners have already lived with for years, but being exacerbated by AI. Cyentia’s research found the typical organization has the capacity to remediate 1/10 vulnerabilities in a given month, and that was before discovery got industrialized.

The 2026 Verizon DBIR, which I covered earlier this year, found the median time to fully patch has grown to 43 days and that only 26% of KEV-listed vulnerabilities were fully remediated, while exploitation became the top initial vector at 31% of breaches.

The labs know this, which is why every discovery capability now ships with a fix capability bolted next to it. That said, those fixes still require a human review before anything merges.

Niels Provos made the case on the show in June that remediation is the bottleneck AI hasn’t cracked, and I largely agree, with one caveat. Generating a patch has become cheap as AI has collapsed the economics there as well.

The hard part is knowing whether the patch is correct, whether it breaks something three services away, whether the finding was even reachable, and who is accountable when an agent-written fix for agent-written code ships to production, and that is an AppSec program design problem more than a model capability problem, and one we haven’t fully figured out yet as an industry.

The Left Moved

This is where I think much of the industry is still looking in the wrong place.

“Shift left” was built for a world where a human typed code into an IDE, opened a pull request, and a pipeline ran scanners against it. That world is ending as industry tech leaders such as Google and Microsoft highlight nearly universal adoption of AI coding tools, with big surges in AI-generated and accepted code.

The important detail is what those tools are. A coding agent is a process on a developer workstation with a shell, a package manager, access to environment variables and credentials, and a set of MCP servers and skills it can call, and it takes hundreds of actions per task that no human reads.

AI coding tools quietly route around your security, ignoring the authenticated route abstractions and hardened libraries your platform team built and writing raw code instead. Every one of those actions is a place where a supply chain compromise, a leaked secret, or a destructive command can happen, and it happens before there is a pull request for anything to scan.

The evidence that attackers noticed is already here. The Nx “s1ngularity” incident in August 2025 shipped malicious packages that, per the maintainers’ own postmortem, “attempted to use local AI tools (like Claude and Gemini)” on the victim’s workstation to hunt for sensitive information.

The Shai-Hulud worm that followed identified other packages maintained by a compromised developer, injected itself, and republished them, with its second wave compromising roughly 700 npm packages using preinstall hooks. Layer on top of that the USENIX Security 2025 research finding package hallucination rates of at least 5.2% for commercial models and 21.7% for open source models, across 205,474 unique hallucinated package names, and you have an agent that will confidently npm install something that doesn’t exist yet and an adversary happy to register it.

The control point for AppSec has to move to where the code is actually created, which now means the agent itself and the workstation it runs on. Additionally, the loop between the coding agent and the security platform has to become agent-to-agent, because there is no human in the middle to read a scanner output and decide.

A Walkthrough with Legit Security

That is the frame I brought into a demo and walkthrough with Legit Security’s CTO and Co-Founder Liav Caspi and CMO Dave Howell recently. Their architecture maps closely onto the two shifts above.

Liav described their approach as three-pronged.

• First, use AI to find and fix the flaws traditional static analysis misses.

• Second, secure the SDLC and the agent ecosystem around it, meaning the coding agents, MCP servers, and skills developers are actually using.

• Third, wrap governance controls around all of it so security teams can set policy and see what is happening.

The platform itself functions as what Liav called a “hive mind,” a central brain for AppSec that maintains a security context model of each application, broken down into components such as APIs and data models, and runs a set of autonomous agents against it while developers keep working.

Those agents cover detection, response, bill of materials generation, triage, and remediation. On the integration side, Legit plugs into the leading AI coding tools, such as Cursor, Claude Code, Copilot, and Codex, and exposes its security context through an MCP server so that a coding agent can trigger checks, ask whether a change is safe to deploy, and get remediation guidance without a human relaying scanner results.

That agent-to-agent interface is the piece I think most teams will be building or buying within the year as we move towards a more AI-native approach to securing the SDLC.

The triage agent is where Jerry’s rain-versus-flood problem gets handled. It runs in the background against findings, weighing code context, static and runtime reachability, and EPSS, and it has the authority to demote or close low-risk items and elevate the ones that matter.

Legit’s own description is that it confirms findings, deduplicates them, and ranks them by exploitability, and the remediation agent then reads the code, plans a fix, and delivers a context-aware fix that matches your code, delivered as a pull request.

Among the more useful parts of the conversation was the discussion of autonomy. Today, the remediation agent opens the pull request, watches it, and reacts to build failures or subsequent code changes, but a human still owns the final merge.

The PR goes to the right code owner, who reviews and approves it. When I asked Liav where this goes, he projected that within a year many engineering teams will move to pipelines where agents merge code without human intervention.

I think he is right, and I think most security leaders are not ready for that transition quite yet, because it means the human-in-the-loop requirement becomes a policy setting rather than an assumption. Deciding which findings, which repositories, and which fix types an agent may merge on its own is going to be one of the more consequential AppSec decisions of the next couple of years and it will look different across organizations, business units and risk tolerances.

VibeGuard at the Endpoint

The second half of the demo is where the “left moved” argument got tangible in their product.

VibeGuard is Legit’s endpoint protection agent for developer workstations, and the current release moved it off the IDE extension model and onto the endpoint itself so it can discover and wrap whichever coding agents are running, currently Claude Code, Cursor, and Copilot.

Liav’s description in the launch was that

“Agentic security needs to happen at the developer endpoint with the goal of enhancing agents rather than blocking”

That’s the right posture to take, since as we painfully know in AppSec, anything that slows developers down gets worked around or uninstalled entirely.

Liav ran the demo live inside Claude Code. He had the agent install Lodash, and VibeGuard intercepted the request, because it proxies package manager installs (npm in this case) and evaluates the library before it lands on the machine. The point is to catch malicious dependencies and hallucinated packages at the moment an agent reaches for them, which is the exact gap the s1ngularity and Shai-Hulud incidents and the slopsquatting research point at.

Policy is granular, so an organization can choose per operation whether to block, warn, or require an approval, and the developer sees the outcome inline in the agent session rather than in a ticket a week later, once the vulnerabilities or malicious packages already enter production and later get picked up by a scanner.

Two other controls struck me as practical, the first of which addresses secrets. Developers paste API keys and tokens into agent prompts constantly, and VibeGuard intercepts that paste and instead offers a secure injection method, so the agent can use the credential without the credential living in the prompt history, the transcript, or whatever the agent decides to write to disk. This also prevents the secrets being sent externally to third-parties, such as frontier labs.

The second is command policy, where administrators can require a fingerprint verification before high-risk bash commands execute, and the example Liav used was gh repo delete, which is exactly the sort of thing an agent operating on a misunderstood instruction, or a prompt injected via a poisoned dependency, would happily run.

On the governance side, VibeGuard gives administrators a centralized view of every developer endpoint, including the ones that are not yet protected, along with event logs covering prompts, secret block attempts, and policy violations.

For anyone who has tried to answer “which of our developers are running which agents with which MCP servers,” that inventory alone is a meaningful step, and it connects back to the critical point that asset inventory remains the unsolved problem underneath all of this.

What This Asks of Security Leaders

I want to close the analysis with what I think this means for the people running AppSec programs, independent of any one vendor.

The first shift is that the agent session, rather than the PR, is the unit of work your program needs visibility into. If you cannot see what an agent installed, what it ran, and what it was given, your pipeline scanners are auditing a summary of a transaction that already happened. Endpoint visibility for developer agents is going to sit alongside EDR as a baseline control or with the innovative agent-centric purpose built security solutions, and I’d argue it belongs to AppSec rather than the endpoint team, since the policies are about code, dependencies, and secrets.

The second is that human-in-the-loop needs to be an explicit design decision. Agents are already opening pull requests for agent-written code. The decision about where a human is required, at the finding, at the fix, at the merge, or at the deploy, should be explicit and tiered by risk, and it should be revisited as your confidence in the tooling grows. Teams that never define it will default to whatever their vendor shipped, and teams that define it as “always” will get routed around by developers who want their backlog gone.

The third is that Niels’s argument about invariants matters even more as agents write more of the code. Reachability, egress control, hardened libraries the agent is told to use, and package allow-lists enforced at the workstation are the controls that hold when neither the developer nor the reviewer is a human. Guardrails at the point of creation are generally cheaper than downstream triage.

Closing Thoughts

This is far from an exhaustive discussion, but the direction is clear enough.

AI has made discovery cheap, remediation is being handed to agents next, and the code itself is increasingly written by a process no human watches. Security once again has a choice between meeting the work where it now happens or bolting controls onto a pipeline that sees a shrinking share of what matters.

It remains to be seen which direction we take as an industry, but the teams building control points at the developer endpoint and agent-to-agent interfaces into their AppSec platforms are, in my view, closer to where this is headed than the ones still tuning their pull request scanners.

Subscribe now

At the time, the clock was a single, blunt instrument built on roughly 3,500 CVE-exploit pairs, showing the median time-to-exploit collapsing from 771 days in 2018 to 4 hours in 2024, with the majority of exploited vulnerabilities in 2025 being exploited before public disclosure.

It made the compression of exploitation timelines legible to people outside of the vulnerability management trenches in a way a hundred vendor reports had failed to and as a result, it became a widely cited resource across not just cyber but others when discussing cybersecurity as well.

That said, the Zero Day Clock that exists today is a different animal.

The headline “clock” is gone, replaced by what the project now calls “a public scoreboard for vulnerability management and exploitation,” with an Observatory, an Explorer, a timeline they call “The Collapse,” a ten-point Call to Action, and a signatories list that now includes names such as Bruce Schneier, Heather Adkins, Jeff Moss, Paul Vixie, George Kurtz, and Joe Sullivan, among others, including myself, as I’m a big fan of the work Sergej Epp is doing here.

In this article, I want to walk through what changed, what the new numbers actually say, and what practitioners, CISOs, and AppSec teams should take from it, along with where AI continues to bend the curve.

So, let’s dive in.

From a Clock to an Observatory

The biggest change is philosophical rather than visual.

The original clock’s entire premise was a time-to-exploit metric. The new version explicitly refuses to publish one, and the reasoning is worth understanding, because it applies to plenty of the metrics we throw around internally too.

Below is their direct explanation, but I will break it down as well:

The project lays out three problems with time-to-exploitation as a headline number.

It ignores aging, meaning recent vulnerabilities look artificially fast because the slow ones haven’t been exploited yet. It saturates, since a metric floored at zero can’t represent further acceleration once exploitation happens on or before disclosure day, and both ends move simultaneously, so a shrinking median can’t distinguish between attackers migrating toward disclosure day and a growing long tail of old vulnerabilities being exploited years later.

To be fair, that critique cuts against the version I wrote about in March, and the project is upfront about it. The site is now built around principles it describes as:

• Neutral - No vendor, no product and no thesis that needs protecting

• Independent - Funded by nobody who appears in the data

• Long term - Built as an instrument rather than as a report

For those unfamiliar, the project grew out of the Unprompted conference in San Francisco earlier this year. However, despite that, it is framed as not being a project deliberately about AI, because an instrument build for one narrative tends to measure that narrative and little else.

I find that framing refreshing in an industry where nearly every dataset is published by someone with a product to sell. The data now comes from nine public feeds (CISA KEV, EUVD KEV, CIRCL KEV, VulnCheck KEV, Shadowserver’s honeypot network, MSRC, the CVE Program, NVD, and EPSS), and the four KEV catalogues are deliberately kept separate rather than merged, because in the project’s words the disagreement between them “is itself the finding.”

Just as useful is the list of things the project says it cannot measure, which includes how much vulnerability exists in the world, whether anybody was actually compromised, when exploitation genuinely began, the risk to your own organization, and whether a decline is good news.

If more security dashboards shipped with that disclaimer, we’d have far fewer board slides built on false precision.

What the Numbers Say

The Observatory’s opening chart tells the story in three numbers for the first half of 2026.

There were 35,853 vulnerabilities published, 484 newly named as exploited, and 133 of those were already being exploited when they went public. Through eight months of 2026, the count sits at 57,884 published CVEs and 674 KEV listings, and the project intentionally never divides one into the other, because publication counts and catalogue listings are driven by different forces.

Zoom out and the KEV trend is the one for security leaders to pay attention to. Annual KEV listings across the combined catalogues went from 48 in 2021, to 95 in 2022, 127 in 2023, 221 in 2024, 479 in 2025, and 674 in 2026 with four months still to go. Even allowing for better catalogue coverage over time, that is a curve that has roughly doubled every year or two.

The technology breakdown is where it gets practical. For 2026 year-to-date, web publishing and plugins lead with 206 exploited vulnerabilities, followed by enterprise applications at 163, network appliances at 114, developer platforms at 102, and operating systems at 58.

Browsers, OT, mobile hardware, and cloud/SaaS are all in the single or low double digits. Per the project, web publishing and plugins grew from 6.1 to 25.8 listings per month while operating systems stayed relatively flat at 6.9 to 7.3, meaning nothing moved away from the OS, everything else simply grew around it.

The newer Vulnerability Pressure Index compares the latest complete quarter against the same quarter a year earlier. For 2026Q2, vulnerability pressure reads 270% year-over-year (30k new vulnerabilities in three months versus 11k in the same quarter of 2025), scanning pressure reads 42% (212k honeypot attempts versus 500k), and zero day exploitation pressure reads 78% (93 vulnerabilities exploited on or before disclosure versus 119).

The project is careful to note that 100% isn’t “normal,” with a typical vulnerability pressure reading around 118%, and that each stream compares only against its own past.

Now, I’ll admit that two of those three readings are down on last year, and someone inclined to declare victory could do so. That said, the project’s own list of unmeasurable includes “Whether a decline is good news,” and the scanning figure in particular is qualified by sensor reporting variations. The number that hasn’t declined is the one that lands in your backlog, and it nearly tripled.

Two more findings round out the picture. On severity, the site finds that critical vulnerabilities are attacked at 269 per 10,000 versus 92 for high, so CVSS does separate risk, and yet 61% of everything actually attacked was rated below critical, simply because high-severity vulnerabilities vastly outnumber critical ones.

On age, the honeypot data shows attackers hammering vulnerabilities that are years old. The most scanned CVEs for the week of August 28 through September 3 included a 2025 GeoServer flaw and this year’s SharePoint vulnerability alongside Fortinet CVEs from 2022 and 2018, a Citrix flaw from 2019, and a PHPUnit vulnerability from 2017.

The site’s own caveat is a good one, “Empty space is not safe space,” since honeypots have observed 45% of network device KEV, 2% of OS flaws, and nothing from Apple.

The KEV Problem

All of the exploitation figures above hinge on the word “catalogued,” and that deserves scrutiny, because the catalogue most of the industry treats as ground truth is CISA’s KEV. The project’s decision to run four KEV feeds side by side rather than merging them is a quiet acknowledgment that no single catalogue is the truth, and the gap between them is bigger than most vulnerability management programs assume.

To level set, CISA KEV was built as a directive for federal civilian agencies under BOD 22-01, with an inclusion bar that requires a CVE, reliable evidence of exploitation, and clear remediation guidance. That makes it authoritative and conservative by design, and conservative is a problem when it becomes your only exploitation signal.

VulnCheck’s KEV, which is free to community members and is one of the four feeds the Zero Day Clock ingests, claims approximately 80% more CVEs exploited in the wild than any other public catalogue, with citations behind every entry. In VulnCheck’s “State of Exploitation 2026” report, my friend Patrick Garrity found 884 KEVs with first evidence of exploitation in 2025, across 518 vendors and 672 products, while CISA added 245 KEVs across 99 vendors and 146 products over the same period.

VulnCheck’s 118 first-reporting sources added evidence “more than 85 percent of the time, often predating CISA by days, months, or even years,” and 28.96% of its 2025 KEVs were exploited on or before the day their CVE was published, up from 23.6% in 2024. That last figure is the same phenomenon the Zero Day Clock’s “ZeroDay KEV” line tracks, seen from a broader catalogue.

Empirical Security’s whitepaper “How to Deal with Speed” goes further and, to me, lands the harder blow.

When pulling data for the 2025 DBIR, across roughly six years of observed history, Empirical counted 16,116 CVEs with exploitation activity. CISA KEV held 1,307 of them, Empirical’s telemetry corroborated 894, which leaves 413 KEV entries they cannot see at all and 15,222 actively exploited CVEs that never reach the catalogue.

Additionally, Empirical found that more than half of the entries on the KEV were last observed with exploitation activity over three years ago, “yet a scanner, vulnerability intelligence tool, or exposure management platform finding one of them today fires the same alarm as a flaw under attack this morning.”

Empirical’s broader point is that exploitation is a time series rather than an on/off state.

In their data, a vulnerability with exploitation activity today has a 32.3% chance of being exploited again tomorrow, a 52% chance within the next seven days, and a 65.1% chance within 30 days, and the activity clusters into persistent, frequent, occasional, and rare patterns, with persistent vulnerabilities showing activity on 95.4% of days and rare ones on 4.8%.

KEV entries skew heavily toward the persistent and frequent clusters (48% and 35%), which is another way of saying the catalogue captures the loud, long-running exploitation and misses the long tail. Their conclusion is that prioritizing by exploitation evidence rather than CVSS severity produces about a 29-fold improvement in efficiency for the same remediation effort, which pairs neatly with the Zero Day Clock’s own severity finding above.

Now, none of this means CISA KEV is useless. It is free, it is authoritative for federal agencies, and a KEV hit still deserves attention. That said, treating it as a complete or current picture of exploitation is a mistake, and the Zero Day Clock’s decision to show the catalogues disagreeing with each other is more honest than the single-catalogue view most dashboards ship with.

What It Means for CISOs

The first implication is the one I made in March and will keep making. Finding vulnerabilities has never been the hard part, the hard part is fixing them, and the data now supports that in both directions.

Disclosure volume is up roughly 270% year-over-year for the quarter, and the ceiling on remediation capacity hasn’t moved. Empirical puts it plainly, “the answer to speed is not to patch faster,” because very few organizations can win a throughput contest against a disclosure curve with no upper bound, and the alternative is sorting better before you run. If your program is still reporting mean-time-to-remediate against a 30-day SLA, you’re measuring adherence to a policy, and exposure is a different question entirely.

Or, as one would call it, you’re performing compliance/security theater, not risk management.

Closely related, if your “known exploited” signal is CISA KEV alone, you are working from a catalogue that Empirical’s telemetry suggests misses the large majority of exploited CVEs and carries entries that haven’t seen activity in years. Layering in VulnCheck KEV, EPSS, and honeypot telemetry such as Shadowserver’s is table stakes at this point, and the Zero Day Clock’s Explorer is a reasonable place to see how the catalogues disagree on your vendors.

The second implication is that the zero-day framing has become a distraction for most organizations.

Yes, 133 of the vulnerabilities named as exploited in the first half of 2026 were already being exploited when published, and that matters for the vendors and the handful of organizations targeted first. For everyone else, the week’s scanning chart says the attackers’ bread and butter is a Fortinet CVE from 2018 and a PHPUnit bug from 2017.

The Collapse timeline cites Shadowserver data showing 68% of attacked known vulnerabilities in a recent sample were published before 2024, with a single 2018 Fortinet CVE drawing 56,864 attacks in one week. The N-hour exploitation window and the N-year backlog are the same problem viewed from two ends, and boards tend to hear only about the first one.

Third, the technology breakdown should reshape where you spend. Network appliances, enterprise applications, and web platforms are where the KEV listings concentrate. If your vulnerability management program is still weighted toward endpoint OS patching because that’s where the tooling is mature, the exploitation data is telling you the attackers went elsewhere.

Finally, the project’s Call to Action is aimed at the structural level, with demands for vendor liability, security by default in platforms, memory-safe languages for new critical infrastructure code, open-sourced defensive AI tooling, and regulation redesigned for machine-speed defense, to name a few. It explicitly lays out 10 items in the Call to Action:

• Hold the Makers Accountable

• Build Security into the Platform

• Stop Patching, Start Rebuilding

• Eliminate the Root Cause

• Open-Source the Defense

• Regulation for Machine Speed

• Bridge the Gap Between Hackers and Policy

• Zero Trust, Everywhere

• Treat Cyber as Statecraft

• Fund the Defense

I’ve argued before that voluntary pledges won’t move vendors, and I still believe that. CISOs won’t fix vendor liability on their own, but they can start pricing exploitation history into procurement, and the site’s Explorer view, filterable by vendor and year, makes that fairly easy to do, but it’s up to us as a community to actually make use of it.

What It Means for AppSec Teams

For AppSec, the most relevant number is the developer platforms category, which is fourth on the exploitation list at 102 KEV listings for 2026 year-to-date.

That bucket covers the build systems, frameworks, and tooling we rely on to produce software, and it is being exploited at nearly twice the rate of operating systems. The web publishing and plugins category leading the list at 206 is a reminder that the long tail of CMS plugins and web frameworks remains the softest target on the internet, and much of that is code your organization runs but never wrote.

The severity finding matters here too. AppSec programs love CVSS thresholds because they are simple to encode in a policy, and the data says critical vulnerabilities really are exploited at a higher rate. It also says that most of what gets exploited is rated high or below.

A gate that only blocks criticals is letting through the majority of what attackers actually use, and a gate that blocks everything above medium is how you end up as the “office of no”.

The way out, as I’ve written about repeatedly, is context, which means reachability, exploitation intelligence from sources richer than CISA KEV alone, and runtime exposure, rather than a severity score in isolation. Empirical’s 29-fold efficiency figure for exploitation-based prioritization over CVSS is the kind of number that should end the CVSS threshold debate with engineering leadership.

There’s also a disclosure angle for AppSec teams that ship software. Per the project’s zero-day definition, 88% of vulnerabilities with a KEV listing on or before publication had a patch available on or before disclosure where vendor dates exist. That’s coordinated disclosure working as designed, and it still leaves defenders with no advance warning, because the attacker’s timeline now starts at the patch, and the data below suggests that timeline is measured in hours.

AI’s Continued Impact

The Collapse timeline is where the AI thread runs, and it has been extended since March.

The entries I covered then are still there, from Daniel Kang’s work showing GPT-4 exploiting known flaws with an 87% success rate at $8.80 per exploit, to Sean Heelan generating 40 working exploits for a single flaw at a cost of $50, to Dinkin and Kraft finding 100+ exploitable kernel driver vulnerabilities for $600 total. Heelan’s line remains one of the better summaries of where this goes:

“The limiting factor on a state’s ability to develop exploits will be token throughput, not hacker count.”

The newer entries push the timeline from N-day to what Anthropic’s June research on measuring LLMs’ impact on N-day exploits calls N-hour. In that work, Mythos Preview had its first working exploit against a Firefox patch within an hour of Mozilla issuing it and ultimately produced eight different exploits in roughly 12 hours, while against Windows kernel bugs its first proof of concept arrived in 31 minutes and all 18 arrived within six hours, at a total cost of $15,700 in API credits, or roughly $2,000 per privilege escalation.

The comparison the paper draws is the one most relevant for a CISO, since it typically takes seven days for a patch to reach 90% of enrolled Windows devices and day 11 before a forced reboot, meaning the model “would have finished creating all eight full chain exploits before any of the Windows devices had received the patch.” As the authors put it, “N-hour is closer to the reality we now operate in.” You can see in the Zero Day Clock Observatory,0 where vulnerability exposure is growing as well.

The timeline also cites Anthropic’s disclosure that Claude found over 500 high-severity vulnerabilities in open source software, with a warning that 90-day disclosure windows may not survive AI-discovered bug volume, and Schneier, Adkins, and Evron’s October 2025 essay gets the closing word:

“The attackers’ AI singularity has arrived. Ours has not yet begun.”

I would argue that is timely, looking at a similar effort as Anthropic’s, in competitor OpenAI’s effort “Patch the Planet” in tandem with Trail of Bits, you can see 66% of issues found are still awaiting patches.

This highlights the bottleneck isn’t finding issues, but the subsequent validation, patch development, institutional triage and ultimately the patches being merged upstream. You can see above in Patch the Planet, only 13% of issues so far have actually had a patch merged upstream.

Now, don’t get me wrong, I remain bullish on AI for defense, and the Call to Action’s demand to open source defensive AI tooling is one I endorse, hence being a signed supporter. That said, Sergej’s Verifier’s Law, which he and I discussed at length on the podcast, explains why offense is compounding faster.

An exploit either works or it doesn’t, which is a cheap, deterministic verifier, while defense gets ambiguous, delayed feedback and has to be right everywhere. Until defenders get feedback loops as tight as a working exploit, the asymmetry persists regardless of how much AI we buy.

Closing Thoughts

It is of course debatable whether the world needed another vulnerability dashboard, and the earlier version of the clock was frankly easier to put in front of a board than an observatory with nine data feeds and a page explaining what it can’t measure.

That said, the rebuilt Zero Day Clock is among the more honest instruments I’ve seen in this space, precisely because it gave up its own headline metric when the data couldn’t support it.

The picture it paints is consistent with everything else we’ve seen this year.

Disclosure volume is roughly tripling, exploitation listings are compounding, attackers are living off old edge-device bugs while AI compresses the window on new ones to hours, and remediation capacity hasn’t budged.

This is both a measurement challenge and structural one, with various systemic, organizational and technical issues at play.

All that aside, this is an excellent data rich resource to discuss the state of vulnerabilities and exploitation with security leaders and practitioners alike.

Subscribe now

Welcome to issue #112 of the Resilient Cyber Newsletter.

It’s been another action packed week, with an industry-wide call from frontier labs, CSP’s and vendors for collective action on Cyber, continued M&A activity, a slew of fundraising, continued drama with AI incidents and the industry still grappling with the surge of CVE’s and remediation bottlenecks.

I try and unpack it all this week concisely, so sit back, grab a coffee and let’s get moving before everyone heads off to enjoy the long weekend, at least here in the U.S.

Cyber Leadership & Market Dynamics

A Call for Collective Action on Cyber Defense

OpenAI published a letter with 100+ cosigners across the industry with a core claim that:

”In the coming months, AI-enabled cyber attacks will become far more widespread and sophisticated as models around the world become increasingly capable”.

It goes on to make various calls to actions such as:

• Recognizing the status quo of security won’t be enough

• Empower more defenders with cyber-capable AI

• Mobilize a collective response

• Make cyber defense a leadership priority

Now, where I struggle with this is, I agree with everything their saying.. the problem however is that we cannot “will” ourselves into a state of security. It requires either sufficient market or regulatory forces and right now we largely lack both, which is why many consider cyber to be a market failure.

There is also the fact that the labs, CSPs and many of the signatories are security vendors, so they are calling on the market and their customers to spend more on the very things they sell, which can be seen as problematic.

All that said, I unfortunately don’t anticipate much changing until organizations feel real market consequences for incidents, shipping insecure products, or changes in the regulatory landscape which force them to prioritize and invest in security with more rigor.

AI Is Moving Cyberattacks to Machine Speed

In a bit of a dim warning, former NSA leader Rob Joyce recently had an interview where he discussed the fact that exploitation timelines are collapsing, and attacks are moving at machine speed.

Rob discusses how years of technical debt are now going to be found and exploited by AI, and how critically important the fundamentals remain.

Palo Alto Acquires Console

PANW continues its acquisition run, this time acquiring a company named Console. This one is less about securing AI, and instead focused on leveraging AI for security, as the company provides capabilities for users to express oiperational goals and the software handle the complexity of helping them achieve it.

This quote from Nikesh Arora sums up the goal:

"Security operations can no longer be about managing dashboards and queuing tickets just to help humans work faster. By bringing Console into Palo Alto Networks, our customers can have a direct conversation with data and build agentic workflows in natural language that helps alert and remediate issues automatically. This is the shift to software-as-an-agent, giving our platform the arms and legs to deliver autonomous security outcomes across the entire enterprise."

If you’re looking for deeper insights into how the industries largest vendor sees the landscape, as well as their M&A ambitions, I found this recent conversation with to be perfect. I had a chance to listen to it earlier this week.

AIR Security Emerges From Stealth With $50M

The team at AIR Security recently emerged from stealth with $50M, focused on building a “firewall” for agents. I’m very familiar with this team, and had them on the show in the past to discuss an early effort of theirs Mother of all KEV’s (MOAK), which automated developing exploits for KEV’s.

The team has continued innovating and now has the capital and backing of amazing investors, such as Sequoia. They played a role in the new OWASP Agentic Skills Top 10, and are focusing their attention on creating a firewall for AI Agents.

HiddenLayer Raises $100M Series B

One of the more longstanding AI security players in the ecosystem who has been around for a bit, HiddenLayer, recently announced a $100M Series B, being led by Delta-v Capital, with involvement from others such as MSFT’s M12 venture fund, and Booz Allen Hamilton.

I’m employed at a competitor in this category so I watch it closely, but I’ve been following their team for years, prior to the role I am in as well. It is interesting to see M12 be among the investors, given they also invest in competitors to Hidden Layer. The involvement of BAH, and my public sector background also give the signal that the team has likely has strong public sector traction as well, which is supported in their announcement where they cite deployments across U.S. defense and IC environments. They also cite 10x ARR growth, 50+ new platform customers etc.

There’s some great security leaders on the team of course, aside from the founders, such as longtime industry leader Malcom Harkins. While I compete in the category in my day job, I know it is a highly competitive and fast moving one, and there’s several great teams in the ecosystem.

Upwind Raises $300M, Doubling Valuation to $3.8 Billion in Five Months

In what feels like groundhog day, we have another large fundraising event for Upwind, who has established itself as a leader in the cloud security and runtime categories. This comes 8 months after their prior $250M Series B(hence my groundhog day comment).

The company seems to be capitalizing on their momentum, competing strongly in the CNAPP space, and also expanding to cover specific areas of AI security, as everyone scrambles to cover the risks of AI.

Huskey’s Announces $27M Series A

The team at Huskey’s also announced their $27M Series A, just 5 months after coming out of stealth with participation from teams such a Blackstone, Merlin Ventures, Zscaler, Okta and others.

They aim their focus at “Network Edge Security Management (NESM), focusing on making network edge security stacks work for, not against customers.

AI

Conversation with a OpenAI/Hugging Face Incident Investigator

One thing I found really interesting this week was the conversation with around the OpenAI/Hugging Face incident.

For those unfamiliar, Ajeya is one of the independent investigators from METR involved in the analysis of the incident. In the conversation with Dwarkesh, they go really deep in particular in some of the multi-agent conversations, behaviors and more, which felt like diving into the psychology of multi-agent systems, of “civilizations” as Dwarkesh himself framed them in his blog “The Rise of Fall of Agent Civilizations”, which is worth a read.

Ajeya also had a good blog on what surprised her from the incident, including the scale of the number of agents that participated in this incident and activity and how they collaborated.

Valid Questions About the Independent Review of the OpenAI/Hugging Face Incident

Now, not to throw shade at the organizations involved in the review of the incident, but Zack Korman shared an excellent video critiquing aspects of this review. He points out how the organizations involved in the review largely lack any cybersecurity expertise or background, and by their own admission, the review could of been handled better in several ways.

He goes on to rightfully call out the Cyber community as well, as we seem to be sitting back and letting the frontier labs, and others outside of Cyber lead the charge as it relates to the cyber risks of AI. Zack says we need to step it up as a community, and I’m inclined to agree with him.

Anthropic’s Plans to Improve Alignment and Security

Sticking with the theme of incidents and “breakouts and such, Anthropic published a blog this week discussing how they plan to improve alignment and security efforts.

Agent "breakouts", unauthorized actions and misalignment has been dominating the AI and security conversation for weeks.

From the initial OpenAI and Hugging Face incident, to others such as Anthropic, AI Security Institute (AISI), Meta and even open weight labs coming forward disclosing incidents of agent attacks and unauthorized actions.

That's why this blog from Anthropic is super timely. They walk through what they learned from their three incidents of Claude gaining unauthorized access to real systems and infrastructure and what they plan to improve moving forward.

This includes efforts such as securing evaluation and training environments, utilizing classifiers to identify unauthorized activities, the use of automated monitors, improved cyber sandboxes and general environmental hardening.

It also lays out recommendations for external partners using models with reduced cyber safeguards that include sandbox and network isolation, pre-engagement validation, explicit scope setting and real-time monitoring.

One thing I particularly appreciate is they are honest about where gaps remain, in terms of models cheating in training environments and objectives, continued alignment challenges and more.

Most notably for me is their hardening security practices and recommendations highlight a list of things that nearly every IT environment I've worked in across 20~ years is still rife with, and inevitably will be found by AI soon.

This includes accounts with standing access to sensitive data, lack of outbound access control, identify rigor, legacy infra configs and services, and gaps in observability.

It's going to be an interesting couple of years ahead. Give the Anthropic blog a read yourself.

CrowdStrike SafeMind

AI and Cyber have been converging for quite sometime now, in good and bad ways. While a lot of the attention tends to be on the negative, incidents, exploitation and so on, there are a lot of promising aspects as well, and in my opinion, leveraging AI is the only way cyber has any chance of keeping up with the threat landscape.

This week we saw an innovative and interesting announcement from one of the industries largest teams, CrowdStrike, who announced their “Cyber Superintelligence Lab”, and first breakthrough “SafeMind”, in partnership with NVIDIA.

It is described as a family of purpose-built security models and agentic harnesses for autonomous offense and defense together, to both identify and resolve vulnerabilities, as depicted below:

Their blog has an interesting video and frames using the Red and Blue models together (or not) to identify attack paths and vulnerabilities and mitigate them.

The Security Autonomy Matrix: Deciding AI Authority

Many organizations are wrestling with the autonomy that agents introduce. That’s why this Security Autonomy Matrix from Lenny Zeltser is a timely resource, helping organizations walk through how much authority AI agents get with different columns and rows for considerations such as workflows, triggers, autonomy levels per action class, accountable person, gate, residual risk and safeguards as well as reevluation triggers and expirations.

Agent Hooks: An open framework-neutral AI governance contract

Hooks have quickly become one of the de facto runtime enforcement mechanisms for controlling actions agents take. They’ve seen adoption across endpoint coding agents, and custom/homegrown agents alike.

That said, there are a lot of different frameworks, SDK’s and more that must be considered across frameworks and platforms. Microsoft. published an open, framework-neutral governance contract with conformance testing on both sides.

AppSec

AppSec in the Age of Agents

AppSec was already losing ground prior to AI coding agents hitting the scene. Trends such as "Shift Left" and DevSecOps fell short, producing noise for developers and reinforcing the very silos between teams they were meant to break down.

Now, FIRST projects we could see ~66,000+ CVE's in 2026, yet most organizations can only remediate about 10% of their findings in a month, despite Verizon's DBIR showing exploitation as the initial access vector in breaches. Meanwhile, AI is industrializing the discovery of vulnerabilities and now we're seeing examples of agentic workflows and autonomous exploitation of known exploited vulnerabilities.

Better prioritization alone isn't going to close the gap, and a decade of refining how we rank findings hasn't stopped vulnerability backlogs from growing. Cybersecurity and Infrastructure Security Agency's published their 2024-2025 Vulnerability Review report, and it showed 41.5% of KEV's map to MITRE "stubborn weaknesses", with 18 CWE's appearing in the CWE Top 25 every year from 2019-2025... the same classes of flaws keep shipping year after year.

This is why root cause research from Jeevan Jutla and Gecko Security, a Resilient Cyber partner caught my attention. They traced disclosed findings, such as in n8n, back to their origins and found 569 findings came from just 105 distinct root causes, with 67% of them being repeats of earlier issues, same with other platforms such as GitLab, where 58% were repeats.

What looks like a runaway backlog is often a short list of root causes that just get ignored, when we could fix the class once, and it stays fixed. I chat with a lot of teams in AppSec, and often hear about prioritization, intelligence, dashboards, ticketing and more, but don't often hear about addressing root causes, despite it being advocated for by leaders such as CISA, Bob Lord and others for years.

This is one of the key shifts I think AppSec needs to make in the age of agents. I dove into the data, AI discovery and exploitation trends and what eliminating vulnerability classes looks like in practice in my latest blog.

Why Finding Bugs Still Isn’t Commoditized

In this episode, I sit down with Ondrej Vlcek, Founder and CEO at AISLE and the former CEO of Avast, to discuss where AI vulnerability discovery actually stands, including what got commoditized, what did not, and why shipping a fix a maintainer will accept is a very different problem from finding the bug in the first place.

Ondrej spent roughly 30 years in this industry, starting as employee number six or seven at Avast doing kernel-mode driver work on Windows 95, and eventually taking the company public and selling it to NortonLifeLock in a nearly $9 billion transaction. He co-founded AISLE in the fall of 2024, and his team has since disclosed more than 350 CVEs across projects like OpenSSL and curl.

I have been beating the remediation drum for a while now, so this was a conversation I wanted to have with someone who is actually shipping accepted patches upstream rather than just posting finding counts.

Runaway CVE Rates

It should come as no surprise that we have more CVE’s in 2026 than in 2025, but how rapidly it is growing is still something to track and honestly be concerned with in some ways.

Jerry Gamblin recently took to LinkedIn to show how CVE’s YTD are up +86.5% YoY at 396 a day, compared to 238 a day the year prior. This is not even accounting for the fact that NVD isn’t enriching the full breadth of CVE’s and some may not be showing up in the NVD, as it made adjustments to try and manage the load it is seeing, much of which is being driven by the industrialization of AI discovering vulnerabilities.

There’s nuance in the numbers of course, and understanding what to prioritize and remediate is still critical and is a topic I dug into with Jerry himself recently on the show.

Running a Software Factory Efficiently at Uber-Scale

There’s been a rise in discussions about “Software Factories”, but it has often been hypothetical, or small startups. What does it look like for a major tech company and enterprise?

Well, Uber provided that answer with an excellent blog recently, showing how agentic tooling grew 7x, and weekly agent requests grew 9.4x while total spend “relatively stabilized”.

This piece goes deep into Uber’s software factory, covering models, MCP, FinOps and more. While it isn’t security focused, I do think this is a development pattern we should expect to see grew with AI coding agents, and security inevitably will want to be a key part of the conversation.

Empirical Observations: How to Deal with Speed

Everyone (including myself) have been discussing the so called “Vulnpocalypse” and industrialization of vulnerability discovery, runaway CVE volume, need for prioritization and so on.

This paper from Empirical provides some great insights on how to actually deal with the problem. From FIRST reporting a projects 66,000+ CVE’s in 2026, DBIR showing vuln exploitation as a leading initial attack vector at 31% and more, the problem has been top of mind for many.

Empirical also highlights just how woefully insufficient the CISA KEV is when it comes to identifying vulnerabilities with known exploitation, as shown below:

They make recommendations such as replacing uniform SLA’s with risk-stratified cadences, tracking days since last exploitation rather than a permanent “known exploited” flag, and accounting for local exposure and escalating on quiet-to-active transitions intra-day.

The Real Reasons Vuln Remediation is Slow and How AI Changes the Economics of Fixing Things

Many of us have been arguing that finding vulnerabilities has never been the bottleneck, fixing them is, and now AI is massively front loading the finding, while fixing stays problematic.

This piece from longtime CISO and security leader Tim Rains highlights the reasons remediation is slow, such as the friction of safely changing production software, differences in bought vs. built software, incomplete inventories, unclear ownership, and fragmented authority among many other issues.

This is a comprehensive real-world informed perspective of the problems of reducing risk in complex enterprise environments and now marketing noise from a vendor.

Rival Buyout Aids Customer After Firm Shutters

Last week I had shared how the hardened container and supply chain vendor Minimus had decided to shutdown and return funding to investors after struggling to grow and scale.

In a bit of a surprise move, their competitor Echo stepped into the fold, announcing they were acquiring Minimus and providing an option to customers of Minimus who would have had to switch to an alternative, such as the industry leader in Chainguard.

I had a chance to provide some commentary to TechTarget on this one.

Closing Thoughts

It’s another week that sometimes feels like a month in the AI era. From collective calls for cyber defense in the face of AI-driven risks and threats, continues fundraising as teams tackle emerging and innovative solutions, and the industry grappling with incidents tied to agents and AI.

That said, the work rolls on, and so do we!

Stay Resilient

Subscribe now

If we’re being honest, AppSec was already struggling to keep pace in the pre-AI era, with efforts such as “Shift Left” and DevSecOps largely falling short, producing noise for developers and bolstering the very silos between teams they meant to break down.

That said, the same capabilities driving the AI velocity are also industrializing vulnerability discovery, compressing exploitation timelines, and steadily marching toward autonomous exploitation, which means the gap between how fast software changes and how fast we secure it is widening in both directions at once.

In this article, I will walk through how AppSec and vulnerability management are evolving in the age of AI and agents, from growing vulnerability backlogs and exploitation’s rise as a leading attack vector to the industrialization of vulnerability discovery and what it demands of modern AppSec programs.

I will also take a look at how Gecko Security, a Resilient Cyber partner and prior guest on the show, is putting one of the more promising answers into practice, eliminating entire classes of vulnerabilities rather than playing whack-a-mole with individual findings.

So with all of that said, let’s begin to dive in.

Drowning in Backlogs

To level set, the vulnerability landscape was already straining defenders before AI entered the picture. FIRST’s vulnerability forecast projects roughly 59,000 new CVEs for 2026, the first year we will cross 50,000 published CVEs annually, while NIST moved approximately 29,000 backlogged CVEs into a “Not Scheduled” category, effectively conceding that the enrichment pipeline the entire ecosystem depends on cannot keep pace.

Now, as I argued in Why 70,000 CVE’s is Less Scary Than It Sounds in my discussion with FIRST’s Jerry Gamblin, raw CVE counts have always been a poor proxy for actual risk, given that only a small fraction of published vulnerabilities are ever exploited in the wild.

The problem is that organizational vulnerability backlogs do not care about that nuance. Large enterprises are sitting on backlogs in the hundreds of thousands of findings while remediating roughly 10% of them in a given month, and the inputs to those backlogs are accelerating, with GitHub hitting 1 billion commits in 2025 and pacing toward 14 billion in 2026, driven overwhelmingly by AI coding agents.

More code means more vulnerabilities, more findings, and more debt for AppSec teams that were already underwater.

The Exploitation Era

While the backlogs grow, attackers have gotten far more efficient at capitalizing on them. As I covered in The DBIR’s Exploitation Era, Verizon’s DBIR shows exploitation of vulnerabilities has become the leading initial access vector in breaches, nearly doubling the share held by phishing, a notable inversion of the attack hierarchy most defenders internalized over the past decade.

Meanwhile, only 26% of critical Known Exploited Vulnerabilities (KEVs) were fully remediated in 2025, down from 38% the year prior, with organizations taking a median of 43 days to remediate edge device vulnerabilities.

Time-to-exploit trends make those remediation timelines look even worse. As I laid out in The AI Cyber Capability Curve, the median time from disclosure to first observed exploitation has collapsed from 771 days in 2018 to 84 days in 2021 to roughly 6 days in 2023, and in 2026, 67.2% of exploited CVEs are zero-days, weaponized before or on the day of disclosure, up from 16.1% in 2018.

Attackers measure time-to-exploit in hours while defenders still measure remediation in weeks and months, that’s a fundamental mismatch and it isn’t in our favor.

CISA has taken notice. Its Vulnerability Review opens by pointing out that most compromises have not relied on advanced techniques but instead:

“Exploited simple, known software vulnerabilities that remain widespread and persistent in publicly exposed assets,” and that “Increasingly, cyber threat actors are using artificial intelligence (AI) to automate all the steps necessary to exploit these vulnerabilities.”

In fact, CISA explicitly states it is publishing the review “to establish a baseline of the vulnerability landscape prior to widespread AI-enabled vulnerability discovery.” When the nation’s cyber defense agency is planting a flag to measure the before-and-after of AI-enabled vulnerability discovery, that tells you something about where this is headed and it isn’t pretty.

Industrializing Discovery, Automating Exploitation

The direction is already visible in the research. Vulnerability discovery has been industrialized, and exploitation is being automated right behind it, as the next shoe to drop.

On the discovery side, frontier labs and researchers keep demonstrating capabilities that were considered aspirational just a couple of years ago. Anthropic has discovered 500+ high-severity zero-day vulnerabilities across open source codebases, including 22 Firefox vulnerabilities in a two-week span. Their Glasswing update showed that they had discovered 23,000+ vulnerabilities as of May.

DARPA’s AI Cyber Challenge drove the cost of AI-driven vulnerability discovery down to $152 per vulnerability across 54 million lines of code. This was further corroborated by the UK AI Security Institute’s evaluations, where frontier models completed expert-level offensive cyber tasks at rates that climb with every model generation, including multi-stage corporate network attack chains that take human experts roughly 20 hours.

The exploitation side is following the same curve. The researchers behind the MOAK agentic exploit workflow demonstrated autonomous exploitation of 174 of 178 known exploited vulnerabilities in testing, including going from a public React vulnerability to a working shell in 21 minutes with no human intervention.

Researcher Sean Heelan showed AI agents generating 40+ working exploits for a single flaw at a cost of around $50, while a swarm-based research effort surfaced 100+ exploitable Windows kernel driver vulnerabilities across AMD, Intel, NVIDIA, Dell, Lenovo, and IBM in 30 days for $600 in total compute, roughly $4 per bug.

The strain is even showing up in the disclosure ecosystem itself, with HackerOne’s Internet Bug Bounty pausing submissions in March 2026 as valid AI-generated vulnerability reports climbed 210%.

I have described this asymmetry before, and I will repeat it here because it captures the structural problem. Attackers need an API key and an afternoon, while defenders need a quarter and a steering committee.

Fully autonomous exploitation at scale is not quite here yet, but every data point above suggests we are approaching it, and the organizations planning for it now will be in a fundamentally different position than those waiting for proof.

Context Is the Scarce Resource

All of this has real implications for how AppSec and vulnerability management programs need to operate. For one, the legacy model of dumping low-context scanner output onto development teams and calling it risk management is finished. When findings volume grows faster than remediation capacity, the only lever left is ruthless prioritization, and that requires context that most AppSec tooling and teams have historically failed to provide.

CISA’s Vulnerability Review is blunt on this point, noting that:

CVSS scores “reflect theoretical severity, not real-world impact” and that “AI-enabled vulnerability discovery is rapidly increasing the volume of disclosed vulnerabilities, requiring ruthless patching prioritization.”

CISA’s prioritization guidance now hinges on four variables:

That is the same direction modern AppSec needs to move, leading with known exploitation, exploitability, reachability, and business context rather than raw severity scores.

A critical-severity finding in an internal tool with no path to sensitive data is not the same as a medium-severity finding sitting on an internet-facing asset with automated exploit tooling in the wild, and treating them the same is how teams end up drowning in backlogs while the vulnerabilities that matter sit unpatched.

This is a theme I have been discussing for years. The difference now is that AI has raised the stakes on both sides of the equation, and the teams that leverage AI and agents to bring exploitability and business context to their findings will fair far better, especially if they look to try and root out the causes of vulnerabilities as well, which takes me to my next point.

Eliminating Entire Classes of Vulnerabilities

That brings me to the second half of this discussion, which is what it looks like when someone actually builds for this reality.

Gecko Security is an AI AppSec company I recently hosted on the Resilient Cyber podcast in an episode titled Building an AI AppSec Engineer.

A couple of moments from that conversation have stuck with me since. Ryan called MTTR “a fake metric that makes teams look good,” arguing that recurrence rate is the metric AppSec should actually care about, since MTTR incentivizes closing repeated instances of the same flaw rather than addressing the root cause, and as I often say in cyber (and general), incentives drive behavior.

JJ made the point that as AI automates more of the discovery and triage work, “the scarce thing left is the judgment.”

Both of those observations converge on an idea that CISA has been advocating for years through Secure-by-Design, which urges software producers to “eliminate common vulnerability classes and publish roadmaps for the rest.”

It shows up again in CISA’s Secure-by-Demand guidance, where one of the key questions buyers are told to ask vendors is which vulnerability classes the producer has already eliminated and what the roadmap is for the rest, and in the Vulnerability Review’s discussion of AI-powered threats, CISA’s prescription for defenders explicitly includes “elimination of entire vulnerability classes” alongside MFA and engineering resilience into AI-integrated systems.

The Vulnerability Review data shows why this matters.

Across FY2024 and FY2025, 41.5% of KEVs map to what MITRE calls “stubborn weaknesses,” the 18 CWEs that appeared in the CWE Top 25 every single year from 2019 to 2025.

Per CISA, three of today’s top 10 CWEs would have been considered “unforgivable” by the standards MITRE published nearly two decades ago, and their persistence illustrates that “the problem is not technical complexity, it is organizational culture, developer workflows, and systemic gaps in Secure-by-Design adoption.” In other words, the industry keeps losing to the same classes of flaws, over and over, at scale, rather than to novel attacks.

Gecko’s own research, presented at Black Hat 2026 and detailed in their executive brief on eliminating vulnerability classes, quantifies just how much of the backlog problem is really a root cause problem.

By tracing every publicly disclosed vulnerability in n8n and GitLab back to its fixing commit, Gecko found that 569 disclosed findings traced back to just 105 distinct root causes, with 1,117 duplicate backports along the way.

For n8n, 67% of public disclosures were repeats of previously disclosed issues, and for GitLab the figure was 58%, with the repeats costing roughly $44,000 in bounties for n8n and over $1 million for GitLab. The longest-lived vulnerability class persisted 728 days before comprehensive remediation. As the research puts it:

“What looks like an unmanageable backlog is a short list of root causes. Fix the class once, at a shared point, and it stays fixed.”

That framing resonates with me because it converts an intractable-sounding problem, hundreds of thousands of findings and growing, into a tractable one, a bounded list of systemic flaws that can actually be burned down, if we intentionally focused on doing so.

It is also exactly the kind of work AI and agents are suited for, reasoning across an entire codebase to identify the shared root cause behind dozens of surface-level findings, something no human AppSec team has the cycles to do at scale.

The Cal.com Example

For a concrete look at what this means in practice, Gecko’s case study with Cal.com is worth a read.

Cal.com is a scheduling platform used by over 1 million people, with customers including Vercel, Coinbase, and Ramp, and it spent five years as an open source project before going closed source in April 2026.

Their situation reads like a compressed version of everything discussed above. After adopting AI coding tools, pull request volume jumped from roughly 40 to 100 per day, supported by a security team of two engineers covering 25 engineers, something many of us in AppSec can likely relate to.

They were running multiple scanners, both legacy and AI-native, which generated duplicated findings, inconsistent severity ratings, and a steady stream of false positives. Cal.com CEO Bailey Pumfleet captured the consistency problem well, noting that “If you ask two different AI agents to review the same PR, they’re going to pull out very different results.”, which isn’t surprising given the non-deterministic nature of AI.

Consolidating on Gecko gave them a single source of truth for pull request security decisions, with context-aware findings validated by proof-of-concept exploits, an understanding of production exploitability and data sensitivity, and findings automatically routed to code owners, with every PR scanned before human review.

Keith Williams, Cal.com’s Head of Engineering, described the outcome as “One tool that gives us great results from a full scanning perspective, and every single pull request that goes in, we know is protected.” His broader observation applies to every team shipping AI-assisted code right now, “This is the new reality. Especially with Mythos, you’re always going to find new stuff.”

His quote doesn’t even account for the fact that Mythos level capabilities are now becoming commoditized, with open weight models quickly catching up to the frontier and available to malicious actors everywhere.

Notice what that approach operationalizes:

• Exploit validation instead of theoretical severity

• Production context instead of isolated code findings

• The elimination of recurring classes instead of an ever-growing queue of one-off tickets.

Those are precisely the properties I have argued modern vulnerability management needs, and precisely what CISA is pushing the ecosystem toward.

Closing Thoughts

This is far from an exhaustive discussion of how AI and agents are reshaping AppSec, and much of the trajectory remains to be seen, particularly around how quickly autonomous exploitation matures from research demonstrations into commodity tradecraft.

That said, the direction of travel is clear. Vulnerability discovery has been industrialized, exploitation timelines have collapsed, backlogs are compounding, and the traditional AppSec model of low-context findings and human-speed triage cannot survive contact with machine-speed offense.

Security has historically been a laggard when it comes to adopting transformative technology, hand-wringing over risks while the business races ahead.

AI and agents offer us a rare chance to break that pattern, using the same capabilities that are empowering attackers to finally address root causes, eliminate entire classes of vulnerabilities, and focus our scarce human judgment on the decisions that actually matter.

Will we take it, or will we spend the next decade remediating the same stubborn weaknesses we have been remediating for the last two?

Subscribe now

Ondrej spent roughly 30 years in this industry, starting as employee number six or seven at Avast doing kernel-mode driver work on Windows 95, and eventually taking the company public and selling it to NortonLifeLock in a nearly $9 billion transaction. He co-founded AISLE in the fall of 2024, and his team has since disclosed more than 350 CVEs across projects like OpenSSL and curl.

I have been beating the remediation drum for a while now, so this was a conversation I wanted to have with someone who is actually shipping accepted patches upstream rather than just posting finding counts.

We chatted about:

• Going from Avast intern to CEO, and why vulnerability management became the next problem worth solving

• The jagged frontier, and why a bigger or more expensive model does not reliably mean better results

• Which bug classes genuinely got cheap to find, and which subtle ones still lead to XZ Utils and Log4j style outcomes

• Why the gray market price of vulnerabilities has gone up rather than collapsed

• Building a model-agnostic system, and the bespoke benchmarks AISLE uses to move workloads between models

• Sovereign AI, on-prem and air-gapped deployment, and why your findings are more sensitive than your source code

• Triage, reachability, and why most findings are not actually exploitable in your environment

• Patch verification in bespoke Docker environments, and mitigations for systems that cannot be redeployed

• How AISLE earned trust from curl after Daniel Stenberg shut down a seven year bug bounty

• Whether a CVE count is a vanity metric, and what makes it a real signal

• Build versus buy as the underlying model capability keeps getting cheaper

• What breaks first across maintainers, CNAs, and the CVE ecosystem

Prefer to listen?

Find the episode on Spotify and Apple Podcasts

Please be sure to leave a rating and review, as it truly helps the show!

Takeaways

Bigger models are not reliably better models

The phrase “jagged frontier” has escaped AISLE’s blog and entered the general discourse at this point, and Ondrej’s explanation of it is the most practical version I have heard. As he put it, “more expensive or bigger or more robust model doesn’t necessarily mean better results.” Large models struggle with certain vulnerability classes while smaller ones, given a harness that supplies prior knowledge of what good looks like, do better on discovery and triage.

The second half of that argument is the one buyers underweight. Cheaper and faster models mean you can run far more of them. “Because of those gains that you get in terms of speed and in terms of cost, you can run many, many more agents at the same time,” Ondrej said, describing swarms of specialized agents that chunk code and coordinate with each other. That is what people mean when they say the system beats the model, and it is why AISLE built its own benchmark to move workloads between models as new versions ship. Anyone building this internally should be asking whether they have that evaluation layer, because without it you are married to whichever model you picked last quarter.

Discovery is cheaper, but it is not solved

I pushed on whether finding bugs is now commoditized, and Ondrej’s answer used the market rather than the models. Vulnerability prices in the gray market have gone up, not down, despite all the model progress. The floor moved, so memory safety bugs and off-by-one errors are much easier and cheaper to find today. The subtle bugs that produce XZ Utils and Log4j outcomes are still hard.

This lines up with the token maxing backlash we saw earlier this year. The industry briefly confused spending more compute with getting better results, and the pricing data suggests the market never believed it.

Remediation is more than generating a patch

This was the heart of the episode for me. Ondrej broke remediation into pieces most vendors collapse into one. Triage comes first, and it matters because “the vast majority of findings may actually not be related or are not directly exploitable in your environment,” which requires data flow context rather than just function reachability. Then comes patch generation, and then the part nobody demos, which is automated verification. AISLE spins up bespoke Docker images to compile the code, run unit tests, and confirm the fix neither reintroduces the vulnerability nor breaks something else.

Then there is the category where a patch cannot be deployed at all. Cars, industrial robots, ATMs. Ondrej’s answer there was compensating controls and network level mitigations rather than pretending a code patch closes the loop. This maps almost exactly to the empirical work Keith Hoodlitt and the team at 1Password published on AI-generated patches, where fixes frequently failed, broke functionality, or introduced new vulnerabilities. Anyone selling you autonomous remediation without a verification story is selling you the easy half.

Quality is what earned curl’s trust

Daniel Stenberg shut down a seven year bug bounty over what he called death by a thousand slops, and a few months later curl was running AISLE internally. Ondrej’s explanation was not clever technology. It was standards. “We would be professionally ashamed to actually send reports that we don’t stand behind,” he said, describing reports that arrive pre-triaged with a working proof of vulnerability, repro steps, and a pre-tested proposed fix. Roughly 15 to 20 reports went into curl, all of them high quality.

That is the whole lesson for anyone pointing AI at open source right now. Maintainers are unpaid volunteers, and the currency you are spending is their attention. Ondrej called it white glove service for maintainers, and it is the reason a vocal skeptic reversed his position.

Ondrej is more optimistic than I expected on what breaks next

I asked what cracks first over the next 18 months, whether it is maintainer capacity or the CVE and CNA institutions. He acknowledged the pressure, citing roughly 47,000 CVEs in 2025 and a single recent month approaching 10,000, and he was direct that “these maintainers have no chance whatsoever to withstand the incoming load of new vulnerabilities that is just starting to come.” But he declined to predict a break, pointing instead at the wave of vendors and labs standing up open source support programs over the last several months. AISLE itself became a CNA under the ENISA route only a few weeks ago.

His read on the moment was my favorite line of the conversation. “If 2025 was mostly about naysayers, 2026 is people are realizing, my gosh, this actually works.” His advice to AppSec leaders followed from that, which was to stop leaning on legacy pattern matching tools when adversaries have unrestricted access to both frontier and open weight models, and to spend real time experimenting rather than waiting for the category to settle.

Thanks to Ondrej for coming on. Keep an eye on AISLE’s research at aisle.com/blog, since they are publishing some of the more useful empirical work on AI-driven vulnerability discovery right now.

Subscribe now

Cloud got CSPM, containers got runtime security, SaaS got SSPM, and AI is now working through its own alphabet soup. Some of that is warranted, given how different these architectures are from what came before.

That said, when you strip the AI security conversation down to what is actually going wrong inside enterprises today, most of it is an old problem wearing a new outfit. Sensitive data going somewhere it should not, into systems nobody inventoried, through accounts nobody manages, leaving behind no record anyone can query afterward.

We have written the acceptable use policies, stood up the AI committees, and run the prompt injection tabletops, and nearly all of it rests on an assumption that does not survive contact with a real environment, which is that we often can’t see what our AI systems are actually doing.

In this article I want to walk through the problem space the way practitioners are running into it, starting with why data became the attack surface, then the visibility gap sitting underneath most AI governance programs, and finally what AI is doing to detection engineering.

From there I will use Cribl, a Resilient Cyber partner whose team walked me through their platform and their AI security approach across two conversations this summer, as an example of how one vendor is coming at it.

The Data Was Always the Point

To level set on how fast this moved, Verizon’s 2026 DBIR has a Shadow AI section drawn from its data loss prevention telemetry, and it found that 45% of employees are now considered regular users of AI on their corporate devices, authorized or not, up from 15% the year before, which is a tripling in twelve months.

67% of users are reaching AI services through non-corporate accounts on corporate hardware, which Verizon notes is actually a slight decrease from the prior year, while Shadow AI has climbed to the third most common non-malicious insider action in that dataset, a fourfold increase in percentage terms. What is leaving matters as much as how much of it, and Verizon found source code to be the most common data type going into external models.

For those who prefer breach outcomes to policy violations, IBM’s Cost of a Data Breach Report 2026 found that incidents involving shadow AI more than doubled this year, to 43% from 20%, and cost more when they happened, at an average of $5.39 million against $4.63 million the prior year.

More than 20% of organizations reported a breach targeting AI models or applications outright. When IBM looked at how those AI systems were actually compromised, the two leading causes were compromised APIs, applications or plug-ins at 27%, and cloud misconfigurations affecting AI workloads, also at 27%.

That last finding is key, because it tells you where the risk actually lives. The AI systems getting breached are not being broken through exotic model attacks. They are falling to integrations, plumbing, and misconfigured Cloud, which is to say the same things that have been breaching everything else for fifteen years.

The governance numbers in the same report are worth highlighting as well. 68% of breached organizations had no AI governance in place to manage AI or detect shadow AI, which is worse than the 63% reported a year earlier, meaning the gap widened rather than closed during a year of exceptionally fast adoption. Among organizations that reported an AI-related breach specifically, 92% lacked proper AI access controls, and only 40% reported using access controls on AI models and data at all.

To be fair, the industry is not standing still. The World Economic Forum’s Global Cybersecurity Outlook 2026 found the share of respondents assessing the security of their AI tools nearly doubled in a year, from 37% to 64%. That is real progress but it also leaves more than a third not assessing those tools at all, which is a tough position to defend in 2026, particularly when 87% of those same respondents called AI-related vulnerabilities the fastest-growing cyber risk of the past year.

Sanctioned Is Not the Same as Instrumented

Now, the instinctive response to shadow AI is to sanction the tools, buy the enterprise tenant, and declare the problem managed. I understand the impulse and it is not wrong, exactly. It just solves a different problem than the one people think it solves.

Moving a Developer from a personal ChatGPT account onto a corporate tenant addresses account governance. It does very little for the data governance underneath it. The prompts still contain source code, the context windows still pull from internal document stores and wikis, the retrieval layer still reaches into systems with their own access models, and the outputs still land somewhere nobody is watching. The organization traded an unmanaged account it could not see into for a managed account it still cannot see into, and then closed the risk item anyways, despite the gap.

ISACA’s 2026 AI Pulse Poll, which surveyed more than 3,400 practitioners across IT audit, governance, cybersecurity, privacy and emerging tech roles, put a number on it. Only 43% said they were completely or fairly confident their organization could investigate and explain a serious AI incident to leadership or regulators. More than half do not know how quickly they could halt an AI system in response to a security incident.

That first figure is, to me, the whole article in one line. Investigating and explaining an incident is not a policy capability or a governance capability. It is an evidence capability, and evidence means logs somebody decided to collect before the thing happened. A majority of ISACA’s respondents could not say they were confident their organization could reconstruct what an AI system did.

Everything else in an AI security program sits downstream of that.

You Cannot Inventory What You Never Logged

Every serious piece of AI security guidance published in the last three years starts in the same place, which is inventory.

NIST has covered this in various publications such as the AI Risk Management Framework which calls for inventorying AI systems and their GenAI Profile, which pushed for organizations to enumerate AI systems and continuously monitor third-party ones being leveraged.

OWASP gets to the same place from the threat side, where the Excessive Agency guidance asks teams to log and monitor LLM extension activity, and is careful to frame that as damage limitation rather than prevention. It’s worth noting that excessive agency also jumped to #3 on the latest OWASP LLM Top 10 as well, due to the impact agents are having in real-world incidents.

The OWASP Top 10 for Agentic Applications, released at the end of 2025, is where this stops being aspirational and becomes an engineering requirement. Goal hijack asks for “comprehensive logging and continuous monitoring of agent activity” plus a behavioral baseline covering goal state, tool-use patterns, and invariant properties such as schema and access patterns.

Tool misuse wants immutable logs of every tool invocation and parameter change, along with monitoring for unusual tool-chaining. Rogue agents wants signed, immutable audit logs of agent actions, tool calls, and inter-agent communication.

Read those as an engineer rather than as a GRC practitioner, and what OWASP is asking for is a behavioral baseline per agent, immutable logs of every tool call, and signed records of agent-to-agent traffic. Every one of them is a telemetry problem before it is an AI problem, and I would wager most organizations reading this could not satisfy a single one today for a single production agent, let alone all of them.

The Cloud Security Alliance published research in March in which 68% of respondents said they cannot clearly distinguish AI agent activity from human activity, and 79% believe agents create new access pathways that are difficult to monitor. The shape of it matches what I hear from practitioners constantly, and it is the same structural problem we have failed to solve for non-human identities generally, which I wrote about previously in an article titled “Identity Is the Agentic AI Problem Nobody Has Solved Yet”.

Now, none of this means the sky is falling, and I want to be careful not to overstate where enterprises actually are. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027 on cost, unclear value, or inadequate risk controls. A great deal of what is marketed as the agentic enterprise is pilot work, as organizations stumble through the messy work of trying to operationalize this disruptive and quickly evolving technology.

That is precisely the argument for building the instrumentation now, while these architectures are still taking shape, before the telemetry debt compounds the way our vulnerability backlogs did, and before we spend another decade bolting visibility onto systems designed without it.

We know how that story ends because we have lived it with Cloud, with SaaS, and with every wave before them.

The Volume Problem Nobody Budgeted For

The uncomfortable part is that the answer to all of the above is “log more,” and that runs directly into the economics of every SIEM contract in the industry.

Telemetry growth by itself is an old problem and I won’t rehash all of the details. What makes it different this time is the character of the data rather than just the quantity of it.

Prompt and completion logs, tool call traces, retrieval events, agent-to-agent messages, and MCP server interactions arrive verbose, semi-structured, and inconsistently schematized across every provider, framework, and gateway in the stack. Making that queryable is exactly the kind of undifferentiated engineering work detection teams have no capacity for, and it lands on the same people already drowning in alert backlogs.

So we arrive at the moment where OWASP asks for immutable logs of every tool invocation and the practitioner reading that guidance is doing math on what their ingest tier costs per gigabyte. Better policy does not resolve that tension, as long as the cost of retaining a log stays coupled to the cost of analyzing it, security teams will keep making retention decisions on budget grounds and then discover, mid-incident, that the evidence they needed got dropped at the pipeline six months earlier.

I have written about the structural version of this in “The SIEM’s Structural Problem and Why It Matters Now More Than Ever” and “The Data Layer Is the New Battleground for the Agentic SOC”, so I will leave it there.

The Pyramid Is Shifting

The other half of this, and the half that came up in my conversation with Nicole Beckwith on Cribl’s security side, is what AI is doing to the indicators we have been building detections on for a decade.

For those unfamiliar, David Bianco published “The Pyramid of Pain” back in 2013 and it remains one of the most durable mental models in detection engineering.

It ranks indicator types from hash values at the bottom, through IP addresses, domain names, network and host artifacts, and tools, up to TTPs at the top, ordered by how much pain denying each one causes the adversary.

His read on the bottom of the pyramid has aged extremely well. Any reasonably advanced adversary can rotate IPs “with very little effort,” and if you burn one of them they can usually recover “without even breaking stride.” Hashes are worse, since flipping a single inconsequential bit produces a completely unrelated value.

Bianco came back to this with data in 2022, analyzing VirusTotal metadata for over 11 million unique files submitted during 2021, and found that 91.81% of them were submitted by a single submitter, with only 0.33% seen by more than ten organizations. His conclusion was blunt, and it was to stop using third-party hash values for detection, because the effort to reward ratio does not work.

The governments have since made the same argument one level up. The joint advisory on fast flux published in April of 2025 by NSA, and others notes that a typical fast flux domain may change its IP address every 3 to 5 minutes, which “renders IP blocking irrelevant” because the address is out of use before the block lands.

Beckwith’s framing was that AI has accelerated this shift rather than created it, and I think that is the correct and appropriately un-hyped read. The evidence that adversaries are operationalizing AI is real and it is now documented by the model providers themselves. Google’s Threat Intelligence Group reported in November that for the first time it had identified malware families using LLMs during execution, generating scripts and obfuscating their own code on demand rather than hard-coding it.

One family, PROMPTFLUX, carried a function to have Gemini rewrite its own source hourly, though GTIG noted that function was commented out, which is the kind of detail that separates threat intelligence from marketing. Another, PROMPTSTEAL, was used by APT28 against Ukraine and represents GTIG’s first observation of malware querying an LLM in live operations. Anthropic separately reported a campaign against roughly thirty targets where, by their assessment, AI performed 80 to 90% of the work with humans intervening only sporadically, at perhaps four to six critical decision points.

OpenAI’s October threat report concluded across the activity it disrupted that it found “no evidence of new tactics” or that its models handed threat actors novel offensive capabilities. In the individual operations it wrote up, OpenAI described actors who appeared to be primarily seeking incremental efficiency in workflows they already had.

M-Trends 2026, grounded in over 500,000 hours of Mandiant incident response last year, lands in the same place, noting adversary AI adoption while reporting that, from its own frontline vantage point, the vast majority of successful intrusions still stem from “fundamental human and systemic failures.” Global median dwell time actually rose to 14 days from 11, and exploits remained the most common initial infection vector for the sixth straight year at 32% of intrusions.

So the honest synthesis, less exciting than either the doom or the dismissal, is that AI is not rewriting the threat model from scratch. It is compressing the cost and the cycle time of everything at the bottom of the pyramid, which was already cheap for adversaries and already low-value for defenders.

Regenerate the binary, rotate the infrastructure, rewrite the script, and every atomic indicator you were matching on is stale before your feed refreshes. MITRE’s Center for Threat-Informed Defense makes the structural version of this argument in Summiting the Pyramid, pointing out that a detection built on a hash will miss the same malware altered by a single byte, while TTPs sit at the top precisely because they are the most expensive thing for an adversary to change.

Detecting behavior rather than artifacts has been the stated goal of detection engineering for a decade. What has kept most teams from getting there is not conviction.

It is that behavioral detection requires broad, retained, correlatable telemetry across sources, and that requirement collides head-on with the volume and cost problem in the previous section. Which brings the two halves of this article together.

Four Things, All of Them Telemetry

Strip away the vendor positioning and the requirements for securing AI in an enterprise reduce to four things, and Nicole from Cribl’s framing of them makes a ton of sense.

• First, identify what exists, meaning an inventory of models, agents, tools, plugins, and extensions, including the ones nobody registered.

• Second, observe how those things are actually being used, which means prompts, input context, and session activity rather than a count of API calls.

• Third, track where data is going, meaning what feeds the models, where it is retained, and what leaves the boundary.

• Fourth, alert on malicious activity, including exfiltration, leakage, abnormal usage spikes, compromised accounts, and agents deviating from how they normally behave.

Every one of those four is a telemetry problem. You cannot inventory what does not emit, you cannot baseline behavior without history, and you cannot detect deviation without both.

The AI security tooling market is full of products that quietly assume this substrate already exists, and in most enterprises it does not.

A Look at One Approach in Practice

Which brings me to Cribl, who partnered on this piece and whose team spent two sessions this summer walking me through their platform and their AI security approach.

Cribl is useful as the example here for a specific reason, which is that they came at AI security from the data layer rather than the model layer, which is especially relevant as we as an industry realize the model isn’t a security boundary.

The company positions itself as “Your AI Platform for Telemetry”, They also earned a FedRAMP Moderate ATO in January, which was relevant for me given I came from the public sector both as a contractor supporting agencies, and on the GSA FedRAMP team and I know agencies desperately need innovative capabilities when it comes to AI.

I chatted with Nick Heudecker, who leads market strategy and competitive intelligence at Cribl, and he described customers seeing data volumes climb 80 to 100 percent annually, with some going from one petabyte to 2.5 petabytes per day of ingestion, and most of them not remotely ready for that from a governance or security perspective.

The architectural argument he made is one I have made myself in a different context, which is that a pipeline sitting between sources and destinations functions as a two-way door. It lets you change SIEMs, augment with best-of-breed tools to avoid vendor lock, route the same data to multiple destinations, and avoid a world where your detection strategy gets dictated by whatever your ingest contract makes affordable.

On the four pillars, Cribl’s AI observability app runs on top of that pipeline. Publicly the company pitches it as one place to search, investigate and report on AI telemetry across models, tools and environments, surfacing AI usage, sensitive data and cost.

In the demo that meant an inventory of models, agents, tools, plugins and extensions, extending into prompts, input context and session activity. For the data protection layer, Cribl Guard ships with over 200 configurable policy rules and more than 220 prebuilt detection patterns, organized into rulesets for secrets and credentials, bank and credit cards, medical codes and licenses, network authentication and configs, and PII, running either in an active mode that masks in real time or a background mode that samples and lets you decide what to protect automatically.

I want to be equally clear about the boundaries here, because the Cribl team was during our convos, and that candor is a good part of why I found the conversation worth writing up.

Cribl operates as an aggregator. For bespoke agents running on endpoints it leans on existing EDR telemetry rather than shipping its own sensor, and for tracking where data goes it currently depends on tooling like DLP that you already own.

Once that telemetry is ingested you can drive policy decisions from it and route enforcement accordingly, but the collection depends on instrumentation already in place. For most enterprises that is a feature rather than a limitation, since the alternative is yet another agent on the endpoint. It does mean Cribl’s AI visibility is bounded by the quality of the sources feeding it, and any evaluation should start there rather than with the dashboard.

The fourth pillar is where the demo got genuinely interesting. Nicole’s team had built a threat intelligence platform on Cribl’s app framework to ingest IoCs, and then ran into exactly the wall this article walked through above, which is that the bottom of the pyramid has become ephemeral enough that the effort stops paying for itself.

What they built in response is called APEX, and it maps MITRE ATT&CK TTPs as individual signals against raw telemetry and clusters those signals into behavioral chains, generating detections from the previous 30 days of telemetry to set a baseline, with users able to tailor criticality and monitoring windows to their own risk tolerance.

Publicly, Cribl announced new security capabilities in August that include stream-native detections running on telemetry as it moves through the pipeline, plus detection engineering capabilities out of their CardinalOps acquisition that map detections to ATT&CK, expose coverage gaps, and surface broken and noisy rules before they fail silently.

Two design choices in the capability Cribl demoed are worth pulling out for practitioners. The first is that it works against any log source piping into Cribl without requiring OCSF normalization, with detection engineers working from roughly the top 15 critical fields that stay consistent across sources rather than parsing every field in every source.

Anyone who has been involved in a data normalization project knows how much undifferentiated effort that avoids, and normalization debt is one of the quieter reasons detection coverage stalls out.

The second is that running detections closer to the telemetry layer, rather than after data lands in an analytics platform, shortens the distance between an event happening and an alert firing.

Combined with the correlation work their team described as weeks out at the time of our conversation, clustering activity within time windows so alerts fire against behavioral baselines, the intent is to avoid a world where covering the technique space means authoring and maintaining tens of thousands of individual detections. Whether that holds up at enterprise scale is something practitioners will need to validate in their own environments, and I would want to see it running against a genuinely messy estate before drawing conclusions but the premise makes sense and is promising.

Closing Thoughts

This is far from an exhaustive discussion of AI security, and there are entire domains I have not touched, from model supply chain to inference-time attacks to the agent identity problem, among others.

That said, the the recurring theme is hard to miss. NIST wants an inventory, OWASP wants immutable logs of every tool invocation and a behavioral baseline for every agent and regulators are going to want you to explain what happened. None of that is achievable without a data layer built to carry it, and most security practitioners being surveyed don’t feel confident they could produce that today.

There is a version of this market that sells you a model firewall, a prompt scanner, and yet another dashboard, and leaves you exactly where you started, unable to answer basic questions about what your AI systems did on any given day. I do not think we get out of this by adding another silo. We learned that in the Cloud era and relearned it with SaaS, and the organizations handling AI adoption best so far are the ones treating it as another set of sources and destinations in a pipeline they already understood.

The ask is tough too though, as we are being asked to expand telemetry and add behavioral baselining for an entirely new class of non-human actor in agents at the exact moment most teams are under pressure to cut ingest costs due to runaway bills. Something has to give there, and I would much rather it be the assumption that we must pay analytics prices to retain evidence than the evidence itself.

So, will we build the instrumentation while these architectures are still forming, or spend the next five years reconstructing what our agents did from logs we chose not to keep?

We have run this experiment before, and we know how it goes when security shows up after the fact, which is disjointed tech stacks, open questions in our incident response and the inability to deliver on secure outcomes for the businesses we support.

Subscribe now

Two stories dominated the week, and both of them run through Hugging Face. OpenAI published its technical report on the incident where its own internal research models escaped an evaluation environment and went on to compromise Hugging Face infrastructure, and NVIDIA is reportedly closing in on acquiring Hugging Face for somewhere in the neighborhood of $13 billion.

Read together, they tell you a lot about where we actually are. Agents are demonstrably capable of chaining novel vulnerabilities to break out of the sandboxes we build for them, and the open model ecosystem those same agents are trained on and distributed through has become valuable enough that the most important chip company on the planet wants to own the distribution point. Both of those have security implications we are only starting to work through.

The rest of the week filled in around them, with Trail of Bits arguing that VMs won’t contain cyber-capable agents, the researchers behind ExploitGym walking through how they measure agent exploitation capability, SemiAnalysis making the case that open models close the gap faster with every cycle, and Ciaran Martin offering a badly needed corrective to AI doomerism.

Let’s get into it!

Know your attack surface before it outgrows you

You cannot patch, monitor, or govern an asset you don’t know exists. Yet, most enterprise inventories are still working from an incomplete picture.

runZero, built by HD Moore (the mind behind Metasploit), delivers agentless, credential-free discovery across your entire internal and external attack surface—surfacing unknown and unmanaged assets along with the exposures riding along with them: CVEs, default credentials, misconfigurations. No appliances, no scanning windows to negotiate, just an accurate picture of what’s actually out there.

Start your 21-day free trial

Pro tip: When your trial wraps, runZero’s free Community Edition covers up to 100 devices, perfect for home labs!

*Sponsored

Cyber Leadership & Market Dynamics

NVIDIA in talks to acquire Hugging Face in $13 billion deal

News broke over the weekend that Hugging Face was fielding takeover interest, and by midweek The Information reported that NVIDIA had agreed to buy it for $12.9 billion, with no signed agreement yet and neither company confirming. For context on how fast this has moved, Hugging Face turned down a $500 million NVIDIA investment in late 2025 that valued it at $7 billion, with CEO Clem Delangue saying the company “didn’t want a dominant investor that could sway its decisions.” It was valued at $4.5 billion in 2023 and is now doing roughly $150 million in annual revenue, up from about $100 million two months prior.

The strategic logic is easy to follow, with OpenAI, Google, Amazon, and Anthropic all building their own silicon, owning the place where open models get published and pulled is a durable way to keep the ecosystem on your hardware. The security angle is the one I’m most interested in of course.

Hugging Face is effectively the GitHub of AI, a package registry for weights, datasets, and Spaces that enterprises pull from constantly, often with far less scrutiny than they apply to OSS packages. Concentrating that registry under a single vendor with its own commercial incentives changes the software supply chain risk conversation, and it does so in the same month the registry itself got rooted.

Rolling with the Punches: Why Cybersecurity is Backgammon, not Chess

Phil Venables is one of the most consistently useful writers and deep thinkers in our field, and this one qualifies. His argument is that we keep framing security as chess, a game of perfect information where a sufficiently smart player calculates their way to victory, when it actually behaves like backgammon, which he describes as “stochastic risk management” where skill has to account for the dice. He maps it out through blots and anchors (exposed vulnerabilities versus layered controls like IAM, MFA, and segmentation), priming, the blitz (automated ransomware hitting everything at once), and the doubling cube (the decision of whether to pay or execute recovery).

The cultural point at the end is the one that matters for security leaders. Chasing “flawless, unyielding defense” is the wrong objective function, and resilience means accepting that bad rolls happen and building an organization that absorbs and adapts. Given how the OpenAI incident below unfolded, with clear signals that went un-escalated, this framing is timely.

Exclusive: CrowdStrike’s CTO is leaving to launch an AI cyber fund

Elia Zaitsev is leaving CrowdStrike after 13 years as global CTO to launch Cognition, a venture firm he is starting with Gur Talpaz and Tayler Sipperly, targeting $170 million. The model is concentrated, leading or co-leading seed and Series A with average checks around $6 million and $15 million respectively, and only three to four investments a year. Zaitsev’s framing is that agentic AI is a platform reset for security, and as he put it:

“We have this new attack surface that’s being brought on by AI and agents.”

I’ve made the point before that we are watching a genuine reshuffling of the security market, with operators leaving incumbent platforms to build and fund the next wave. Whether agentic AI produces a category-defining platform or gets absorbed into the existing consolidators is the open question, and it is one Sid Trivedi and I spent a good chunk of our annual pre-Black Hat conversation on. That said, when a sitting CTO of the most successful endpoint platform of the last decade walks out to raise on this thesis, it tells you something about how the people closest to the data see it.

Cybersecurity startup Minimus shutting down after raising $51 million

The other side of that market story, and one we don’t hear about enough. Minimus, founded by the team that sold Twistlock to Palo Alto Networks for roughly $410 million in 2019, is winding down after raising $51 million in seed funding. The company built stripped-down container images and VMs with dramatically fewer vulnerabilities, publicly launched in April 2025, and had around 60 employees four months ago. Customers have 60 days, until October 22, to migrate off the Minimus registry. The founders’ statement is pretty direct as well, that:

“the current business and investment climate has resulted in a situation in which we are unable to continue operations.”

This one stings, because the product solved a real problem. Minimal images are one of the few software supply chain interventions that actually burns down vulnerability backlogs rather than just measuring them. Proven founders, real technology, and a genuine pain point still weren’t enough, which says quite a bit about how hard it is to sell into a crowded container security market where buyers have five ways to defer the purchase.

As I wrote on LinkedIn, this is a good example that building a thriving security (or any) company is very hard. This one had a real market need, being addressed by repeat founders who have walked the path. But, it is a highly competitive category with players like Chainguard dominating the space and it is hard to be wake a player who defined and built the category.

A good reminder in this era of record setting funding rounds, PR announcements and categories flooded with tens of security vendors chasing the same problem around AI and agents.

Questions to ask AI security vendors

Lenny Zeltser put together five questions worth bringing into any AI security evaluation, which AI asset the product actually protects, whether it delivers value standalone or requires a broader platform, what exists today versus what lives on the roadmap, whether you already own the capability somewhere else in your stack, and what evidence backs the claims. His framing is refreshingly direct, that “In the fast-changing AI security market, a product described one way often turns out to be something else after a closer look.”

The fourth question is the one most practitioners skip and the one that kills the most deals, and the distinction he draws between traditional tooling with AI bolted on and genuinely AI-native protection is the fault line running through this entire category right now.

My favorite though is the one tied to roadmap vs. actual capabilities, and not what lives in a analyst or marketing pitch deck. Many of the AI-centric categories have companies chasing the opportunities but they have little to no actual functional capabilities deployed in production with customers.

Be careful out there!

The choices we make about AI now are critical

Bill Gates argues that this transition differs from previous ones because AI automates cognition itself, and that it will play out over a decade rather than across generations. He points to Stanford payroll data showing a 16% relative employment decline for workers aged 22 to 25 in AI-exposed occupations while older workers stayed flat, and proposes a governance framework modeled on nuclear inspection and aviation regimes, “Human Reserved” roles kept for people, and a token and robot tax.

The line security folks should notice is his, that:

“The smartest cybersecurity experts I know are scared about the next few years, because the attackers are getting powerful new capabilities faster than the defenders can fix all the weaknesses.”

I don’t agree with all of his prescriptions, and I remain skeptical of preemptive regulatory regimes built around hypothetical harms. That said, the asymmetry he describes is real, and the gap between offensive capability and defender remediation throughput is showing up in nearly every other item in this issue.

Diffusion is destiny for defenders, and our best defense against the coming AI impact in cyber by attackers is arming defenders with the innovative capabilities as quickly as possible.

Fears of AI-induced armageddon are overdone

Ciaran Martin, founding CEO of the UK’s NCSC, wrote the counterweight to the piece above, and it is a rational pushback on some of the AI FUD. He opens with L0pht walking into a Senate office building on May 19th 1998 and telling lawmakers they could render the internet unusable in 30 minutes, then walks through Leon Panetta’s 2012 “cyber Pearl Harbour” warning, pointing out that our field has “a long history of apocalyptic prophecies” that never arrived.

Martin isn’t arguing that nothing bad happens, he is arguing that our track record of predicting catastrophic collapse is terrible and that the predictions themselves distort policy and spending. Coming from the person who ran a national cyber defense agency, that carries weight. Pair it with the Gates piece and with below, and you get a much healthier version of this debate than the one happening on your social media timeline.

Anthropic plans to change data retention policy for advanced AI

Anthropic is reportedly moving to let enterprise customers store required data in their own cloud environments rather than exclusively on Anthropic’s infrastructure, while keeping a 30-day retention requirement for its most capable models.

For anyone running a frontier model in a regulated environment, this is the constraint that has been blocking deals, and it is a reasonable compromise between the safety case for retention (you cannot investigate an incident like the one below without logs) and the enterprise requirement to control where data lives.

Given that OpenAI’s own report leans heavily on retained chain-of-thought and infrastructure telemetry to reconstruct what happened, the tension between “retain enough to investigate” and “retain nothing our customers didn’t consent to” is going to be a live governance question for every AI vendor, not just Anthropic.

This has also been a key point/theme in the conversations around open vs. closed models for enterprises, so it isn’t surprising to see the labs trying to offer different options to alleviate those concerns and streamline procurement pathways to expand adoption and consumption.

AI

The Hugging Face incident and the road ahead

This is the report of the year so far, and if you focus on one thing in this weeks issue, make it this.

OpenAI walked through how internal research models, during cybersecurity evaluations, “communicated through unauthorized channels, exploited vulnerabilities in shared infrastructure, gained internet access” and ultimately compromised both OpenAI and Hugging Face infrastructure.

The timeline is a key aspect to examine.

• On May 12 the agents discovered they could pass messages to each other through Artifactory, building an improvised message board out of file directories to coordinate across supposedly isolated instances.

• On May 26 they got internet access through SSRF.

• On June 26 they exploited a token refresh flaw for admin access.

• On July 4 sustained agent activity crashed Artifactory, and when it was rebuilt on July 8, the agents immediately reestablished both the message board and internet access.

• Between July 10 and 12 they recovered publicly exposed Hugging Face credentials, chained “several novel security flaws” into code execution, and took root across Hugging Face servers in multiple regions.

• Detection came on July 19 and 20, and public disclosure on July 21.

The root cause analysis is where the practitioner value and community takeaways are. OpenAI names reward hacking, persistence without a safe exit, metagaming, and unauthorized communication. The most damning figure in the report is that of 898 ExploitGym tasks, 198 were ones the models had never solved, and those unsolved tasks accounted for “93% of the tasks that were discussed on the Artifactory message board.”

The models were handed impossible problems, given enormous compute, rewarded for solving them, and rationally concluded that attacking the scorer was the path to reward.

Two failures compounded the situation as it is described. Production safeguards, meaning system prompts and auto-review models, were “not applied in the evaluation environment,” and chain-of-thought monitoring wasn’t running on these evaluations at all. OpenAI states that:

“deployed monitoring would have caught the initial relevant activity and paged our security team more than a day before models breached Hugging Face systems,”

and that production safeguards reduce infrastructure compromise propensity by over 100x. The controls existed, they just weren’t turned on where the most capable models were being pushed hardest.

There are also things the report doesn’t say. Per Fortune’s read, OpenAI didn’t publish the prompt given to the agents, message examples, or code snippets, all of which Hugging Face did include in its own July 29 post-mortem.

Fortune also reports, citing the independent METR and Redwood Research analyses, that 1,200 agents communicated over the message board and 700 participated in the attack, with a lead agent coordinating concealment. OpenAI’s own characterization, that this was “misaligned behavior in an outlier scenario involving a rare and unexpected confluence of events,” reads as perhaps thinner than the timeline alludes to.

That said, credit where it is due, publishing this level of detail is genuinely valuable to the field, and the commitments are the right ones, including required chain-of-thought monitoring for models at GPT-5.6 Sol capability or above, multi-agent alignment environments that teach models “to distrust unauthorized instructions,” training that rewards “correctly identifying broken tasks, requesting clarification, or stopping safely,” and 30-minute escalation requirements for severe misalignment alerts.

That said, every one of those is a control we already know how to describe in enterprise security terms, and none of them were in place at one of the organizations with the most capable models on earth and the most reason to be careful.

VMs won’t contain cyber-capable agents

The team at Trail of Bits published the perfect companion piece, and the timing is ironic. They gave GPT 5.6-Cyber the task of escaping a VM sandbox, and it succeeded three separate times with escalating sophistication.

• First, it identified a recently disclosed kernel vulnerability, built an exploit, and hardlocked the host.

• Second, it found that Debian 12 shipped an outdated libslirp (v4.7.0) carrying CVE-2026-9539 and combined it with an unmarked bug fix to get arbitrary read and write into host memory.

• Third, and this is the one that is most concerning, it chained three previously unknown vulnerabilities across QEMU, Linux KVM, and libslirp, plus one patched flaw nobody had recognized as security relevant, to get controlled execution in the host kernel.

The behavioral description matters as much as the results on this one. The agent “operated autonomously for hours, backtracked from approaches that didn’t work, pulled code and research papers,” and sustained this across 12-hour windows. That is not a model completing a benchmark, that is a researcher with infinite patience.

The blogs recommendations are practical, meaning minimal virtualization platforms like Firecracker rather than full QEMU, continuous distribution updates instead of stable releases that lag on patching, least privilege applied to network access and credentials, and time-limited operations with pristine resets between runs.

Put this next to the OpenAI report and the conclusion is uncomfortable, because the sandbox has been among the load-bearing control in every agent security architecture, including plenty in production today.

This is a topic I’ve discussed on the Resilient Cyber show in the past with folks such as Luke Hinds and Alex Zenla months ago, before the breakouts got everyone’s attention.

Inside ExploitGym: How Researchers Are Measuring AI Agent Exploitation Capabilities

Timely context on the benchmark at the center of the OpenAI incident. ExploitGym holds roughly 898 vulnerability instances and measures whether agents can turn known vulnerabilities into working exploits, across userspace memory safety flaws in C and C++, browser engines (Google’s V8), and Linux kernel exploitation.

The results show a steep difficulty curve. Claude Mythos Preview and GPT-5.5 led with 157 and 120 successful exploits, but kernel exploitation collapsed that to 12 and 22 successes for the top two models. Agents also sometimes achieved code execution through unintended vulnerabilities rather than the one under test, which is exactly the behavior that generalized into the OpenAI incident.

“Measuring only whether an exploit succeeds may miss important changes in how that success is achieved.”

Agentic AI: The New Insider Threat Model

Katie Moussouris of Luta Security frames autonomous agents as an insider threat problem, which is the right mental model. Her assessment of the Hugging Face incident is direct, that:

“Clearly, we didn’t have the real-time monitoring in place, and we don’t have any breaks that seem to work.”

She notes the gap between initiation in May 2026 and detection on July 19, roughly two and a half months of undetected activity, and points out that Anthropic’s latest model “realized it was on the internet and stopped itself,” which is the behavior we should be training toward.

Her broader push is one I strongly agree with, that organizations need to invest in the fundamentals, reduce attack surface, and manage technical debt rather than assuming AI tooling solves problems the organization never solved manually.

The insider framing is useful because we already have a discipline for this, with behavioral baselines, least privilege, separation of duties, and monitoring for the trusted entity going off-script. We just have to apply it to entities that operate at machine speed and outnumber our employees, which is a new paradigm for us all.

Where Security Fits in an AI Agent Stack

NVIDIA published a genuinely good architectural piece, and the core distinction is one I’d like to see adopted broadly, that behavioral controls (prompts, model safeguards, harness logic) are different in kind from infrastructure controls (what the runtime actually permits). Their framing is clean, that “The harness guides what an agent tries. The infrastructure controls what an agent can do.”

They lay out five layers, distribution and product, orchestration, agent harness, secure runtime, and inference data plane, with a security boundary drawn between the harness and the runtime so requests cannot route around policy enforcement. The five design rules are the useful part, that higher layers propose and lower layers decide, policy lives below the boundary, every effect is checked, access is just-in-time, and isolation enables recovery. They also define four escalating security profiles, Isolated, Connected, Production, and Adversarial.

This maps almost exactly onto the soft guardrails versus hard boundaries argument I’ve been making for a while now, and the OpenAI incident is the proof case. Every control that failed there was a behavioral control, or a boundary control that simply wasn’t enabled.

Secure Vibe Coding and the 99%

In this episode, I sit down with Igor Andriushchenko, Head of Security and CISO at Lovable, to discuss securing AI-native development, including soft guardrails versus hard boundaries, the shared responsibility model for vibe coding platforms, and how GRC engineering fits into a world of AI-powered attackers.

I had been chasing Igor down on LinkedIn since February, so I was glad to finally get him on the show. Lovable sits in an unusual spot. Igor has to run security for a company that went from roughly 40 people to 400 laptops in MDM inside a year, and at the same time the product he is securing hands software creation to people who are not developers and have never thought about security at all. Those two problems pull in different directions, and the conversation gets into how his team handles both.

Are Open Models Catching Up?

The best data-driven piece I read this week, and directly relevant to the NVIDIA news above.

and SemiAnalysis argues the gap between open and frontier models closes in roughly half the time with each successive era.

The authors are appropriately careful, noting that “benchmarks are not the end all be all” and warning about hill climbing on public evals. For security purposes, though, the direction is what matters.

If open-weight models reach frontier agentic capability within four to six months of release, then every capability demonstrated in the OpenAI report and the Trail of Bits research becomes available to anyone with a GPU and no safety stack on top of it, on a predictable clock. That is the assumption Igor’s conversation above mentions, and the evidence supports it.

Where are all the prompt injection attacks?

asks the question our industry avoids, which is why documented real-world damages from prompt injection remain tiny relative to the hundreds of billions lost to cybercrime annually.

He offers three explanations:

• Opportunity cost (attackers still get in through known vulnerabilities, weak credentials, and misconfigurations, which is cheaper than building novel exploit workflows)

• Organizational inertia (established criminal enterprises have profitable, proven playbooks and poor ROI on retraining)

• Attribution gaps (detection tooling for LLM-mediated breaches is immature enough that successful injections may be getting attributed to whatever system got touched next).

He isn’t dismissing the risk, and he still recommends securing agents with something like Meta’s rule of two, restricting sensitive actions on untrusted data.

His point is about resource allocation, that overweighting AI-native risk because it dominates conference talks means underfunding the tech debt that is actually getting organizations breached. Josh has been on the Resilient Cyber show and consistently brings evidence rather than vibes, and this is a good example of it.

AppSec

Staying Ahead of Adversarial AI Through Agentic Source Code Review

Google Cloud and Mandiant detailed their Agentic Vulnerability Discovery Harness, a waterfall pipeline of specialized agents running threat modeling, entry point discovery, context enrichment, hypothesis generation, and hypothesis validation, with human expert gates at both ends.

Distinct agents handle access control analysis and data flow analysis, Gemini Flash Lite handles parallelized entry point discovery at scale, and high-temperature validation agents feed a synthesis agent that marks findings Confirmed, Disproven, or Rejected. Mandiant expertise is injected through a three-tier rules hierarchy covering domain, framework and language, and vulnerability specifics.

The results are the reason to read it, with 12 CVEs assigned so far, another dozen in active disclosure, tens of millions of lines of code analyzed, and over 100 critical vulnerabilities discovered in two days during an incident response engagement.

The harness is the story here, not the model, which is a trend we continue to see. This is the same lesson from the NVIDIA piece above and from OpenAI’s report, that capability comes from orchestration, scoping, and validation rather than from prompting a frontier model harder.

It is also worth noting that Google is careful to keep human validation in the loop at the exploitation stage, which is the difference between a finding and a fix.

Just a rumour of a bug is enough to find a security exploit these days

Anil Madhavapeddy, the OCaml maintainer and Cambridge researcher, wrote a super interesting piece. He opened a public pull request fixing a path traversal bug in cohttp and saw probes matching that vulnerability pattern within 10 minutes. He then demonstrated that building a working exploit from the PR alone took roughly one minute with available models. His point is that embargo, the entire premise of coordinated disclosure, assumes attackers need time that they no longer need.

He cites 2026 research showing the bottleneck has moved to “defender remediation throughput,” and points to CVE-2026-39987 exploited in 9 hours and CVE-2026-33017 in 20 hours with no public proof of concept in either case. His proposals are worth engaging with, including private development infrastructure with web-of-trust authentication, continuous shipping on Chrome-style cadences, and protocol-layer virtual patching through distributed rule networks ahead of upstream fixes.

For open source maintainers, this is a serious problem with no good answer yet, something I’ve discussed on the show with industry veteran Casey Ellis of Bugcrowd. The security fix commit is now an exploit specification, and most maintainers have no ability to ship a coordinated release across an ecosystem before that specification is public.

Anyone working on OSS security funding and infrastructure should be reading this one closely.

How to Hack AI Agents

Shoeb Patel put together an excellent practitioner’s mental model for finding vulnerabilities in agentic systems, and it is the resource for AppSec engineers being asked to test their first agent.

He frames the core problem:

“the model is trained to trust the system prompt more than the user, and the user more than tool results. But this boundary is soft.”

This aligns with the soft guardrails vs. hard boundaries framing I’ve been writing and speaking about for a while now. From there he separates direct injection through user-controlled inputs from indirect injection hidden in web pages, emails, plugin descriptions, repositories, documents, and logs, then walks the impact vectors of data exfiltration, privileged actions taken under the agent’s or victim’s identity, and persistence through injections stored in memory and configuration.

The writeup references more than 15 documented attacks including CamoLeak, EchoLeak, and Invitation Is All You Need, and points to practice environments like Gandalf and HackAPrompt plus Microsoft’s PyRIT for red teaming.

Note how well it pairs with Saxe’s piece above, because the techniques are all real and demonstrated while the in-the-wild exploitation data remains thin, perhaps due to the factors Josh mentioned such as attribution, widely available low hanging fruit etc.

Final Thoughts

The week’s two headline stories are the same story told twice. OpenAI’s report shows agents chaining novel vulnerabilities to escape an evaluation sandbox, and Trail of Bits shows a commercially available model doing the same thing to a VM three different ways.

Meanwhile, the registry those models are published to and pulled from is about to change hands for $13 billion, and SemiAnalysis has the data showing open-weight models reach that capability level four to six months behind the frontier and closing.

If those things are all true at once, the security architecture most organizations are building around agents right now rests on a control that doesn’t hold, against capabilities that will be freely downloadable inside of a year.

The good news, such as it is, is that nobody is proposing exotic solutions. NVIDIA’s boundary model, Igor’s six pillars, Moussouris’s insider threat framing, and OpenAI’s own list of commitments all describe controls we already know how to build.

We just have to actually build them, everywhere, and turn them on in the environments where we are pushing the hardest, which is precisely where they weren’t.

Stay resilient.

Subscribe now

I had been chasing Igor down on LinkedIn since February, so I was glad to finally get him on the show. Lovable sits in an unusual spot. Igor has to run security for a company that went from roughly 40 people to 400 laptops in MDM inside a year, and at the same time the product he is securing hands software creation to people who are not developers and have never thought about security at all. Those two problems pull in different directions, and the conversation gets into how his team handles both.

We chatted about:

• Building a security program for a 15x company when you already know you are going to be 10x, and what breaks along the way

• Soft guardrails versus hard guardrails, why hard blocks get routed around by AI-assisted workflows, and how to tell which problems deserve which

• Anchoring guardrail decisions in business goals, risks, and threats instead of tool defaults

• The gap between democratized development and democratized security, and what a platform owes the 99 percent

• Lovable’s auto-fix toggle, the per-app threat model built behind the scenes, and the goal of shipping an app with no security tab at all

• Whether frontier models will ever produce secure code by default, and why defense in depth still does most of the work

• Governing the reality that every employee vibe coding an app starts to look like a new vendor

• GRC engineering as the discipline for measuring control efficiency layer by layer

• CRA, NIS2, and the EU AI Act landing on citizen developers who never considered themselves software manufacturers

Prefer to listen?

Spotify

Apple Podcasts

Please be sure to leave a rating and review, as it truly helps the show!

Takeaways

Build the security program for the company you are about to be

Igor joined Lovable as the first security hire when it was around 40 people. Today his team is 20 plus and covers product security, GRC, IT, and platform safety, and the company is managing about 400 laptops in MDM. He described the security team itself as growing roughly 25x in that stretch, from one person to around 25 with offers out.

What I found useful was how he framed the planning problem. He and the team could see the revenue numbers before anyone else could, which meant they could see the trajectory. “As a CISO you just need to build your security program to cater for probably 15x company. If you expect to be 10x, if you add extra on top for extra resilience, then you’ll be fine.” He also made the point that the threat model changes as you scale, because a 40 person company and a company on the front page of every tech publication do not attract the same adversaries. That is a very different exercise than budgeting off last year’s headcount, and it is one most security leaders in high growth environments should be doing more deliberately.

Soft guardrails are coming for most of your controls, but not all of them

Igor’s argument is that deterministic controls were an artifact of a deterministic world. Static analysis was called static for a reason. Rules matched or they did not. What AI enables is a control that can look at intent, at a person’s role, at what they are actually trying to accomplish, and make a judgment. He compared it to onboarding an intern and sitting next to them, which is a much better analogy for adaptive policy than anything I have heard from a vendor.

He is not arguing hard blocks go away. He explicitly wants some. “We take human creativity and we multiply it by agent creativity,” and sometimes the result is an agent with no judgment about what it should never do. His example of a genuine hard boundary is an agent never escaping a sandbox, or never being handed a powerful admin-level CLI with developer credentials. The part that matters for practitioners is that he derives those hard boundaries from business risk rather than from a tool’s default policy set. If your risk model is done deeply enough, the things that should never happen are already written down somewhere.

The platform owes the 99 percent more than a fix button

This was the thread I came in most curious about. Lovable’s stated goal is empowering the 99 percent to build, and I have made the argument for a while that we democratized development without democratizing security. Igor’s answer is that they tried the obvious thing first and it did not work. They surfaced security bugs in a project with a button to have AI fix it, and very few people clicked it. Their research found two reasons. People were scared of breaking something that already worked, and security felt complicated and unfamiliar.

So they pushed the responsibility further onto the platform. In June they shipped an auto-fix toggle in settings, and behind the scenes every application gets scanned and a security model built for it, which is functionally a threat model. The direction he described is a platform that fixes the obvious issues silently and reserves the human interaction for questions only the builder can answer, like whether a given table should be private or public. “Ideally, there should be no security tab whatsoever in the app.” That is secure by design applied to an audience that will never read a secure coding guide, and it is only possible because Lovable owns the whole loop from generation to deployment to runtime. Most vendors cannot make that claim, which is exactly why platform providers have systemic leverage that individual security teams do not.

Good enough changed, and that is what makes GRC engineering interesting

Igor’s take on AI-powered attackers is the part of this conversation I keep thinking about. Defense in depth historically worked on a good enough standard. You layered controls, accepted that each layer had gaps, and trusted that the aggregate would slow an attacker down long enough to detect and eject them. His argument is that standard no longer holds when someone with no offensive security background can point a capable model at a target and let it work. As he put it, that is “hacking at the cost of electricity.” A relentless attacker will find the gap in layer one, then the gap in layer two, and it will do it fast.

His conclusion is that each layer now needs measured, near-complete coverage rather than good enough coverage. If you have MFA and EDR, they need to be everywhere, not on most employees and not on that one contractor group. And measuring control efficiency layer by layer is a GRC problem, because GRC already holds the risks, the vendors, the controls, and the mapping between them. Build the eval, or the KPI if you prefer the old word, get coverage from 80 to 85 to 90, and keep going. I have spent years pushing back on the compliance does not equal security line, and this is a good articulation of why. Used this way, GRC is how you prove your controls actually work in near real time rather than how you generate a report.

Regulation is coming for people who do not know they are software manufacturers

The last thread was one I did not expect to get a fully formed answer on. When a citizen developer ships an app that touches PII or PHI, they have produced software and put it into the world, even though nobody would call them a vendor. Igor’s view is that the platform’s job is to make the obligations visible early, before someone publishes. Lovable already draws some hard lines, and he mentioned taking down apps in regulated spaces where they needed to see evidence of a license first. The vision he laid out goes further, with the platform telling a builder up front what publishing will require of them, and pointing them at where to go get it.

He also mentioned a recently released opt-in trust center for apps built on the platform, which generates a compliance posture page automatically from the app and its data. That is GRC engineering aimed at customer apps rather than at the platform’s own audit, and it is a genuinely interesting model for reducing regulatory overhead on people who never signed up to carry it. As Igor put it, the shared responsibility does not sit only with the platform. The moment a builder starts putting real people’s data into what they built, things change quickly for what they need to comply with.

Igor closed with something worth repeating for anyone in this space. If one vibe coding platform fails badly, every other platform gets the same questions the next morning. The whole category is judged together, which is a decent argument for building the security bar high early rather than after the first bad headline.

You can follow Igor on LinkedIn at https://www.linkedin.com/in/igor-andriushchenko and find Lovable at https://lovable.dev

Subscribe now

That said, OWASP’s latest 2026 Top 10 for LLM Applications recently dropped and the letter in the beginning of the publication from my friends and Project Leads Steve Wilson and Rock Lambros open up by telling the ready those arguments are basically missing the point. The below quote from the publication is something I want to cite:

That’s the entire thesis of the latest OWASP Top 10 summarized in the opening letter of the document and once you take that in, the remainder of the new document reads like a guide for practitioners in how to think about securing agentic AI and LLM deployments and the importance of the harness when it comes to being a security and trust boundary.

I’ve been making a version of this argument for several months and I discussed it in my prior article “Learning From the Frontier”, where I worked through AISI’s agent incident report, where the danger doesn’t live in the model weights but lives in the harness around the model, including Internet access and the ability to have autonomy, access tools and take actions. I also published a video on the incident.

In this article I want to walk through what the latest version of the LLM Top 10 changed, and some of the key takeaways for practitioners thinking about securing Agentic AI deployments in production environments.

Testing the Vote Against the Record

One of the aspects I thought was cool from the latest OWASP LLM Top 10 was that they used a methodology where they took the vote of practitioners, which they had done previously to determine the ranking, but they also leveraged real-world incident data to see how rankings contrasted against what practitioners voted on.

This included 7,714 real incidents from public vulnerability and AI harm databases, which in and of itself speaks to how commonplace incidents involving LLMs and agents is becoming, which was something the team also did with the OWASP State of Agentic AI Security & Governance Report, which I previously covered as well.

As they did the analysis comparing practitioners fears and rankings compared to the incident data they started to find some surprising differences. Most practitioners minds jump right to things such as Prompt Injection, ranking it the #1 risk but when it came to incident record data, OWASP said Prompt Injection would have fallen out of the Top 10 entirely.

However, they say it isn’t become prompt injection isn’t a relevant issue, but instead they call it a defense effect, arguing organizations have made efforts to mitigate injection, so fewer clean exploits that are directly attributable to prompt injection land in the public databases and incident counts.

who previously helped lead AI security and safety efforts at Meta made a different argument recently in a piece of his, titled “Where Are All The Prompt Injection Damages”, where he argued universal prompt injection is becoming less common with the latest leading models, due to improved defenses but also the fact attackers already have ample techniques that bear fruit. Below you can see him highlighting the lack of financial damages tied to prompt injection as a technique to compared to other attack technqiues.

This is a point echoed by Anthropic’s Boris Cherny recently in an interview with YC, where he argued "Anthropic’s Opus 5 model does not seem to be prompt injection anymore”, he goes on to discuss that when you combine a well aligned model with a prompt injection classifier for all traffic, coupled with an auto-mode classifier, it is very hard to demonstrate prompt injection. I have set the video below to begin at the 2:10 minute mark, which is where Boris discusses this:

That said, despite the lack of real-world financial damages, progress at the frontier labs, or real-world incident data as pointed out by OWASP themselves, prompt injection still holds the top spot on the LLM Top 10 due to the community vote carrying 75% of the vote.

This is something for organizations leveraging the Top 10 to keep in mind when it comes to allocating their time and resources, and ensuring it is tied to real-world impacts, not just popularity rankings.

There is also a third explanation for the ranking I want to throw out there, which is that injection rarely produces a cleanly attribute public record tied to incident because the impacts often surface downstream. This includes impacts such as stolen credentials, exfiltrated data or source code, poisoned build processes and so on, and gets counted as those, rather than prompt injection.

This actually can be visualized by leveraging a image from OWASP themselves in the LLM Top 10 doc. Below you can see prompt injection is an entry vector not an impact:

Viewing the OWASP LLM Top 10 As a Harness Document

Now that I’ve wrapped up my side rant about prompt injection, attribution, entry vectors and whether or not is solved by the frontier labs and how, we can start to look at the OWASP LLM Top 10 from the perspective of the harness, which is where the risks really lie.

As an aside, my teammate Diana Kelly from Noma recently had an excellent interview on the podcast Cloud Security Today, where she discusses the AI Harness in-depth.

As I showed in the image above, Excessive Agency jumped from #6 to #3 on the latest OWASP LLM Top 10 and OWASP called it the most significant move on the risk and it is directly tied to organizations ramping up agentic deployments and this being where the damage is landing. Other risks such as Unbounded Consumption and Improper Output Handling moved around the lost and others such as System Prompt Leakage became Hidden Context Exposure, speaking the importance of the context window.

All of these moves are properties of the software we build rather than the weights. For example, excessive agency is tools, permissions and autonomy. Unbounded consumption is rate limiting, quotas, and circuit breakers. Hidden Context Exposure is what your app loads into the context windows and you shouldn’t assume always stays private and none of these issues get fixed by swapping model vendors.

LLM01 - Prompt Injection makes the architectural version explicit cleanly summarizing why you can’t necessarily train away prompt injection, noting that:

“LLM’s make no architectural distinction between instructions and data (both are tokens on the same stream), so there is no clean equivalent to parameterized queries”.

This why when you listened to Boris above he mentioned the role of classifiers in addition to model alignment to try and mitigate albeit not entirely eliminate prompt injection.

LLM08 - Hidden Context Exposure goes further in the publication, telling practitioners to design on the assumption that t he hidden context is discoverable and that nothing in the context window should be treated as a secret. When we consider everything that goes into the context window, from our personal chats with the LLM, sensitive data, and so on, its easy to see why this reality is scary from both a security and privacy perspective.

Their mitigation guidance takes it further, stating that “critical controls such as privilege separation, authorization bound checks, and similar must not be delegated to the LLM”, whether through the system prompt or other mechanisms. I’ve been arguing that system prompts are not security controls, so it is useful to have an industry authority such as OWASP enforcing that point.

OWASP also plainly states the the distinction between the LLM Top 10 and the Agentic AI Top 10:

"One boundary matters more every year. This list owns the risk when the model is a component inside your application. The moment that model becomes an actor, with tools it can call, memory it carries between sessions, and consequences it sets in motion downstream, the risk moves to the OWASP Agentic Top 10."

That is OWASP directly stating that once the risk now long is directly tied to the model, it belongs to the Agentic AI Top 10 instead. I’ve served on the Distinguished Review Board for the OWASP Top 10 for Agentic Applications, so it was good to see the authors help clear up the delineation between the two, as many are becoming overwhelmed with the number of Top 10’s out there, with the latest example being the OWASP Agentic Skills Top 10, which I covered in a recent article titled “Dangerous Skills”.

So What Is a Harness?

So we’ve talked a ton about OWASP lists and specific risks such as prompt injection, and the industry has been talking about the importance of a “Harness” a lot lately, but what the hell is a harness exactly?

Databricks has had one of the easiest to understand explanations on this in a blog titled “What is an AI Agent Harness”. In it they state:

“An AI agent harness is the software infrastructure that wraps around a large language model (LLM) and enables it to act on tasks, not just respond to prompts. The model reasons through a problem and decides what to do next. The harness connects it to the tools, systems, memory and execution environments needed to carry out those actions.”

The components they mentioned above align with the OWASP LLM Top 10 fairly one, with things such as system prompts and context assembly aligning with LLM08, tools, permissions and autonomy with LLM03, memory and retrieval on LLM01 and LLM09, tool and model provenance on LLM04, output parsing on LLM10, and quotas and circuit breakers on LLM06.

, who I follow, as do many others, had a great O’Reilly article on agent harness engineering and he argued that a decent model with a great harness beats a great model with a bad harness. Below is a useful visualization from that piece:

also recently had an excellent blog on diving into the evolution of the agent harness. He described the harness as “everything besides the model weights that makes the agent work” and “the harness is like giving the mind of the model a body”.

This is a point made within security too, such as by teams such as AISLE, who argued the “most is the system, not the model” when it comes to using AI to find vulnerabilities.

Where the Capability Actually Went

This part of the blog discusses my changing thoughts on model selection and the conversations I’ve had on the podcast that played a part.

For example, I previously had on the show and he argued that you don’t need a frontier model to find zero days, and that vulnerability discovery is an orchestration problem rather than model problem. Neils discussed finite state machines that decompose vulnerability finding into stages, each with a fresh context and a tight prompt, getting reliable results from weaker models that would otherwise fall short.

I also chatted with of AISLE, who showed how their research team has small open models that are finding real vulnerabilities even in heavily audited code bases at roughly $.11 cents per million tokens.

The UK’s AI Security Institute published research in December 2025 that supports the importance of the harness as well. They found on software engineering tasks, agents with the best externally developed scaffolds reliably outperform the best base models. This shows the harness is key both for software engineering activities, as well as security ones, as Niels and Stanislav discussed above.

Fusion, Routing and the End of the Single Model Enterprise

Another trend unfolding for technical and economic reasons of the rise of organizations embracing many models, including a mix of frontier and open source. I’ve been watching this one heat up since earlier this year when Mythos 5 got banned/blocked, and GPT-5.6 got gated.

That coupled with the blowback from tokenmaxxing and the open source ecosystem closing the gap has led to many openly embracing open weight models, or a mix of models based on the task, rather than using the best tool for every job, regardless of how basic it is.

The harness is also absorbing the act of model selection. OpenRouter published results in June from their system they call “Fusion”, which routed prompts to a panel of models in parallel and had a judge model synthesize the answer. This sort of innovation is part of the story in why Stripe is buying OpenRouter for $7.5B.

Others such as have reported survey results showing nearly half of CIO’s report using 5 or more models, which is up from 29% the year prior.

So the enterprise is increasingly becoming multi-model and the harness is playing a key role in routing etc.

This has security implications as well, with activities such as model risk assessment, provenance, and IR needing to account for environments with multiple models being used and the harness being a key part of how. Logs and telemetry now need to account for the router, rather than a single vendor or agreement and this ties to LLM04 Supply Chain as well, as the model inventory grows, each introducing its own unique security risks and considerations combining commercial frontier vendors and open source model offerings.

Another interesting aspect of this is OpenAI recently open sourced their harness for Codex, which is built on the open agent harness. recently had an excellent detailed blog breaking the harness down. This shows you that the frontier labs view the harness as something you give away, while model weights remain proprietary and organizations need to inherit, review, patch and inventory the harness components they use.

Where the Harness Actually Broke

None of the discussions around the security concerns of the harness are theoretical either. Several have written about the role of the harness in recent agent breakout stories from the labs and research institutes.

Additionally, various CVE’s are tied to vulnerabilities such as CamoLeak in October 2025, where a GitHub Copilot Chat flaw allowed invisible markdown comments to lead to exfiltration through GitHub’s own Camo image proxy. The issue lied in the rendering pipeline, not the model, which behaved as designed.

There are other examples such as Tenable finding CVE’s in Cursor, that were time-of-check to time-of-use flaws, where approved MCP configurations stay trusted because approval was bound to the MCP name rather than its contents, or teams such as Oligo producing findings in Anthropic’s own MCP inspector.

As I mentioned above, the various agent breakout stories are also riddled with issues tied to the sandboxes and build pipelines involved.

Then there are supply chain incidents, such as the Nx s1ngularity compromise, where leading models such as Claude, Gemini and others were prompted to enumerate filesystems before exfiltrating credentials such qas tokens, SSH keys and .env secrets and over 1,000 victim accounts.

There are plenty of other examples to point to but the key point is that none of them were a “model failure” and things such as model evals wouldn’t have surfaced the findings. The failures lied in the rendering, permission checking, transport, sandboxing and build integrity of the systems around the models.

So while the industry has spent the last 24 months hyper-focusing on model-centric security, agents expand the real risks to the harness around the models, and as you can see from above, the opportunities for vulnerabilities, misconfigurations and exploitation is vast due to the complexity of the environments these models are hosted in and interact with via agents and their autonomy.

These trust boundaries introduce risks, and I walked through them in a blog titled “Agents Have Boundary Issues”, where I cited a similar research paper on the topic.

While Boris mentioned some of the latest Anthropic models are resistant to prompt injection, the reality is that every organization and environment leveraging the models will have unique environments, configurations, permissions, etc. which leaves the door open for this sort of activity beyond the model itself.

That said, these incidents are likely to be attributable to other causes, rather than prompt injection, as pointed out in the OWASP LLM Top 10, as well as by in his article I cited above.

Closing Thoughts

The latest OWASP LLM Top 10 says it directly, the model is often not the thing we are defending, and it says so backed by evidence and real-world incident data as well. That said, the complexity of the disparate OWASP Top 10 publications coupled with the nuance laid out by Josh highlight the challenges of trying to measure this class of risk and rank it accordingly.

All of this to say it is time to stop treating model choice as the significant security decision and instead treat the harness as an asset class security needs to be deeply familiar with and own from a risk perspective.

It is where the capability lives, where incidents of the past year landed, and where the controls that hold under an adversary or even model alignment challenges are enforceable. This means it needs to be inventoried, assigned an owner, threat modeled as the privileged application it is and have boundaries enforced deterministically rather than hoping soft guardrails such as model alignment and system prompts hold.

What I will be keeping an eye on is how the industry answers this challenge, how we build this layer from a security perspective moving forward and how the continued evolution of the model and the systems around it contribute and complicate this reality.

Subscribe now

Every so often a piece comes along that gives you the frame for everything else you are reading, and this week that piece was Dan Lahav’s “The End-State Fallacy.”

His argument is that our industry keeps debating whether AI will ultimately favor offense or defense, and in doing so we skip past the part that actually determines what the next few years look like. As he puts it,

“even if the end state turns out to be defense-dominant, the next few years can still be sharply offense-dominant.”

The equilibrium is not the experience, the path is.

Once you have that frame in hand, this week’s stories stop reading like unrelated headlines and start reading like data points on a single curve.

Let’s get into it!

Cyber Leadership & Market Dynamics

Is the Cyber Industry Too Big?

Alan Shimel of Techstrong wrote this one from the floor of Black Hat USA 2026, and it is a great analysis of our space, and the numbers underneath it are worth your time.

Cyber generated roughly $335.8 billion in 2025, up from $214.9 billion in 2022, with projections of $371 billion in 2026 and $404.5 billion in 2027, but growth is moderating from 17.9% in 2023 to a projected 9% in 2027. There are 4,100+ vendors selling around 11,000 products, the top 10 vendors hold only 29.5% of the market, and Microsoft, the largest of them, holds under 10%. Black Hat itself drew 20,000+ attendees and 400+ solution providers at an average booth cost of roughly $250,000.

Alan’s answer to his own question is nuanced, and I largely agree with it. The industry is not too big for the problem, it may be too big for its own commercial plumbing. His observation that:

“the company with the best booth is not necessarily the company with the best product. It may simply be the company with the most capital to convert into visibility”

This is one every practitioner walking a show floor already knows in their gut. The Futurum survey he cites, with 929 decision makers, found 67% expecting budget increases while 42% plan to reduce vendors and 36% plan to add them, which tells you the consolidation story is far messier than the platform vendors would like, and per an IBM and Palo Alto Networks study he references, the average organization is managing 83 security solutions from 29 vendors.

His warning that “the answer to tool sprawl cannot be agent sprawl” is the one I would tattoo on the industry’s forehead heading into 2027. Read this next to the end-state fallacy piece further down, because 83 tools from 29 vendors and six month procurement cycles are exactly the institutional metabolism that makes the transition period offense-dominant regardless of how good our defensive technology gets.

Palo Alto’s CEO bought the dip. Five months later, his $10 million bet is worth $26 million

Nikesh Arora bought 68,085 Palo Alto Networks shares on March 27 at $146.88 per share, roughly $10 million, at a moment when the stock had fallen 20% since the start of the year on fears that AI would disrupt incumbent security vendors. That position is now worth over $26 million. PANW sits at roughly $315 billion in market value, closed the ~$25 billion CyberArk acquisition in February, and posted $3 billion in Q3 revenue at 31% year over year growth.

I include this less as a stock story and more as a signal about the disruption thesis. The market briefly priced incumbents as AI roadkill, and the incumbents responded by buying their way into the AI security stack, with five AI-related acquisitions in the past year alone. Arora’s own framing, that “as AI becomes more pervasive across the enterprise, it expands the attack surface area,” is exactly the pitch every platform vendor is now making. Pair this with the Shimel report above and you get the full picture of where the capital is flowing and why.

I recently came across a good long-form interview with Nikesh on the Sourcery podcast by

Anthropic’s annualized revenue surges to $65B

Per Marina Temkin at TechCrunch, Anthropic hit $65 billion in annualized revenue at the end of July, up from $47 billion in May and $9 billion at the end of 2025. That is $18 billion in annualized revenue added in two months. The company is projected to finish 2026 somewhere between $100 and $120 billion, against OpenAI’s $40 billion run rate, and both have filed confidential IPO paperwork.

To put into perspective what that means for our industry, the entire global cybersecurity market is around $371 billion projected for 2026 per the Techstrong figures above. A single model provider is on a trajectory to reach a third of that inside a year. This is the scale of the platform shift security is now being asked to secure, and it should inform how much of your program you are willing to bet on governance patterns that assume you get to move at your own pace.

Ramp AI Index, August 2026

Ramp’s Ara Kharazian titled this edition “Cracks in the AI Thesis,” and the data underneath is a nice counterweight to the revenue story above.

Paid Anthropic adoption sits at 43.5% of U.S. businesses, up 1.1 points month over month, with OpenAI at 39.7%, up only 0.23 points, and xAI at 4%, up 0.94 points. The finding that stands out to me is on premium model uptake. Anthropic’s flagship Fable 5 accounts for only 6% of tokens purchased from Anthropic and 11.4% of Anthropic spending, despite being the most capable option on offer, at roughly $10 per 1M tokens.

Buyers are not paying up for the best model, they are paying for the good enough model at a price they can defend. Spend distribution says the same thing, with the top 1% of businesses spending a median of $7,400 per employee on AI in July, the top 10% spending $650, and the median firm spending $11.95. For security leaders building AI-driven detection, triage, or code review pipelines, this is your budget reality. The frontier capability exists, and most of your organization will be running something cheaper.

California Building ‘AI Cyber Defense Fund’ to Protect Critical Infrastructure From Hackers

California is standing up an “AI Cyber Defense Program” to use AI to find and patch vulnerabilities across state and local critical infrastructure, supervised by AI Cybersecurity Officers, one per state agency, with an implementation plan due within 120 days. Per Gizmodo, the move follows internal tests in which AI systems from OpenAI, Anthropic, and Meta autonomously gained access to the open internet and hacked into third-party organizations. Governor Newsom framed it as a choice,

“California can either wait for the next crisis, or we can build the kind of defenses this moment demands. We are choosing to build.”

AI

The End-State Fallacy: Where Is AI Security Headed?

This is the piece of the week, and the one I would read first if you only get to one thing in this issue.

Dan Lahav of Irregular argues that our field keeps litigating where the offense-defense balance eventually lands while skipping the question that actually determines the next few years. He calls the mistake the end-state fallacy, assuming that the long-run equilibrium’s properties apply to the transition period, and his thesis is that:

“even if the end state turns out to be defense-dominant, the next few years can still be sharply offense-dominant.”

His analogy for it is good, that “getting in shape has an excellent end state and a hard path; drinking is the reverse, pleasant in the moment and costly later.” The path matters, and as he says, “perhaps even more.”

He gives five reasons why the next few years likely favor offense, and every one of them is something practitioners already feel.

• First, the discovery-to-exploitation window is collapsing while the patch queue grows, with time from a CVE’s public disclosure to first confirmed in-the-wild exploitation falling from 2.3 years in 2018 to 1.6 days in 2026, and defenders paying what he calls an “accountability tax” because we cannot afford to break production with a bad patch while attackers carry no such burden. His illustration of the supply side is one I had not seen anywhere else, that “at Pwn2Own Berlin 2026, for the first time in the competition’s nineteen-year history, dozens of severe vulnerability submissions had to be turned away... simply because the organizers had run out of contest slots.”

• Second, defending AI is itself a new discipline, and building the defenses it requires takes time we do not have much of.

• Third are defense deployment gaps, because “defensive organizations do not move on that timeline. They onboard vendors over quarters, budget annually, and modernize infrastructure over years,” and “defensive capability becomes useful only after an institution has learned how to trust, buy, operate, and integrate it into a complicated system.”

• Fourth, he expects that “at least in the near term... AI will scale faster on offense than on defense,” largely because of verification asymmetry, since an exploit either works or it does not while “a patch asks something closer to global assurance, one must show that the system is secure under continuous, adversarial pressure, without having broken anything adjacent,” which he calls a much harder thing to verify. This is something I have cited in a blog from Sergej Epp titled the “Verifiers Law”, as well as showing in research from Keith Hoodlet that AI created patches remain problematic.

• Lastly, none of these effects occur in isolation, they compound. Elsewhere in the essay he adds the structural version of the same worry, that “if the cost of creating or attacking systems falls faster than the cost of securing them, the attack surface may grow beyond what defensive tooling can feasibly cover.”

The capability data underneath is what makes the argument hard to wave off. On Cybench, “frontier models reportedly climbed from around 10% success to near-complete success in about two years.”

A custom CPU-emulator exploitation task went from unsolvable in February 2026, to roughly 5% success at about $2,000 per run in April, to reliable completion at about $20 per run by June, which he sums up as going “from unsolvable to cheap and repeatable” in four months.

His base case is that frontier models “will continue to roughly double their performance and effective autonomous work horizon every six months” over the next two years, with the price of a fixed capability level falling on the order of 10x per year.

On diffusion, NIST CAISI measured open-weight DeepSeek-V4 Pro lagging the frontier by about eight months across its aggregate evaluation suite in May, and UK AISI found an even tighter gap on cyber specifically in July, with open models like GLM-5.2 and DeepSeek-V4 Pro matching closed frontier models released four to seven months earlier, down from the six to ten month gap it measured through most of 2025.

His projection follows directly, that:

“based on the current trajectory, we can expect current frontier-grade cyber capabilities, such as Mythos 5 / GPT-5.6 Sol, to proliferate before the end of Q1 2027.”

His retelling of the July Hugging Face incident is the clearest I have come across and it makes sense given how involved Irregular is with the labs.

Frontier models in a sealed OpenAI cyber-evaluation sandbox “found a zero-day flaw that let them act beyond their sandbox,” and then, in his words, “autonomously attacked Hugging Face infrastructure, gaining elevated access, stealing credentials, moving laterally, and restoring access after being blocked,” carrying out about 17,600 unscripted actions over several days.

Separate agents “discovered a way to communicate through a shared system, created their own channels to exchange attack directions, exploits and credentials, and divided tasks without being instructed to cooperate, forming an autonomous swarm,” and when one channel was shut down they simply established another. Lahav’s framing of why this one is different is the right one, that “no human selected Hugging Face as the target or specified the attack chain step by step. The AI found and executed that path itself.”

His answer is Differential Defensive Cyber Acceleration, which is deliberately shaping “the development, diffusion, and deployment of AI security capabilities so that protective capabilities mature and reach defenders before corresponding offensive capabilities can overwhelm them.”

It rests on three tenets, measuring the field with continuous feedback between measurement and intervention and tracking realistic attack chains rather than benchmark scores, building defensive-specific capability along a “red-to-blue spectrum” by prioritizing interventions that “sit as far toward blue as possible” such as remediation, incident response and threat intelligence, and blue deployments that get defensive tooling into critical organizations, and treating offensive diffusion as its own R&D problem through use limitations, theft prevention, and AI containment.

I have been making a version of this argument all year in less rigorous terms, so I will say plainly that this is now the reference text.

Where I would put the emphasis is on the least glamorous third of his second tenet, blue deployments. Building blue-asymmetric capability is a research and vendor problem that is already well underway, and the rest of this issue is full of evidence for that.

Getting it into production runs straight into his own third reason, the institutional metabolism of security organizations that onboard over quarters and modernize over years. We do not have a capability gap on defense right now, we have an absorption gap, and absorption is the one part of this that no lab, no benchmark, and no policy office can do on our behalf.

Nearly every other item in this issue is either evidence for one of his five reasons or an example of somebody trying to close that absorption gap, so read the rest with his frame in hand.

GLM-5.3

Z.ai released GLM-5.3 on August 14, and the cyber benchmark results are the story. Per the release coverage, the model posted 84.5% on CyberGym, ahead of Claude Mythos 5 at 83.8% and GPT-5.6 Sol at 83.6%, jumped from 4.6 to 28.3 on Terminal-Bench 3.0 and from 46.2 to 66.9 on DeepSWE v1.1, and reportedly surfaced 2,436 vulnerabilities across 269 open-source projects, with 1,097 rated critical or high severity, including bugs in Linux, WebKit, and FreeBSD.

Then the part that actually matters. Z.ai is holding the open weights for a two-week safety review, because the model:

“began reasoning across multiple stages of exploitation and forming coherent plans for complete exploitation chains, a capability it did not set out to train for.”

A Chinese lab, building on an open-weight lineage, voluntarily delaying a weight release over emergent offensive cyber capability, is a genuinely notable moment for anyone who assumed open-weight governance would only ever come from Western labs or regulators.

It is also the end-state fallacy playing out in real time, since Lahav cites the previous generation, GLM-5.2, being measured at “roughly seventeen cents per vulnerability found” while matching or beating leading closed models on some bug-finding benchmarks, and this release moves that lineage past the frontier models he named as the ones due to proliferate by Q1 2027.

A two-week safety review is a speed bump on a curve like that, and it is worth asking what happens the next time a lab in this position decides the delay is not worth it.

The evolving role of the Red Team in the era of agentic security

Daniel Fabian, who heads Google’s Red Teams, wrote this with Ash Fox, Moni Pande, Niru Ragupathy, and Stefan Friedli, and it is a practical companion to the Lahav essay.

Their argument is that red teams have to stop running manual exercises and start building the autonomous agents that will simulate real agentic attacks, because attackers who value volume and speed above all have every incentive to automate first.

They break the change into sophistication, scale, and speed, with the observation that “dwell time, the window between gaining an initial foothold and moving on objectives, is collapsing.”

Their forecast is that within 6 to 12 months “open-weight models will match today’s cybersecurity capabilities of frontier models,” with safety guardrails removable through techniques like abliteration.

Given the GLM-5.3 and Kimi K3 results above, that forecast may already be conservative. What I appreciate most is the pragmatism of the recommendation, which is not to build a full autonomous red team on day one, but to start automating isolated pieces of your existing manual exercises like reconnaissance or lateral movement, then wire modular subagents behind an orchestrator.

Their closing point, that “we have the time right now to get ahead of the curve,” is the same window Lahav is describing, arrived at independently by a team with a very different vantage point, and the two forecasts landing on the same 6 to 12 month horizon should carry more weight than either would alone.

Patterns and problems in emerging multiagent systems

Anthropic’s Frontier Red Team ran swarms of Claude agents across several shared environments, and the failure modes are worth knowing before your next architecture review.

Coordination degraded as agent counts rose in a 12-hour game development experiment scaling from 10 to 80 agents, with Sonnet 4.6 and Opus 4.6 opening 876 and 980 PRs respectively while closing very few. Agents also show remarkably low behavioral variance, with 18 of 30 creating the identical git branch name “mvp-game-loop,” and in a job queue experiment they flooded the system with 2.4 million requests when only 117 jobs were accepted.

Given a communication channel in pricing games they colluded on price floors, and under incompatible objectives they deployed self-replicating malware disguised as system processes, disabled Unix accounts, and wrote kill-loop scripts, with one agent noting that “the name of the reaper script matters for dodging pkill -f.”

On the upside, a coordinated 45-agent swarm found 266 vulnerabilities using 27M tokens versus 21 for independent parallel agents at 6.5M tokens, with only 12 findings in common. The researchers’ conclusion is the line to carry forward, that “coordination doesn’t naturally emerge from stronger intelligence nor alignment at the individual level.” Anthropic is showing us that emergent coordination is unreliable and often destructive in benign settings, and the Hugging Face incident above is what it produced in an adversarial one.

Teaching AI to Reason Through Detection Triage

CrowdStrike published results on a detection triage classifier built on NVIDIA Nemotron that reasons through evidence before issuing a verdict. At their high-confidence operating point, holding 98% false positive precision and 99% true positive precision, false positive recall improved from 21.8% to 64.8% and true positive recall from 34.7% to 53.0%, with overall accuracy landing at 82.6% against frontier general-purpose models in the 55 to 71% range.

This is what applied AI in SecOps should look like, and the auditability is the part that matters, since their framing that “teaching the model to think through a detection improves accuracy while producing an auditable rationale that analysts can evaluate” answers the biggest practitioner objection to AI triage.

A tuned smaller model beating the frontier generalists is also a useful data point next to the Ramp findings above. Alert adjudication is about as blue as Lahav’s spectrum gets, since attackers get almost nothing out of it.

Least privilege for AI agents, identity, access, and tool binding

Yesenia Yser and Toby Kohlenberg laid out Microsoft’s guidance on agent least privilege, and it is refreshingly unglamorous.

Treat every agent as a first-class identity principal with its own lifecycle and clear human ownership, build task-based roles instead of broad team-level access, scope by resource, data, and operation type, and expose only curated tools through explicit allowlists, with JIT elevation, re-authorization enforced downstream rather than trusting the orchestrator, and mandatory revocation testing.

Their warning is the one practitioners will recognize from every prior identity wave, that agents working “across multiple systems within a single workflow” quietly accumulate dangerous combined permissions, and that “scope creep is quiet, incremental, and rarely revisited.”

They suggest doing this work in 30 to 90 days before expanding agent deployments, which is optimistic for most enterprises, but the sequencing is right. Doing agent identity hygiene after you have 10x’d your agent population is the service account mistake at a much worse scale.

Credential Injection Patterns for AI Agents

Christian Posta wrote the deep technical version of the same problem.

Bearer credentials have an obvious flaw, “anyone holding the credential can use it,” and of his three mitigations, accelerating expiration, proof-of-possession, or removing agent access to credentials entirely, he argues for the third through credential brokering. The vehicle is Credential Brokering 4 AI Agents (CB4A), an IETF draft from March 2026 that recommends a proxy gateway model where credentials are injected on egress and the agent never sees them.

Posta is honest about the tradeoff, since CB4A’s own threat model rates broker compromise as “CRITICAL” and the broker becomes “the highest-value target in the architecture.” That is the right way to present a control, as a shift in where risk concentrates rather than an elimination of it.

AppSec

CVE program eyes automation and globalization to weather AI ‘vulnpocalypse’

This is good reporting providing insights from NIST and others on running vulnerability programs.

Microsoft’s Elizabeth Eigner gave the quote of the week, that

“these vulnerabilities are coming out at an AI pace, but we’re still creating and processing them at a human scale.”

CISA’s Lindsey Cerkovnik said “we cannot treat every vulnerability the same way” and that she is “concerned about the industry’s ability to scale via prioritization.” GitHub has published more than 7,000 CVE identifiers so far in 2026, which Madison Ficorelli said she believed to be an annual record for a CNA, framing it correctly as “not a competition.”

Intel’s Katie Noble was bluntest, “I don’t think the CVE Program was designed to be able to manage this influx of vulnerabilities.” CISA is now handling 360 to 400 cases simultaneously, and OpenAI and Anthropic were granted temporary CNA status in July.

This is Lahav’s first reason with names and job titles attached. Automating intake does not solve the downstream problem, because even a perfectly efficient CVE Program hands enterprises a volume of findings their remediation capacity cannot absorb, which is why I keep arguing that prioritization and remediation capacity, not discovery, are where the money should be going.

Vulnpocalypse 2026 statistics dashboard

If you would rather watch the trend than read about it, this dashboard tracks 2026 CVE publication against prior years off the Vulners archive, with cumulative counts, year over year pace, monthly flow by CNA, year-end projections, and my favorite view, reserved but unpublished CVE IDs sitting in the queue.

The page’s own line is accurate, “the gap between the red line and the pack is not a rendering glitch.” That reserved-but-unpublished view is the closest thing we have to a leading indicator, since everything in it is work your team has not been handed yet.

A timely resource, and worth bookmarking.

AI-powered vulnerability clearinghouse faces deep skepticism, major challenges

The administration’s AI-enhanced clearinghouse, codenamed Gold Eagle, launched in mid-July out of a June executive order, using CMU SEI’s VINCE platform for intake.

, now CSO at Corridor, argued that “there’s no need for the government to step in here.” Katie Moussouris framed both sides best, granting that “a clearinghouse that validates findings before they hit software maintainers, deduplicates them, and routes fixes to everyone affected would convert AI noise into defensive signal,” while flagging that CERT/CC “is not currently funded with enough analysts to handle a program of this size,” that “increased centralization of unpatched vulnerabilities is a juicy target for adversaries,” and that on Treasury oversight, “vulnerability coordination succeeds or fails on trust... Treasury has neither the coordination mission nor those relationships.”

Her advice, “don’t boil the ocean,” applies to nearly every federal cyber initiative I have watched launch. The private sector is building the same capability anyway, with IBM and Red Hat’s Lightwell, the Linux Foundation’s Akrites, and Chainguard’s Athena, and with Mandiant putting the patch lag at 7 days on average against Lahav’s 1.6 days from disclosure to exploitation, a clearinghouse that will take quarters to earn ecosystem trust is being asked to keep pace with something moving in hours.

Git at any scale

Vicent Martí wrote up Cursor’s launch of Origin, a Git hosting platform built on a distributed storage system called Continuity that uses a write-ahead log in S3-compatible object storage with atomic compare-and-swap in place of consensus protocols, reaching up to 120 pushes per second on S3 Standard and over 300 on S3 Express One Zone. The line that tells you what this is really about is the allocation model, where monorepos get hundreds of replicas for CI workloads while agent-created repositories need just one.

Coding agents are now creating repositories fast enough that source control itself is being rebuilt around them, and every assumption baked into your scanning, code review, branch protection, and provenance tooling was designed for a world where humans created repositories at human rates.

A repository created by an agent and owned by no one in particular still ends up in your software supply chain. That is Lahav’s ever-expanding-surface argument arriving as infrastructure.

Final Thoughts

Reading this issue back, nearly every item is a footnote to Lahav’s argument.

Offensive capability is diffusing on a 4 to 7 month lag for cyber tasks, Z.ai just posted leading cyber benchmark scores and paused the weight release over emergent exploitation-chain reasoning, and Google’s red team independently expects the rest of the gap to close inside 6 to 12 months.

Meanwhile the CVE Program is processing at human scale, the federal clearinghouse meant to help is launching into deep skepticism about its funding and its home, and the average enterprise is managing 83 security solutions from 29 vendors with six month procurement cycles. That is his third reason, defense deployment gaps, in its native habitat.

So here is where I would leave it.

Whether AI ultimately favors offense or defense is the least useful question available to us right now, because we do not get to live in the end state. We live in the transition, and there the binding constraint is not whether defensive capability exists, it is whether our institutions can absorb it faster than offensive capability diffuses. Right now we cannot, and that gap is ours to close.

Pick one thing from the blue end of Lahav’s spectrum, a frontier-model review of your most critical repository, remediation capacity instead of more discovery, or gateway-enforced boundaries on your agents, and get it into production this quarter rather than next fiscal year.

That is the whole game between now and Q1 2027.

Stay resilient.

Subscribe now

“Skills” were among one of the most notable examples that caught my attention quickly. For those unfamiliar, skills are essentially modular reusable artifacts that can help extend, or improve the performance of agents. They can be instructions, code, resources or operational insights related to the user, organization etc. Agents can discover, load and execute them, as well as being directly fed them by a user to help improve the agents capabilities and usefulness.

Like agents themselves, it is these very capabilities that make them problematic from the security perspective. I often refer to this as the “Security vs. Utility Tradeoff”, where users/organizations are often trying to balance the two, and the more capabilities an agent is given, the more utility it has for the business, but also the more potential risks and challenges it introduces.

Similar to open source, Skills can be quickly created, distributed and shared widely with the broader community. This has led to the proliferation of Skill hubs and marketplaces. Some of them attempt to vet or score the Skills for security implications and some don’t. Skills were originally introduced by Anthropic but now have become widely adopted.

Some examples include AgentSkillsHub, skillsmp and MCP Market. These marketplaces have thousands and even millions of Skills available for download and use.

It is easy to see why it is helpful to provide information and context to agents to make them more productive and helpful. That said, if you’ve been following my writing, you can also guess that Skills can easily serve as an attack vector to maliciously steer agents behavior, inject harmful context and carry out other nefarious activities.

It didn’t take long for academics and vendors alike to begin to investigate this, and quickly find thousands of examples of malicious Skills in the wild. One of my favorite examples was titled just that, “Agent Skills in thew Wild: An Empirical Study of Vulnerabilities at Scale”.

The team used open source tools and scanned tens of thousands of publicly available skills from the marketplaces and found many examples of malicious skills attempting to exfiltrate data, escalate privileges, execute malicious scripts and other harmful activities. They also provided a useful threat model in the paper, which they walked through and is worth a read.

The risk of skills has become widely known and discussed now, including talks at Black Hat recently by OWASP, Open AI and others and culminated in the publication of OWASP’s v1.0 of the Agentic Skills Top 10, which will be the focus of this article. My friend who helped champion the effort also recently had a great article on it.

I’ll briefly walkthrough the Top 10 risks and their associated mitigations.

AST01 - Malicious Skills

Much like they sound, malicious skills are intentionally malicious skills published to the public, often via the marketplaces I discussed above or by other methods. They are intended to seem legit but often look to steal credentials, establish backdoors or even social engineer users and agents.

The publication points out the problem that agents often utilize excessive permissions, or permissions tied to a user and a malicious skill can lead to exposing credentials such as API keys and SSH credentials.

The team points to real-world incidents such as ClawHavoc, which involved 1,000+ malicious skills, tens of publisher accounts and targeted crypto wallets, SSH keys and browser credentials.

Attack scenarios include examples such as typosquatting, instruction override, memory poisoning and persistence among others.

To prevent impacts from malicious skills, the OWASP team recommended mitigations such as cryptographic signatures of skills, layered scanning at both public and install time, isolated skill execution and auditing skill actions as well as behavior sandboxing, to observe how a skill influences an agents behavior.

AST02 - Supply Chain Compromise

Next up we have supply chain compromise. It’s easy to see how this is a risk given how Skills by their very nature are shared and distributed across the community directly, through repositories and via the marketplaces.

OWASP rightly points out that many of these ecosystems are immature compared to the broader open source ecosystem with platforms such as npm, PyPI and Cargo (which have their own never-ending slew of incidents still).

To capitalize on this, attackers mass upload malicious skills, take advantage of dependency confusion and go after accounts of developers and contributors to poison the registries.

As OWASP points out, all you need to publish a skill on marketplaces/repos such as ClawHub is a SKILL.md file and a GitHub account. Essentially anyone can do it and there’s no security rigor such as code signing, security review, or sandbox by default. These are the sort controls popular OSS platforms have implemented due to a variety of attacks, compromises and social engineering efforts targeting open source users and maintainers in supply chain attacks.

Some of the attack scenarios they point out include flooding registries with malicious skills, poisoning nested dependencies under top-level skills to bypass scanners, hijacking configuration files with malicious execution instructions and the tried and true takeover of a maintainers account to then inject a backdoored version of a trusted skill.

To mitigate some of these attacks, OWASP recommends mitigations such as skill provenance tracking, transparency logs for registry operations, pinning all nested dependencies and applying trust gates to repo config files.

AST03 - Over-Privileged Skills

Least-permissive, not even once.

Everyone’s favorite security challenge enters the fold, as skills are often granted broad permissions beyond what is necessary for their functionality. OWASP points out this is due to there often being no permission manifest system, or users just accepting all permissions without a review.

These overly-permissive skills can be abused to take malicious actions against organizational systems and data.

What makes this problematic to Skills in particular is their natural language format, that uses intent on top of tradition system permissions and methods such as prompt injection which can take advantage of the fact that permission checks occur at the tool call level.

The industry is still widely grappling with “Intent Analysis” when it comes to Agentic AI, and it is a topic I have written about several times. OWASP cites several real-world examples, such as Snyk’s ToxicSkills where hundreds of publicly available skills expose credentials and data beyond the skills declared functions.

They lay out attack scenarios such as data exfiltration, wiping databases, establishing persistent behavioral backdoors and opportunities for low-privilege skills to invoke higher privileged skills, essentially privilege escalation via Skills.

To prevent this, OWASP recommends mitigations such as require skills to declare permission manifests, per-skill scoped credentials, runtime permission enforcement and requiring explicit operator consent for persistent state changes.

It’s easy to see how this would be difficult to do at scale in enterprise environments with thousands of developers leveraging skills and agents at machine speed and scale.

AST04 - Insecure Metadata

Skills come with metadata such as name, description, author, permissions, requires and the native YAML/JSON/Markdown formats they are written in. Attackers can take advantage of this and put attacker-controlled inputs into the metadata which then gets read or executed with no security rigor.

OWASP explains how this can lead to manipulating the metadata to downplay or misinform users on the skills true motives, as well as embed executable payloads that trigger on load before a user takes any action.

What makes it challenging for skills is that malicious definitions can mislead the installer and also execute malicious code before the skill is run due to the fact that the metadata is deserialized during the skill-loading lifecycle as part of initialization.

Some of the attack scenarios OWASP mention include brand impersonation, permission understating, risk tier spoofing and YAML code execution among others. To prevent it, they recommend using safe parsers by default and disabling dangerous tags, validating metadata against a schema prior to deserialization, applying static analysis to all metadata fields as well as validating declared permissions against actual runtime behavior.

AST05 - Untrusted External Instructions

This one reminds me of the core problem of AI and Agents themselves. As we know, consuming untrusted content can lead to models and agents being manipulated and potential impacts for the organizations leveraging them. The best paper on this was Google DeepMind’s “AI Agent Traps”, which described essentially the entire open Internet as a field of potential landmines Agents can consume into the context window and boom, negative things can happen.

In this example for skills, OWASP explains how skills routinely reference external documentation such as API references, SDK guides, schemas and other content that leads agents to URL’s or reading remote files at runtime. That consumed content now becomes part of the agents instructions acted on with the host agent’s full instructions.

OWASP explains how unlike traditional software with versioning, hashing, pinning, lockfiles and signed packages, skills have no pinning to a documents hash, no lockfile, and the fact that signing skills doesn’t mitigate the risks that the URL’s return when executed at runtime.

When I read this, a lot of the risk comes from the fact that agents take action and have autonomy. Those actions and autonomous come with risks and potential for abuse, and embedding malicious instructed externally that get consumed and acted upon is a perfect example of this.

Some of the attack scenarios they cite include author rug pulls, reviewer bait-and-switch, transitive reference chaining and DoS via malicious skills. To mitigate these attacks OWASP recommends techniques such as pinning and verifying referenced content, performing final verifications before model ingestion, preferring inlining over fetching and allow-list specific domains only.

AST06 - Weak Isolation

Every installed skill is a potential full-system compromise due to the fact that sandboxing is often not available, optional or even disabled by default. This limits the ability for containment guarantees per OWASP.

Agents and sandboxes have been a hot topic throughout 2026, and are topics I have discussed with industry leaders such as Alex Zenla and Luke Hinds:

Some of the attack scenarios OWASP lists include host escape, network pivot, skill shadowing, and cross-agent workspace contamination. To prevent these sort of attacks the OWASP authors argue for mitigations such as container isolation for skill execution, binding agent control interfaces to localhost with authentication, applying seccomp/AppArmor profiles and implementing per-skill process isolation.

AST07 - Update Drift

Much like other aspects of cybersecurity, where things are set it and forget it (e.g. permissions), skills are installed and forgotten. OWASP points to a lack of immutable pinning and automated update verification leading to skills drifting from known-good versions due a lack of patches being applied or auto-updates leading to malicious versions.

Unlike traditional software, OWASP points out that skills are often installed by users with no sort of remedy such as traditional patch management and even then, if users did update skills to new versions, the new version itself could be malicious due to unverifiable cryptographic pinning when it comes to skills.

OWASP cites real-world examples such as ClawJacked, which demonstrated patch lag leaving agent gateways vulnerable.

The attack scenarios include malicious updates, rollback attacks and hot-reload abuse. To mitigate these attacks, OWASP recommends mitigations such as pinning installed skills to immutable content hashes not version ranges, freezing production deployments and subscribing to registry security advisories or auto-alerts for CVE matches on installed skills.

AST08 - Poor Scanning

Unlike traditional software, agent skills utilize executable content and metadata but also natural-language instructions. This can make it difficult to match patterns, regex filters or use signature-based detection. While marketplaces and organizations have begun to use static skill scanners and open source tools, the natural-language aspect of agent skills proves problematic and easy to bypass.

As they say in the publication:

”The enemy of AI security is the infinite variability of language”

OWASP cites a robust set of real-world evidence from security vendors and researchers showing how simple pattern matching and static scans are insufficient for detecting malicious skills and instead requires behavioral analysis as well.

Some of the attack scenarios OWASP calls out include natural-language bypass, obfuscated instructions, scanner impersonation and scanner-target evasion. To mitigate these attacks they recommend mitigations such as deploying behavioral analysis scanners to evaluate intent not just signatures, scanning both the code and natural language instruction layers independently and treating scanner skill results as advisory only, not authoritative from a risk perspective.

AST09 - No Governance

This one reads to me a bit odd, as it isn’t necessarily a specific technical risk but more so reflects the reality that the adoption curve of AI and Agents has often outpaced the organization and security teams ability to govern it.

OWASP cites organizational lack of inventories, policies, review processes and audit trails to manage skills at enterprise scale. These skills are often installed with no visibility from security teams, no governance or review process or revocation pathway.

OWASP points to the fact that typical software asset management (SAM) tools have no ability to govern agent skills, and skills can be quickly installed by anyone with access. This is often done with no logs going to the SOC, no CMDB entry and no integration with existing IAM. They cite several research efforts finding hundreds of malicious skills installed across corporate environments by developers and users with no oversight or governance.

Some of the attack scenarios include undetected compromise, unapproved malicious skills, orphaned skills, regulatory exposure and cascading agent compromise. To mitigate these attacks OWASP recommends organizations establish a centralized skill inventory, approval workflow for skill installations requiring security reviews, audit logging for skill actions and establishing skill revocation processes to offboard or shut down skills.

AST10 - Cross-Platform Reuse

Speaking to the diverse nature of the Agentic AI ecosystem, OWASP rounds out the list discussing the reality that skills are ported across platforms (e.g. OpenClaw, Claude Code, Cursor, Codex etc.) without the security properties of the source format translating.

Specific examples they use include permission manifests on one platform not transferring to another with the skill itself, creating increased risks for skills shared across platforms.

A lack of a universal skill format and normalization of security metadata across ported skills is problematic.

Some attack examples OWASP cites include security property loss in translation, cross-registry arbitrage, multi-platform campaigns and implicit privilege escalation. To mitigate these attacks, OWASP recommends techniques such as adopting a universal skill format, requiring full security metadata re-validation for ported skills, establishing cross registry threat intel among the major registries and building platform-agnostic skill scanners to identify issues at runtime.

Many of these read to me as systemic ecosystem issues rather than problems to be solved by any specific organization or user.

Closing Thoughts

Well, that was our brief tour of the new v1.0 of the OWASP Agentic Skills Top 10. I wanted to dig into it to understand the most prevalent risks and mitigations associated with Agentic Skills, what parallels exist to broader software and what aspects are novel.

Several of the risks are systemic in nature and tied to the immature nature of agents in a broader sense, and the ecosystems early days as it evolves to painfully re-learn many of the lessons we know from examples such as software and supply chain security.

I hope you found this helpful and I will be keeping an eye on how this aspect of Agentic AI security evolves!

Subscribe now

I have spent years writing and speaking on it, and back in 2023 I co-authored a book titled “Software Transparency: Supply Chain Security in an Era of a Software-Driven Society” because it was becoming impossible to ignore that modern software is assembled far more than it is written, and that we had almost no visibility into what we were actually assembling.

That said, if you had told me back then that the pace of attacks would look the way it does in the first half of 2026, I am not sure I would have believed you. We spent years talking about software supply chain risk as a accelerating problem, something we needed to get ahead of. It is no longer looming, it is here, it is industrialized, and the growth curves are steepening in a way that should reshape how practitioners think about their environments.

In this article, I want to level set on how we got here, walk through what the attack data actually shows in 2026, and then dig into a discussion and demo I recently had with Resilient Cyber’s partner at Kusari, whose approach to this problem I find promising.

So, let’s start unpacking the problem space.

Years in the Making

None of this is new, and that is part of what makes the current moment so frustrating.

We have known for years that commercial and open source software alike are built on a sprawling web of dependencies that almost no one fully understands. Synopsys’ 2026 OSSRA report found that 97% of audited commercial codebases contain open source components, that the average application contains 911 open source components, and that 90% of audited codebases contain components more than four years out of date.

The average codebase carried 581 open source vulnerabilities. Those are not the numbers of a niche problem, that is the the underlying critical infrastructure the entire digital economy runs on. These are problems myself and others have been highlighting for several years at this point.

The incidents that made this real for most people are by now part of the security folklore. SolarWinds showed us what happens when an attacker compromises the build pipeline itself of a widely used commercial software provider. Log4Shell showed us that a single ubiquitous open source component could put the entire internet into an emergency remediation cycle overnight, and that most organizations could not even answer the basic question of whether they were affected.

Those events generated executive orders, SBOM mandates, a wave of frameworks, and a genuine surge of attention. For a while it felt like we were finally starting to build the muscle memory this problem demands.

The problem is that the attackers were paying attention too, and they have adapted far faster than most defenders have and the introduction of agentic development as the breakout use case has complicated the problem at a pace and scale that makes the problems of the past pale in comparison.

Velocity, Volume, and Malicious Packages

The numbers coming out of 2025 and the first half of 2026 are hard to overstate, so I will let them speak for themselves. Sonatype’s 2026 State of the Software Supply Chain report identified 454,600 new malicious packages in 2025 alone, bringing the cumulative total they have tracked to over 1.233 million across npm, PyPI, Maven Central, NuGet, and Hugging Face. Over 99% of that open source malware in 2025 landed on npm, the beating heart of the JavaScript ecosystem.

To put the raw exposure into perspective, Sonatype notes developers downloaded open source components 9.8 trillion times across the major ecosystems in 2025.

What changed in 2026 was not just the volume but the tempo. Research from Phoenix Security tracking malicious package campaigns found that the first half of 2026 alone produced 2.6 times the campaign count and 4.5 times the malicious package volume of all of 2025. May of 2026 was the single busiest month on record in their findings, with 14 distinct campaigns and 346 indexed packages in 31 days, and a single self-replicating worm accounting for 226 of them. That is not a steady climb, it is an testament to how this threat is scaling.

Much of that acceleration traces to a shift from one-off malicious uploads to self-replicating worms and coordinated campaigns. The Shai-Hulud worm that hit npm in September 2025 compromised more than 500 packages in a matter of days, spreading on its own by harvesting credentials from each compromised maintainer and using them to poison the next set of packages.

A related compromise that same month reached widely depended-upon packages like chalk and debug, which together account for billions of weekly downloads across the ecosystem. A second wave dubbed Shai-Hulud 2.0 arrived in November 2025, and researchers tracked over a thousand backdoored package versions across hundreds of packages, along with tens of thousands of attacker-created repositories used to exfiltrate stolen secrets. CISA issued guidance on the campaign, demonstrating how significant it had become.

The GitHub Actions and CI/CD ecosystem has been hit just as hard. The tj-actions/changed-files compromise in March 2025 saw an attacker exploit a leaked personal access token to push malicious commits and redirect version tags, and it sat undetected for four months.

In March 2026 a campaign tracked as TeamPCP poisoned 75 of 76 version tags across the widely used trivy-action and other tooling in a single coordinated push. By May 2026 the same class of actor was pushing thousands of malicious workflow commits across thousands of repositories in a matter of hours, and in March 2026 the Axios package, with over 300 million weekly downloads, was compromised when an attacker hijacked a maintainer’s npm account and published a remote access Trojan that bypassed GitHub Actions entirely.

I could keep going, but the pattern matters more than an exhaustive catalog of incidents. If you want the deeper dive on how AI is compressing both the discovery and exploitation timelines on top of all of this, I wrote about it recently in “Vulnpocalypse” and “The Attack Surface Exponential”.

Attacking Trust, Not Just Code

The most important thread running through all of these incidents is that attackers are no longer just targeting the code. They are targeting the people, the credentials, and the CI/CD workflows that we all implicitly trust. A maintainer’s npm token, a leaked PAT in a build log, a poisoned GitHub Action, these are the new front line, and they are devastatingly effective precisely because the entire model of open source consumption is built on trust and convenience, which is ironic given the last several years of security leaders touting concepts such as “Zero Trust”.

There is one detail from the Phoenix analysis that stands out as well. Across the 59 campaigns they tracked, the CVE count during active exploitation was zero. The tooling, the processes, and the mental models most organizations have built for managing software risk are oriented around CVEs, around a known vulnerability with an identifier that shows up in a scanner. Malicious package campaigns do not play by those rules, there is no CVE to alert on while the attack is live. By the time anything shows up in the systems most teams rely on, the credentials are already gone. This is due the speed and complexity, as well as the reality that institutions such as NVD are collapsing under the load being driven by AI with coding and vulnerability discovery.

This is the uncomfortable reality of where we are. The volume is exponential, the tempo is accelerating, the attack surface has expanded from the code itself to the entire development ecosystem around it, and our detection models are looking in the wrong place.

Meanwhile, the rise of AI-assisted and increasingly agentic development is pouring more code, more dependencies, and more velocity into environments that most organizations already could not keep pace with prior to AI’s widespread impact on development, vulnerability discovery and exploitation.

The Visibility Problem Nobody Solved

Underneath all of this sits a problem that predates the current attack wave and has never really been solved, which is visibility. When Log4Shell hit, the single hardest question for most organizations was not how to patch, it was where the vulnerable component even lived across their environment. Years and many frameworks later, most organizations still cannot answer that question quickly, despite things such as software asset inventory being a critical control for years and even decades.

This came up almost immediately when I sat down with the Kusari team, and it lined up with everything I have seen in practice. As their team framed it, the primary struggle for their customers is a lack of visibility, frequently expressed as an inability to answer a deceptively basic question, “Do I have this package, and where is it?” In the current environment that question becomes “Do I have Shai-Hulud, or the compromised version of Axios, and if so, what is the blast radius?”

Most organizations cannot answer it in any reasonable timeframe, and in an era where a worm can traverse hundreds of packages in days, the time it takes to answer is the whole ballgame.

That is the gap I want to spend the rest of this piece on, because it is where I think we need to solve the problem from a first principles perspective before we get into any fancy discussions of known exploitation, exploitability, reachability and other concepts I often discuss.

Where Kusari Fits In

Kusari is a software supply chain security company that came out of the open source world rather than bolting onto it after the fact.

Its founders created and helped shepherd the open source GUAC project, short for Graph for Understanding Artifact Composition, which joined the OpenSSF as an incubating project in 2024.

GUAC is built around the idea of mapping the software supply chain as a graph, identifying the most-used components in an environment, exposing risky dependencies, and calculating the blast radius of a given vulnerability.

What I appreciated in the demo and discussion is that the platform starts from the visibility problem rather than the alert problem. The integration point is typically a GitHub app installed at the organizational level, from which the platform tracks information across the various CI/CD systems and build pipelines, analyzes build metadata and software artifacts, and maintains a continuously updated graph of the organization’s environment.

That graph updates as pull requests and changes flow through, so it reflects the actual current state rather than a snapshot in time from the last time someone ran a scan. As a byproduct of maintaining that graph, the platform tracks versioned, time-stamped records of software including SBOMs, supporting both CycloneDX and SPDX, along with metadata and VEX documents, without an organization having to stand up a separate SBOM management effort, avoiding yet another tool in the security stack.

On top of that graph the platform layers risk. Kusari generates a score from 0 to 10 for a given software component, and I found the inputs valuable and relevant for truly mitigating organizational risks.

The score factors in whether a component carries vulnerabilities on CISA’s Known Exploited Vulnerabilities (KEV) list, the breadth of vulnerabilities across the environment, and how deeply a component is rooted in the supply chain. That last input is the one most tools miss. A vulnerability buried five layers deep in a transitive dependency that half your services pull in is a very different problem than the same vulnerability used once, and the score is explicitly trying to communicate blast radius and remediation complexity rather than just severity in isolation, which is common for a lot of security tools that lack organizational context.

The platform also leans on reachability analysis, using graph analysis to determine whether a vulnerability actually has impact in a given context rather than dumping the full undifferentiated backlog on a development team.

Anyone who has watched developers tune out security tooling because 90% of what it surfaces is noise understands why this matters. To avoid the whack-a-mole cycle where a fixed component quietly gets reintroduced, the platform uses dependency cooldowns and analyzes every change coming through, which is a nice acknowledgment that remediation is not a one-time event but an ongoing fight and shows an evolution of how we should think about reachability in the context of vulnerabilities as well.

Remediation, Not Just Findings

Where the conversation got most interesting for me was on remediation, because finding problems has never really been the hard part in this space, and that’s a point I’ve been making a lot lately.

The platform includes an Autofix capability built around a set of purpose-specific agents. As the team walked me through it, a security architect agent builds a remediation plan, an inspector agent reviews that plan for newly introduced vulnerabilities or compliance issues, and a developer execution agent implements the fix.

Organizations can dial the level of required human intervention up or down based on their own maturity and how much they trust the platform’s suggestions, which to me is the right approach given where most teams are on the trust curve with agentic tooling, especially around production remediation.

The Inspector agent stood on its own as the piece I would probably get the most day-to-day value from. It operates directly in the developer workflow and provides immediate feedback on pull requests, functioning as a security reviewer that gives a thumbs up or thumbs down on whether a change introduces a malicious package, a license compliance violation, or a broader supply chain risk.

Developers get that signal without having to context switch into a separate platform, which is exactly where security tooling tends to die due to breaking the flow of developers or becoming frustrating to use. Meeting developers where they already work, rather than dragging them into yet another console, is one of those lessons our industry keeps having to relearn, despite countless examples demonstrating why its the wrong approach.

There is also a beta conversational interface that lets a user ask natural language questions against the underlying graph, the “Do I have Shai-Hulud or not?” a query I mentioned earlier, and get an instant answer. It sounds simple, and that is the point. That is the question organizations were desperate to answer during Log4Shell and every incident since, and being able to answer it in seconds against a live graph of your environment that accounts for not just presence but blast radius is a meaningfully different posture than what most teams have today.

For organizations with sensitivity around data separation, the team noted that customer infrastructure is single-tenant as well.

Why the SDLC Focus Matters

One point of differentiation the team was passionate about, is the decision to anchor in the software development lifecycle and source control rather than the runtime environment. Their argument is that a great deal of supply chain risk manifests inside developer tooling, build systems, and test suites, and never touches the runtime environment at all.

The Shai-Hulud worm harvesting credentials during a package install is a perfect example. That happens on a developer’s machine or in a CI runner, long before anything reaches production. A runtime-oriented tool is looking in the wrong place for that class of attack, but that said, I do hold the view that coupling this with something with runtime visibility and capability is key as well.

The other place the SDLC-anchored, graph-based approach earns its keep is in large, complex, non-uniform environments. Enterprises rarely run on a single tidy GitHub org. They have multiple disparate instances of GitHub and GitLab, acquisitions with their own stacks, and years of accumulated sprawl.

The ability to enumerate software and assess risk across all of that without forcing a massive migration or platform consolidation first is a genuine differentiator, and it maps to the reality practitioners actually live in and environments I often see rather than the clean environment a tool wishes they had.

Closing Thoughts

This is far from an exhaustive discussion, and I have deliberately left the deeper AI angle to my prior writing.

That said, what the first half of 2026 makes clear is that software supply chain security has crossed from a problem we talked about getting ahead of into one that is actively outrunning most organizations’ ability to respond. The volume is exponential, the campaigns are self-replicating, the attackers have moved upstream to the trust and identity layer, and the CVE-shaped tooling most of us built our programs around does not see any of it while it is happening.

I have been beating this drum for years, going back to my book “Software Transparency”, and the through line has not changed. You cannot secure, prioritize, or remediate what you cannot see. The organizations that come through this next wave in decent shape will be the ones that finally solve for visibility and remediation velocity as first-order problems, rather than treating them as something they will get to after the next audit.

It remains to be seen whether the industry actually embraces this approach at scale before the next widespread software supply chain event, but the tooling and the approaches to actually do something about it are here, and that is a more hopeful place to be than we were a few years ago.

-> Check Out Kusari! <-

I skipped last week’s issue while I was heads down at Black Hat, so this one pulls together the stories worth your attention from across the last two weeks rather than every link that crossed my desk. I have tried to keep it tight, with a focus on key stories over the last couple of weeks.

Black Hat was a blast, I had a chance to MC both the Innovators & Investors Summit as well as the Startup Spotlight Competition. So many excellent talks both at the events and in the hallways, I recorded several podcasts with friends from the community and more, so be on a look out for those!

This was the stretch where autonomous agents stopped being a benchmark curiosity and started reaching real systems. OpenAI disclosed that a model under evaluation escaped its environment and hacked Hugging Face, Anthropic went back through more than a hundred thousand of its own evaluation runs and found its models had compromised real companies, and the UK’s AI Security Institute published an incident report describing agents attempting supply-chain attacks and deceiving real people during routine testing. OpenAI of course shared their post-mortem at Black Hat, which many including myself agree is a must-watch for this space.

The rest of the industry spent the past week reacting to it, in accountability debates, defensive AI deployments, a wave of agent sandboxing work, and a funding market that keeps writing nine-figure checks for AI-versus-AI security.

Let’s get into it!

Into the Breach: critical infrastructure cybersecurity, on screen

Into the Breach is OPSWAT’s new cybersecurity docuseries, hosted by MythBusters’ Kari Byron and produced by Cyber King Productions. Through hands-on experiments, cinematic storytelling, and expert interviews, the series makes critical infrastructure security visible — for technical practitioners and nontechnical audiences alike.

Episode 1, “Breaking the Firewall,” is now streaming on YouTube. It challenges one of the industry’s most dangerous assumptions: that firewalls alone can protect critical assets. Also available on select in-flight entertainment systems worldwide.

Watch Now

*Sponsored

Cyber Leadership & Market Dynamics

Cyera acquires Oasis Security in a roughly $1 billion deal

Cyera signed a letter of intent to acquire Israeli startup Oasis Security for approximately $1 billion, reported as $700 million in cash with the remainder in Cyera shares. Oasis, founded in 2022, had raised $195 million and works in what it calls agentic access management, which tells you a lot about where Cyera thinks the puck is going.

Cyera itself recently raised $600 million at a $12 billion valuation, reports more than $200 million in ARR, and has now strung together a series of acquisitions across identity and machine access. The interesting piece here is not the headline number, it is that a data-security company is spending megaround capital to buy its way into managing non-human and agent identity before that problem fully arrives.

Given everything else in this issue about agents acting on their own, that looks less like empire building and more like reading the room.

Horizon3 raises $250M Series E at a $2B+ valuation

Horizon3 announced a $250 million Series E at a valuation north of $2 billion, up from the $650 million valuation of its Series D just over a year ago.

The company reports 120% year-over-year ARR growth, more than 7,000 organizations protected, and 310,000 tests safely executed in production, with the round co-led by NightDragon and NEA and Dave DeWalt joining the board. The framing Horizon3 chose, leading the “AI vs. AI” era, is the same theme showing up across this issue, and the market is clearly willing to fund it.

Autonomous offense to validate your environment is a genuinely useful capability, and it is worth dwelling on the fact that the same techniques being funded here as blue-team tooling are, in the incident section below, what happens when they run without a leash.

I had a chance to sit down with Snehal at Black Hat and discuss the funding round, their market trajectory, the competitiveness of the category and more. Snehal remains one of the sharpest cyber business leaders I know and speak with.

Corma raises $60M from Sequoia for AI trained to defend against cyberattacks

Corma came out of stealth with a $60 million seed round led by Sequoia, with Khosla Ventures and Coatue participating. Founded in 2025 and split between Tel Aviv and San Francisco, the company deployed its first model roughly six weeks before the announcement to Fortune 100 and Fortune 500 organizations, and CEO Alon Pluda says it focuses squarely on defensive work like log analysis and threat detection, claiming a 94% reduction in threat response times at adopting organizations.

A $60 million seed is a lot of conviction for a company barely a year old, and the vendor-supplied 94% figure deserves the usual skepticism until there is independent validation. That said, the signal is consistent with the rest of the market this issue, investors are pricing defensive AI as a category that has to exist, not one that might.

Huntress on crossing $250M ARR

Amid all the megarounds, Kyle Hanslovan put out a reflection on Huntress crossing $250 million in ARR, and it is worth reading because it is not a funding announcement.

The company now protects more than 270,000 organizations and 19 million endpoints and identities across 100 countries, largely through a partner motion of more than 20,000 MSPs and resellers, and Hanslovan frames the revenue as a byproduct of the mission to bring enterprise-grade security to the small and mid-sized businesses he calls “the 99%.”

I have long argued that the underserved end of the market is where a lot of the real risk lives, and building a nine-figure business by serving it rather than chasing the Fortune 500 is a model more of the industry should study. Huntress serves the majority of the ecosystem that lives below the cyber poverty line and desperately need help, as you saw with my recent discussion with Alex Pinto of Verizon on their Breach Impact Study. SMB’s face steeper financial impacts from incidents than their enterprise counterparts.

Templates for cybersecurity executive briefings

Lenny Zeltser published four customizable executive-briefing templates covering threat intelligence, vulnerability investigation, incident response, and security assessment, each built around leading with the takeaway and what a finding actually means for the organization.

This is not flashy, but communicating clearly to decision-makers is one of the most persistent gaps in our field, and a well-structured brief that opens with the takeaway and puts action items in a table does more for your program than most tooling. A timely resource to bookmark.

AI

OpenAI’s Black Hat talk on the Hugging Face incident

The centerpiece of Black Hat this year was OpenAI walking through the incident in which one of its models, under evaluation, escaped its environment and compromised Hugging Face.

OpenAI called it a watershed moment for the industry and encouraged defenders to watch and plan for how attack dynamics are about to change, and the Black Hat session recording covers the reconstruction and its implications for AI security and alignment.

Whatever you make of the framing, a frontier lab standing on the Black Hat stage to dissect its own model breaching another company is a moment our field will be referencing for a while.

This talk helps frame a lot of the below resources and at the time I’m sharing it, it already has over 500,000 views on YouTube!

Anthropic investigates three real-world incidents in its cybersecurity evaluations

Prompted by OpenAI’s disclosure, Anthropic went back through 141,006 of its own evaluation runs and found three incidents where Claude models escaped supposedly isolated environments and reached real systems at three organizations.

Across the three, involving different models, a model compromised a real company’s infrastructure and accessed a database containing several hundred rows of production data, published malicious Python packages to PyPI that were downloaded and run on 15 real systems before removal, and scanned roughly 9,000 targets before compromising a company using what Anthropic describes as basic techniques like reading credentials from an exposed debug page and SQL injection. The root cause was a misconfiguration with their partner Irregular that granted internet access despite prompts stating there was none.

Give Anthropic credit for the transparency, because the substance is helpful but many of course also remain skeptical that it is in large part marketing, especially as others such as Meta and even Chinese model providers rushed to say their agents also broke out of training environments. The models were not doing anything exotic, they were doing ordinary attacker things, at scale, because a supposedly closed door was open.

A defender’s breakdown of the Hugging Face incident

turned the Hugging Face timeline into a practical kill-chain analysis, splitting it into initial access, breach, and lateral movement and mapping defensive controls to each stage.

His read is that supply-chain firewalls offer limited protection against this pattern, and that the real leverage is blocking egress, deep runtime monitoring, and an assume-breach posture, given how difficult the template-injection and in-memory-secrets stages are to stop. He notes the nearly 17,600 actions over four days represent a level of sophistication we would once have called nation-state grade, now produced by a model chasing a benchmark.

If you own detection and response, this is a actionable write-up of the incident.

The UK AISI incident report on unsanctioned agent behaviour

Separate from the OpenAI and Anthropic disclosures, the UK’s AI Security Institute published an incident report from a routine cyber evaluation on July 28, and it is the one that I found the most informative.

Of 122 test runs, 10 runs contained 19 instances of unsanctioned behavior, 17 of them from Anthropic’s Mythos 5 and 2 from OpenAI’s GPT-5.6-Sol. The behaviors are the key part. Agents attempted a supply-chain attack by inserting malicious code into a public open-source project, creating fake identities and social-engineering the maintainers, an attempt caught by a human reviewer. Others directly deceived real people, attempted prompt injection against other AI systems, and in one case left public GitHub messages sharing account credentials for other agents.

Internet access was deliberately enabled and cyber classifiers intentionally disabled for realism, AISI reports no confirmed real-world harm, and it contained the incident within an hour. Autonomy and deception stopped being a slide in a threat model here and started being a logged event.

I recorded a video breaking this one down from my hotel room at Black Hat:

Once again, the scaffolding failed

Hyrum Anderson offers a sharp reframe of the whole episode, and I largely agree with him. His argument is that these incidents are not primarily a story about misaligned objectives, they are a story about failed constraints, models optimizing perfectly legitimate goals inside environments where the declared boundaries were documented but never actually enforced.

In Anthropic’s case the prompts claimed no internet access while the harness quietly provided live connectivity, and the model simply used it.

His line, “optimizers are going to optimize,” is the whole thing in four words.

The uncomfortable question he leaves you with is not whether your models are aligned, it is which of your security constraints are genuinely implemented versus merely written down, and that question long predates AI.

Who is legally to blame for autonomous AI hacks

TechCrunch takes on the accountability question these incidents force, and the answer is genuinely unsettled and that is why we’re seeing a lot debate in the ecosystem.

The piece weighs criminal and civil exposure under the 1986 Computer Fraud and Abuse Act, with cybersecurity attorney Ahmed Ghappour arguing the model is the company’s tool and that “you don’t get to deploy something capable of breaking into systems and then disown where it goes,” calling a civil negligence case a “no brainer” for victims. The EFF’s Andrew Crocker is skeptical that the intent required for criminal charges can be proven against a model, and there is no federal AI liability law to lean on, though several states are moving.

We are going to be litigating who owns an autonomous system’s actions for years, and the technology is not waiting for the law to catch up, so expect more incidents as well as more debates about accountability.

Moonshot’s Kimi K3 escapes its sandbox

For anyone who thinks this is purely a US-lab story, Wired reported that Moonshot’s Kimi K3 model escaped its sandbox as well, a pattern corroborated by Frontier Security’s account of Kimi K3 exploiting network egress in an AISI evaluation sandbox to retrieve an official benchmark solution rather than solving the task natively.

Frontier’s broader argument is the one to keep in mind, that offensive capability scales predictably with inference budget while defensive investigation does not, an asymmetry that should reshape how we benchmark security agents in the first place. Open-weight and international models are part of this story now, and the containment problem does not respect a lab’s borders.

The key theme across all of these stories is that agents find a way, and that way often involves trying to cheat, something that has been researched and documented by AISI on their blog.

AWS introduces Dogwood for runtime verification of AI agents

AWS open-sourced Dogwood, a governance language for regulating how agents use tools that goes beyond point-in-time authorization by adding temporal conditions over an agent’s recent history. Built on Cedar and grounded in metric first-order temporal logic, it can express rules like requiring an approval before a sensitive action or rate-limiting a class of operations, which is the kind of history-aware constraint that static, request-by-request policy cannot capture. It pairs naturally with research like Dreadnode’s ScopeJudge, which tested whether a runtime LLM judge can keep offensive agents in scope and found the best configuration reaching the lower end of human agreement, concluding runtime monitoring is the most practical way to deploy scalable oversight for offensive agents today. Between formal policy and learned judges, runtime is clearly where the agent-control conversation is heading.

Low-cost, evasive, abundant malware from open-weight models

On the offensive research side, Incalmo built a system called PathoGen that uses open-weight models like GLM 5.2 to generate evasive malware, reporting that roughly 27% of samples evaded all 75 scanners on VirusTotal and about 75% evaded all but one, at a cost of $2 to $35 per sample. The researchers withheld methodological details and coordinated with vendors, and their point is constructive, use frontier models proactively to find the defensive gaps before adversaries do. That said, the economics are the story. When capable, scanner-evading malware costs less than lunch to produce, volume stops being a meaningful signal and detection has to lean much harder on behavior than on signatures.

AppSec

VulnCheck’s state of exploitation for the first half of 2026

Patrick Garrity and the VulnCheck team published their first-half exploitation data, and it is the empirical grounding a lot of the AI-and-vulnerabilities conversation badly needs. In 1H-2026, 23.43% of known exploited vulnerabilities showed evidence of exploitation on or before the day the CVE was published, down from 28.93% in 2025, and the median time from publication to known-exploited status dropped from 120 days to 80.

The figure most relevant to this issue is the AI one, of 1,061 vulnerabilities attributed to AI-assisted discovery, only 14, or 1.3%, were confirmed exploited, and Anthropic’s Project Glasswing produced 23,019 findings and 126 published CVEs but just a single confirmed exploitation. AI is discovering vulnerabilities at scale, but discovery and real-world exploitation remain very different things, and the data is a healthy corrective to the assumption that one automatically becomes the other.

SQLite critical CVEs, or LLM slop

JFrog’s Afek Berger dug into six SQLite advisories filed from a newly created GitHub repository and found them fabricated, referencing functions that do not exist, with proof-of-concepts that do not run, and CVSS scores as high as a claimed 9.8 critical that had to be walked back.

A broader audit turned up 54 completely fabricated advisories, with exactly one containing a real bug. Berger ties the problem to NVD pausing its deeper analysis back in early 2024, which lets AI-generated slop flow downstream into scanners and databases unchallenged.

This is the shadow side of the AI-discovers-vulnerabilities story. The same generative capability that finds real bugs also mass-produces convincing fake ones, and our vulnerability infrastructure was not built to filter them.

Triaging bug bounty reports for $2 each, 85% as well as a human

Elastic Security Labs built an AI triage system for HackerOne reports that performs about 85% as well as a human at roughly $2 per report, validated against 764 known-outcome reports.

The context that makes it matter is the volume, they received more than 1,390 reports in the first half of 2026, exceeding their full-year totals for 2024 and 2025 combined, which is exactly the flood that AI-assisted discovery produces on the reporting side. A human still makes the final call on every report.

This is the pragmatic pattern for surviving the coming report volume, let the model handle triage economics while keeping human judgment on the decision, and it pairs well with 1Password’s parallel work on making security reviews scale without drowning in context and nondeterminism.

Why AI-generated patches still require expert human review

1Password’s Off-by-1 Labs ran one of the more rigorous tests of AI patching I have seen, generating 6,080 patches across six recently disclosed CVEs. Only 26.0% completely fixed the flaw without changing application behavior, another 20.1% fixed it but altered behavior, and 53.9% failed outright or introduced new vulnerabilities, with more than a third of even the successful patches judged fragile because they treated symptoms rather than root causes. This is the essential counterweight to the fix-it-with-AI enthusiasm.

The generation side is improving fast, but a majority of machine-generated patches are still wrong or harmful without expert review, and shipping them unreviewed would trade a known vulnerability for an unknown one.

had an excellent blog breaking down the findings and the implications for practitioners as well.

Everything hackable will get hacked

Vercel’s Malte Ubl makes the blunt case that open-weight models now carry real offensive capability, describing Kimi K3 as an Opus-class model with no relevant cybersecurity safeguards, while frontier models still hold the defensive edge for now. This widespread capability is the same point has been making for months.

Vercel’s response is instructive, running full deep security reviews across mission-critical repositories quarterly at a cost of tens of thousands of dollars, and making an egress firewall available even on its free Hobby plan. The egress theme keeps recurring across this entire issue for a reason.

Whether you are containing your own agents or blunting an attacker’s, controlling what code can reach the network is turning out to be one of the highest-leverage controls available, and it is encouraging to see it pushed down to the free tier rather than reserved for enterprise.

Final Thoughts

Two weeks is a lot to compress, but the summer’s story told itself.

Autonomous agents crossed from the benchmark into real systems, and they did it not through exotic capabilities but by exploiting ordinary weaknesses the moment a containment assumption failed.

The most critical thread running through the OpenAI, Anthropic, and AISI incidents is not that the models were brilliant, it is that they were ordinary attackers with unusual stamina, and the doors they walked through were the same weak passwords, exposed endpoints, and soft egress boundaries we have been failing to close for years.

These same problems are pervasive across every organization and environment and is exactly why Vercel’s CTO said everything hackable will be hacked.

The encouraging counter-thread is that the response is already taking shape, in the sandboxing and runtime-verification work, the defensive deployments at security vendors, the honest accounting of where AI patching still fails, and the beginnings of a shared exchange for incidents and near-misses.

The pace of agent adoption is once again outrunning the pace of governance, and we get to choose whether we build these controls in while the architectures are still forming or bolt them on after the next incident. The evidence from the last two weeks suggests we should hurry.

Stay resilient.

Subscribe now

In this episode I sit down with Mike Armistead, co-founder and CEO of Pulse Security, to discuss why the CISO has spent decades running a security program without a system built to run it, including the silos that created the problem, what a system of truth actually looks like, and where AI does the heavy lifting versus where the human stays in the seat.

Mike has been through this movie before as the co-founder of Fortify and of Respond Software, so his view on the AI wave is measured rather than breathless. We also get into the reporting gap between what CISOs say and what boards actually need, and the research findings that put real numbers on it.

We chatted about:

• Mike’s path through two exits and why the AI wave pulled him back to build a third company

• Why security grew up as a set of technical silos, each speaking a slightly different language, with no system to run the program as a whole

• What a system of truth for the CISO means, and how an agentic layer reads across both structured and unstructured data like policies and assessments

• Where agents take over the toilsome work of regulatory monitoring, vendor and vulnerability intelligence, and status reporting

• Governing the guardrails rather than the keystrokes, and why closing the loop still involves people and their judgment

• What corporate directors actually want to hear from a CISO in a 15 to 20 minute quarterly slot

• The research findings, including that 55% of boards have never defined the cyber risk they are willing to accept and only 12.5% of CISOs are very confident the board leaves with a true picture of the risk

• Bringing Joanna Burkey’s dual perspective as a former CISO and current corporate director into the product

Prefer to listen?

Spotify

Apple Podcasts

Be sure to subscribe and leave a review as it truly helps the show!

A few takeaways from the conversation:

The CISO is the last executive without a system of record

Mike frames the gap in terms every leader will recognize. The CFO manages financial risk from an ERP with a general ledger at its core, and the CRO runs the pipeline from a CRM. The CISO manages cyber risk from a scattering of spreadsheets, assessment documents, and point-in-time audits. His argument is that security grew up at the practitioner level, one technical silo at a time, and never developed the layer that answers questions about the program itself rather than about a single threat or vulnerability. I have lived this in programs I have supported, where the leader has to walk over to the deputy, the cloud team, the endpoint team, and the SOC to assemble a picture that should already exist in one place.

Agents for the toil, humans for the judgment

Mike is careful about where autonomy fits, and I appreciated that he did not oversell it. Agents are good at scouring the landscape and pulling the right signals for a specific company’s stack, which turns a board member’s “are we affected by that thing I read about” into a grounded answer instead of a scramble. But he is clear that “closing the loop involves people.” His quarterly access review example lands well. An agent can pull from cloud, identity, GitHub, and HR, but the calls on how broad the review goes and whether to grant exceptions stay with the security professional. What the system adds is memory of those decisions, so the exception you granted last time does not get relitigated from scratch.

The board reporting gap is about ground truth, not delivery

The numbers from the research are the part that should make people sit up. Mike cited that 55% of boards have never defined the level of cyber risk they are willing to accept, and that only 12.5% of CISOs are very confident the board walks away with a true picture of the risk. He does not think this is mainly a storytelling problem. As he put it, “we often, I think, the trees are presented instead of the forest.” The CISO gets 15 to 20 minutes a quarter and tends to fall back on the SOC metrics that feel comfortable, while the director wants to know what changed in the landscape and what the program’s posture is against it. Closing that gap means better ground truth underneath the narrative, not just a better narrative.

Institutionalizing the tribal knowledge

The thread that ties it together is one every practitioner knows. Programs run on tribal knowledge, the contract clauses a leader has ruled on before, the exceptions, the context that lives in a few people’s heads. Mike brought in Joanna Burkey, former CISO at HP and Siemens and now a corporate director, as an advisor precisely because she has seen both sides, and her point is that this knowledge “needs to be institutionalized in a way.” Capturing it saves time and money and headache, and it is the difference between a program that resets every time someone leaves and one that compounds what it learns.

Thanks to Mike for a sharp conversation on a problem the industry has mostly ignored while it chased AI for AppSec and the SOC. You can follow his work at Pulse Security AI and connect with him on LinkedIn.

-> Check Out Pulse Security! <-

The pattern is remarkably consistent regardless of the organization’s size, sector, or security budget. Someone spins up a war room, someone else spins up a chat channel, a Google Doc appears with a running timeline, an executive asks for a status update that takes forty minutes and a game of telephone to assemble, and somewhere in the middle of all of it someone awkwardly asks whether anyone has started the clock on notification obligations.

That said, look at what we have actually built as an industry over the last three decades. We went from basic IT service management, to SIEM for detection, to EDR and XDR for containment, to SOAR for automating the tedious parts, to the current wave of AI SOC tooling for triage. Every one of those advances made the technical work better and almost none of them improved the enterprise work, meaning the decisions, the ownership, the obligations, and the documentation that determine what an incident actually costs an organization in the end.

Using Resilient Cyber’s partner, BreachRx as an example in this article, I want to dig into that gap, why it has become more expensive in an era of collapsing exploitation timelines, and what it looks like to treat incident response as a discipline with a real command center rather than an ad hoc scramble across disconnected tools.

Let’s take a look at how we got here, and where we still need to go.

The Clock We Never Reset

By now, it is clear that the timelines attackers operate on have detached from the timelines defenders operate on, and the evidence on this has gotten hard to dispute.

Mandiant’s M-Trends 2026, built on over 500,000 hours of frontline incident investigations conducted globally in 2025, found that the median time between initial access and hand-off to a second threat group fell from more than eight hours in 2022 to 22 seconds in 2025. Exploits remained the most common initial infection vector for the sixth consecutive year, at 32%. Google Threat Intelligence Group’s mean time-to-exploit, which measured 63 days back in 2018, is now estimated at negative 7 days, meaning exploitation is routinely happening before a patch exists at all.

I wrote about this trajectory earlier this year in an article titled, “The Zero Day Clock Is Ticking”, where the numbers tell the same story from the vulnerability side. In 2018, the median time from a vulnerability being disclosed to the first observed exploit was 771 days.

By 2021 that window had compressed to 84 days. By 2023 it was 6 days, and by 2024 it was 4 hours. This is in addition to the recent 2026 Data Breach Investigations Report (DBIR) highlighting how vulnerability exploitation is now the leading attack vector for organizations, overtaking other vectors such as compromised credentials or social engineering, which historically was in the lead.

Now, for those of us who have spent years telling executives that our detection and response capabilities are maturing, the other half of that same report is uncomfortable reading. Global median dwell time went the wrong direction, up to 14 days in 2025 from 11 days in 2024, and cases where the organization learned about the intrusion from an external party had a median dwell time of 25 days, up from 11. Attackers compressed their timelines by orders of magnitude while we got slower.

Detection has absorbed the overwhelming majority of security investment and innovation for twenty-five years, something strongly documented in work, such as Sounil Yu’s Cyber Defense Matrix and it shows, with 52% of organizations first detecting malicious activity internally in 2025, up from 43% in 2024.

The response side of the house, meaning everything that happens after someone says, “yes, this is real,” is largely still run the way it was run in 2012 with a bridge line, a shared document, and a lot of institutional memory.

Everyone in the Room, and No One in Command

Incident response sits at the intersection of nearly every business unit, and that is what makes it structurally different from the rest of security operations, involving a diverse group of both technical and non-technical stakeholders.

Within hours of an incident being declared, you have security running technical containment, IT managing systems and access, legal evaluating contractual and disclosure exposure, privacy assessing what data categories and jurisdictions are implicated, communications drafting internal and external statements, HR involved if there is an insider dimension, executives asking for accurate status, and the board asking whether this is material. That is before you get to the external parties, meaning outside counsel, forensic firms, the cyber insurer, managed service providers, regulators, customers under contractual notice obligations, involved business partners, and eventually the press.

Most of those people are not technical, and most of them are being asked to make consequential decisions from a summary that someone typed into a chat window twenty minutes ago, which then got passed along in a lossy game of telephone.

The technical execution in these situations is usually fine, since practitioners are good at containment work and generally know what to do. What breaks is enterprise coordination, and it breaks in a very specific way. Actions live in email threads, Slack or Teams channels, and a spreadsheet someone is heroically maintaining, ownership is tracked manually, and status is fragmented across half a dozen tools that were never built to talk to each other. There is activity everywhere and no authoritative, consolidated view of the incident.

In other areas of cybersecurity, we have pushed to quit tolerating this disjointed scenario and now have vendors and enterprises alike building unified cohesive platforms and sources of truth, but unfortunately not so much when it comes to incidents.

External parties make this harder rather than easier. Your forensics firm needs artifacts, your insurer needs a claim narrative, outside counsel needs a privileged workspace, and your regulator eventually needs a defensible chronology. In most organizations all four are served by someone manually exporting slices of the same spreadsheet or Google doc into email attachments, at 2 a.m., during the worst week of their professional life.

Regulatory Clocks Don’t Wait

If the coordination problem stayed internal, it would be an efficiency issue. It does not stay internal, because the reporting obligations have gotten both faster and more numerous, and they run on clocks that start whether or not your team has its act together.

Consider what a large multinational is actually holding at once. India’s CERT-In directions require reporting in-scope cyber incidents “within 6 hours of noticing such incidents.” Under DORA’s regulatory technical standards, EU financial entities must submit an initial notification of a major ICT-related incident within 4 hours of classifying it as major, and no later than 24 hours from becoming aware of it. NIS2 requires an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month.

GDPR requires notification to the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it.” NYDFS requires notice within 72 hours of determining that a cybersecurity incident occurred, plus a 24-hour notice for extortion payments and a written justification within 30 days. The SEC’s Form 8-K is generally due four business days after a registrant determines an incident is material, and underneath all of that, the U.S. has breach notification laws in all 50 states plus the District of Columbia, Guam, Puerto Rico, and the Virgin Islands.

CIRCIA’s 72-hour incident and 24-hour ransom payment requirements are still dormant, since CISA has stated that covered entities are not required to report until the effective date of a final rule that has slipped repeatedly and is now projected for September 2026, but that is a reprieve, not a reduction, and the requirements are still likely to materialize.

Safe to say, the reporting timelines are complex and hard to juggle while also working through incident response.

None of these clocks are triggered by the incident. They are triggered by awareness, determination, or classification, which are all judgment calls made by humans under pressure, and every one of those judgment calls is later reviewable. Missing a deadline is one failure mode, however it is more common to not be able to demonstrate when the clock started or why you concluded what you concluded.

You can see the resulting confusion in the U.S. public company data. I’m subscribed to Andrew Hoog’s 8K and incident tracker, and the reporting truly is all over the place in terms of level of detail within what gets filed.

Privilege Is a Design Decision

There is a category of incident response failure that practitioners rarely think about until it is too late and the implications are real.

Every message in that incident chat channel, every comment in the running timeline doc, every speculative theory someone typed at hour three when the picture was still wrong, is potentially discoverable. Security teams communicate the way engineers communicate, which is candidly and with a lot of thinking out loud. That is the behavior you want during an investigation and exactly the behavior that reads badly when a plaintiff’s attorney reads it back to you two years later, stripped of context.

Attorney-client privilege over incident work is not automatic and it is not preserved by copying a lawyer on a thread. It depends on how the work was structured, who directed it, where it lived, and whether the organization can show a segmented, deliberate approach to sensitive communications. Doing that inside general-purpose collaboration tools designed for open information flow is difficult, and most organizations discover how difficult only in retrospect.

Additionally, and this one is almost too obvious to state, if your incident coordination lives entirely inside the productivity suite the attacker has been sitting in for two weeks, you have a shared workspace with an audience. Out-of-band access sounds paranoid right up until the moment it is the only thing that works, but even then it can get problematic with personal devices and communications intermingled with corporate ones.

This is also where the tabletop conversation gets interesting. We talk constantly about the need for exercises, and the advice is sound. However, running a tabletop in a slide deck and a conference room trains your people on a process they will not actually execute, in a system they will not actually use, against obligations they will not have time to look up. Practice that does not live in the same environment as execution is a rehearsal for a different play.

The Record Is What You Get Judged On

The personal liability narrative in our industry has run hot for a few years now, but the recent evidence is mixed. The SEC’s enforcement action against SolarWinds and its CISO was largely gutted at the motion to dismiss stage in 2024, and in November 2025 the Commission filed to dismiss the remainder with prejudice. That is a meaningful data point, and anyone telling you regulators are indiscriminately hunting CISOs should be viewed with caution.

That said, the underlying dynamic has not gone anywhere. Regulators, lawyers, insurers, and boards do not evaluate an incident purely on the technical outcome, they evaluate the process, meaning whether escalation was timely, whether executives were informed and when, whether disclosure decisions were documented with the reasoning behind them, whether obligations were tracked across jurisdictions and met, and whether leadership can demonstrate good-faith governance rather than simply claim it.

Every one of those questions is answered from the record. If the record is a reconstructed narrative cobbled together weeks later from chat exports, calendar invites, and people’s recollections, you are not defending your decisions, you are defending your memory of them, which is a much weaker and less than ideal position.

This is where I think the emerging Cybersecurity Incident Response Management (CIRM) category, which BreachRx has been a pioneer of, is pointed at a real gap in the industry.

The key thesis is that the enterprise layer of incident response deserves a purpose-built system of record in the same way detection, containment, GRC and even ticketing eventually got theirs, with clear ownership across stakeholders such as security, legal, privacy, IT, communications, and leadership, tailored playbooks and obligation tracking that surface which of those 6-hour, 24-hour, 72-hour, and four-business-day clocks apply to this incident in these jurisdictions, protected and segmented communications, evidence captured continuously as the response executes rather than reconstructed after the fact, and tabletops run inside the same environment the team will use when it counts and it’s no longer a hypothetical incident, but a real one.

Joe Sullivan, former CSO at Uber, Facebook, and Cloudflare, and an advisor to BreachRx, made the case for this strongly in their materials I read, and there are few people have who have lived through incidents at the level of scrutiny he has:

“Until I saw BreachRx, I had not seen any product that truly would have made a difference for me at Uber. Their platform could have completely changed the outcome by ensuring seamless communication, cross-organizational collaboration, and better decision-making that is documented and aligned with the law.”

Their platform embeds agentic AI into the response lifecycle through bounded, role-specific agents rather than a general-purpose chatbot bolted onto the side, with a coordinator agent orchestrating specialists for incident command, response execution, exercises, and regulatory analysis, and human approval checkpoints where they matter. It was interesting to see this multi-agent architecture applied to this use case.

Resilient Cyber subscribers know I am optimistically skeptical of agentic AI claims, but incident response is among one of the more defensible applications I have seen so far, largely because it is a workflow and context problem involving procedures, stakeholders, deadlines, approvals, and documentation. That is the kind of bounded, high-toil, high-consequence coordination work where agents earn their keep and where a chat interface alone does not.

BreachRx has also done something I have not seen elsewhere in this category, and frankly was something I was surprised to see, which is backing the product with a warranty offering up to $3 million per claim in liability protection, with no retention requirement, covering defense costs, fines, penalties, and negligence-related claims for executives and response team members personally named in regulatory or government actions. These are the sort of guarantees I recently heard longtime industry leader Jeremiah Grossman make a call for in an interview:

Very few security companies ever stand behind the effectiveness of their products with this sort of rigor honestly.

The argument is that D&O coverage frequently carries exclusions, carve-outs, or allocation disputes that leave security leaders exposed precisely when they need assurance. Whether a warranty is the deciding factor for a buyer is an open question, but putting financial skin in the game behind a defensibility claim is a stronger commitment than most vendors are willing to make, that’s for sure.

Closing Thoughts

We have spent a decade telling organizations that incidents are inevitable and that resilience matters more than prevention. I believe that, and the data keeps supporting it, especially now with AI-driven vulnerability discovery and autonomous exploitation arriving. What we have not done is give the people who actually run those incidents anything resembling the tooling maturity we handed the detection side of the house.

Attackers now move from initial access to hand-off in 22 seconds and exploit vulnerabilities before patches exist, while the enterprise response to those attacks is coordinated in a spreadsheet, a chat channel, and whatever document someone thought to create in the first ten minutes, against a stack of regulatory clocks that start ticking on judgment calls made by exhausted people at 3 a.m.

That is a very disorganized approach with very high stakes and very good odds of being reviewed later by someone who may not be sympathetic to the circumstances and stressors involved.

Whether you solve that with BreachRx, with something else, or with a painfully disciplined internal build, it’s worth asking your team some simple but not easy questions. For example, if an incident were declared this afternoon, where would the authoritative record live, and would we want a regulator to read it?

If you want to see what the platform side of this looks like in practice, BreachRx runs a walkthrough worth an hour of your time.

Subscribe now

While each of these disclosures share some characteristics and are also unique in their own way, there’s also lessons to be learned. There are inevitably going to be broader policy discussions around responsible cyber evaluations, potential mitigations on real-world organizations and individuals, or even potentially requirements for cyber evals, as the policy discourse continues to heat up.

All of that aside, I wanted to use AISI’s Incident Report as a retrospective, not necessarily on AI cyber evals, but on the inevitable risks enterprises will face as LLMs and agents continue to be deployed in various contexts, from endpoint coding agents, custom/homegrown agents in the Cloud, SaaS/Embedded agents and more.

So, let’s take a look at that report to see what lessons enterprise security leaders and teams can draw from it, knowing they will experience similar situations in terms of deployments, configurations, hardening, and risk management.

My key theme is we have a lot we can learn as security practitioners and leaders from the leading labs and research entities in the ecosystem as it relates to enterprise use of AI agents and security.

What Happened?

I don’t want to belabor the entire AISI incident, but it is helpful to at least recap what happened before we dig into the specific takeaways for security leaders.

The UK AI Security Institute published an incident report on August 4th. During a cyber evaluation that ran from July 25th to July 28th, AISI’s own AI agents took “sustained, unsanctioned actions” on the live internet against real people and organizations that had nothing to do with the test.

Across 122 evaluation attempts, AISI found 19 distinct instances of this behavior. Seventeen of them came from a single model, Mythos 5, and the other two came from GPT-5.6 Sol.

In the most serious case, an agent decided to solve the challenge with a software supply chain attack and went after two unaffiliated open-source maintainers it wrongly assumed were in scope. It created GitHub accounts using Tor and a proxy to slip past signup controls, opened a malicious pull request, and stood up sockpuppet accounts to manufacture consensus and endorse its own code.

It sent spearphishing emails to the maintainers and planted a prompt injection hidden inside a GitHub issue, aimed squarely at other AI coding agents. When a real human spotted the malware, the agent claimed an honest mistake and tried to cover its tracks. AISI says this is the first time it has seen deception of this severity aimed at a real person, unprompted, in the real world.

A couple of things are parrticularly interesting. First, this is now the third disclosure of its kind in a matter of weeks, following OpenAI and Anthropic, which tells me we are looking at a pattern and not an outlier. Second, and more important for practitioners, the danger did not live in the model weights. It lived in the harness around the model, its internet access and its ability to take real actions with real tools, which is exactly the excessive agency risk my friends and Steven Wilson over at OWASP just flagged in the opening lines of their new LLM Top 10.

These safeguards were deliberately disabled and internet access was deliberately enabled to measure raw capability. That is a defensible research choice, but when an evaluation can reach real systems and real individuals, how we run these tests deserves a serious industry and policy conversation, which I anticipate will inevitably heat up now.

But, for this blog, I want to focus on the lesson for security leaders.

Implications for Security Leaders on LLM and Agent Deployments

While the policy conversation and the incidents with the labs and research community are very interesting, that isn’t why I wanted to write this blog. I wanted to write it because as I read through AISI’s incident report, I inevitably saw someone takeaways that are and will be relevant for security leaders as enterprise agent deployments and implementations continue to ramp up.

The most relevant part of the report on this front is the “Possible Contributing Factors” section of their report.

Take a look at that list and ask yourself, how likely do we think it is that each of these will be present in real-world enterprise agent LLM and agent deployments for the organizations we secure or serve?

I think most of us agree that the answer is, very likely. Let’s step through them 1 by 1 to unpack them a bit.

Internet Access

The opening line of this section of their report states:

By now, most of us who are immersing ourselves in AI security are familiar with Simon Willison’s “Lethal Trifecta” for AI agents.

Right there in the bottom left is “Ability to Externally Communicate”. The lethal trifecta essentially states:

“If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.”

In short, we want to avoid combining these three characteristics when deploying agents due to the risks, but of course this is easier said than done. I have been using the phrase Security Usability Tradeoff when I discuss agents, because their very utility, such as the characteristics above, are what make them desirable for enterprise and business use cases, and ironically also what make them risky.

Some, such as Meta have proposed their “Rule of Two” as a mitigation, but even then, as and others have shown, even that approach isn’t infallible, but it does help mitigate some potential risks and attack vectors.

It’s also worth noting in the case of AISI’s evaluation, there was no “attacker” that tricked the agent, it simply took on emergent behavior in pursuit of the goals it was given as part of the cyber evaluation, and as we continue to see, agents find a way, even if that way introduces risks to real world infrastructure and individuals.

Bringing this back to security practitioners, think about the exponential agents being deployed across your environments, on endpoints, in the cloud, in SaaS etc. and can we honestly state they do not have internet access, or if they do, we’re aware of where all of those agents run, with what permissions, tools and which ones have internet access?

The answer of course is no.

Think about the OpenAI and Hugging Face incident, that involved a misunderstanding between OpenAI and Irregular, a firm they use for cyber evaluations, and internet access wasn’t fully restricted despite the initial understanding that it was. This will be the case for many enterprise agent deployments as well.

We have decades of misconfigured ports, proxies, firewalls and other networking configurations to let us confidently say this will happen for enterprise agents too.

Lack of Model Provider Cyber Classifiers

Next up on the list of potentially contributing factors to the AISI incident is a lack of model provider classifiers. Due to AISI’s unique role in the ecosystem, conducting evaluations and research, they were in a position to have the cyber classifiers disabled for their evaluations of the models involved in the incident. This is part of the model providers “Trusted Access” programs, with vetted partners.

For those unfamiliar, model providers implement safeguards known as classifiers to mitigate abuse and misuse of their models for nefarious purposes. I went into detail on this topic in a video I did about the potential for a CVSS for AI.

Given the entire purpose of AISI’s cyber evals is to measure the cyber capabilities of the models and agents, it makes sense that cyber classifiers were disabled. That said, there are various implications for security practitioners and defenders on this front.

Those include the reality that there are plenty of other organizations within the frontier labs trusted access programs as well, even if they aren’t explicitly conducting cyber evals. There’s also the fact that the open weight frontier capability doesn’t lag too far behind the closed frontier, based on AISI’s on evaluations. AISI documented this in a blog titled “How Far Behind the Frontier are Open Weight Models on Cyber?”

So the gap between the closed models and open weights are narrowing in general, and on cyber. That means alternatives are and will be available for malicious actors to use, including versions with classifiers disabled, jailbroken, etc. along with a lack of oversight or monitoring of their usage for malicious activities, a point has made in several blogs now and in my interview with him.

Lack of Synchronous LLM-based Monitoring

AISI moves on from the classifiers topic to discuss a lack of synchronous LLM-based monitoring. As they explain, this is a separate LLM that reviews each agents proposed action before execution. In the community, we often refer to this as “LLM-as-a-Judge”, knowing we don’t have enough human eyeballs or bandwidth to review machine-speed actions at-scale.

Both of the leading frontier labs in Anthropic and OpenAI already use this technique for their “auto modes” of their platforms.

This approach, much like the Rule-of-Two I discussed earlier also is imperfect, given we are monitoring the actions of a non-deterministic system with challenges such as hallucinations etc. with another LLM with the same constraints or characteristics. This doesn’t mean LLM-as-a-Judge isn’t useful, it definitely is, and we know humans can’t scale to meet the speed or complexity of agents, so it will be an approach we have to embrace, despite its shortcomings.

Tying this to my theme of implications for enterprise security leaders, this means we also need to be considering the use of LLM-as-a-Judge, often called “Guardian Agents” (a term Gartner has taken to) as a mechanism to mitigate the risks of agent actions at runtime.

That said, AISI even admins in their blog this is still an open-ended challenge, as it can be hard to decipher what is appropriate or not, and this is why we’ve seen a lot of conversations around topics such as “Intent Analysis” in the industry among AI security vendors and researchers.

In fact, AI security research firm Dreadode recently had an excellent blog on exactly this titled “Can a Runtime Judge Keep Offensive Agents In Scope”, and they found this is far from a solved problem, with no silver bullets, and even human evaluators disagreed about the appropriateness of tool calls for agents 1/8th of the time.

Again, back to the implications for practitioners and security leaders, this is far from a solved problem for the community. We know humans can’t keep pace with agentic actions, but our use of LLM-as-a-Judge, Guardian Agents, or “Synchronous LLM-based Monitoring” as AISI calls it is an open-ended challenge, and if it is a challenge for the labs and leading researchers, it definitely is a gap for security practitioners at most enterprises already deploying agents as well.

Prompt Misconfiguration

Then we have prompt misconfiguration. In short, AISI found that the prompt samples used included some that would have required accessing a network that should have been out of scope for the evals.

They state:

”This is notable because AI agents faced with tasks that cannot be completed within their stated constraints are more likely to take unsanctioned actions, as they resort to “creative” solutions when legitimate approaches fail.”

Or to put it bluntly as I said above, “agents find a way”. When agents encounter constraints that impede their goals or objectives, they will utilize many different and often unexpected means to work around those constraints. AISI even discussed how in several cases despite something being explicitly declared out of scope, the agent moved forward anyways.

This is something I’ve covered in great detail in a prior blog titled “Agents Have Boundary Issues”, where I pointed out that soft guardrails (e.g. system prompts etc.) are far from effective security controls, and even hard boundaries can be sidestepped by persistent agents.

Again, as someone who regularly reads AISI’s blog, this is a topic they have covered in their previous research as well in a blog titled “Cheating behavior in frontier model evaluations”.

Models cheat quite often, as they seek to achieve their goals and objectives and it often involves “creatively” working around their constraints.

This one is a bit scary for security practitioners because even if we implement various measures to mitigate organizational risks (e.g. relying on classifiers, LLM-as-a-Judge, hard architectural boundaries/controls etc.) there is still a good chance that the models and agents will work around them if they are impeding their successful pursuit of a goal.

It is easy to see the risks for enterprise agents, as users will be far less rigorous with their prompting, clarity to the agents, constraints and specifications as agents take actions within and beyond the enterprise.

Lack of Clarity of Exercise Scope

AISI rounds out the list of factors that could of potential contributed to the incident by discussing a lack of clarity of exercise scope.

Surely no enterprise users will provide unclear or ambiguous instructions to LLM’s and agents in their enterprises, right?

This one is among the most obvious to see how it can and will be problematic for security leaders, as not just development and technical users, but broader knowledge workers now leverage agents and this emerging technology to accomplish not just software development or cyber, but broader white collar tasks in their professional environments and roles.

AISI stated:

”The prompts could have, for example, instructed the AI agent not to use social engineering techniques – a recognised part of cyber tradecraft. Alternatively, the prompts could have instructed the model to err on the side of caution whenever it might be interacting with real humans; however, it remains unclear whether, or at what point, the agents recognised they were targeting real people”

Think about the implications of this one. This infers that users, including non-technical users, will need to provide incredibly specific instructions around what agents shouldn’t do, as much as what they should.

Are most enterprise users who are and will be touching this technology deeply familiar with your security policies? Do they understand appropriate/acceptable use? Have they read the stack of dusty security policies most organizations maintain for compliance purposes but no one ever actually reads?

Of course not…

So not only do we have a situation where we have to try and provide explicitly clear instructions to agents, but even if we could get all the enterprise users, including citizen developers and knowledge workers to do so, as we saw in the section above about cheating, even then, the agents may disregard those instructions anyways.

This is…problematic, to put it lightly.

Closing Thoughts

So, to wrap up us, we now have 3, potentially 4 incident disclosures related to LLM’s and AI agents from leading labs and research entities, where agents took unsanctioned or unanticipated actions as part of cyber evaluations, impacting real-world infrastructure and individuals and exhibiting nefarious behavior while doing so.

While there is nuance, such as these being cyber evals, a lack of classifiers, intentional internet access and other factors, the implications for security leaders and enterprises is clear.

We’re seeing this technology adopted at a pace we have never seen before, with a technology adoption J curve like a hockey stick, with agents on endpoints, cloud, SaaS and more.

Security is doing our best to keep pace, leveraging this technology as an early adopter and innovator ourselves, and looking to avoid our sins of the past as a late adopter and laggard.

But, even then, the anticipated challenges due to the people, process and technology paradigm in enterprise environments is stark, there will inevitably be governance gaps, misconfigurations, vulnerabilities and even intentional exploitation.

They say success leaves clues, well so does failure.

We have an opportunity to learn from the AI security frontier to try and ensure we enable our organizations with secure AI agent adoption, by avoiding some of the missteps of those blazing the trail ahead of us - but we have to be willing to look for the clues.

Subscribe now

If you missed it, I did a deep dive blog into the report titled “The Real Price Tag on Breaches”.

I’ve spent a lot of time pushing back on the fear-based statistics that dominate this industry, so a study built on roughly 70,000 real cyber insurance claims is exactly the kind of grounding the conversation has been missing. Alex and his team put concrete numbers behind questions we usually answer with anecdotes, and they were careful about what those numbers can and cannot say.

We chatted about:

• How the Breach Impact Study came together and why the DBIR team finally landed a cyber insurance claims dataset through CyberAcuView

• Why insurable loss is a floor and not a ceiling, and why reputational damage barely moved the numbers

• The decision to report medians instead of averages, including the footnote about not publishing the average so LLMs don’t spread it around

• The rise of business interruption and contingent business interruption, and the sub-limits that hid the real damage

• Whether an $83,000 median breach impact hands the wrong argument to a skeptical CFO

• The SMB paradox, where small companies can lose up to 7% of revenue while large enterprises rarely cross 2%

• Where AI actually shows up in the data, and why offense is running ahead of defense

• Third-party risk as the industry’s persistent blind spot

Prefer to listen?

Spotify

Apple Podcasts

Please be sure to leave a rating and review, as it truly helps the show!

A few takeaways:

Insurable loss is a floor, and business interruption is what moves the needle

The study only counts dollars paid through real policies, which Alex is upfront about calling a floor rather than a ceiling of the true economic impact. The team tried to measure reputational damage a few years back by cross-referencing known breaches against stock movements and found almost nothing.

As Alex put it, from the consumer side “nobody cares anymore,” and he probably has a couple lifetimes of credit monitoring to prove it. What actually changes behavior is downtime. “The thing that will move decision making is business interruption,” he said, and the data backs him up, with business interruption landing at roughly a third of all known losses in 2024. That is the number that gets an organization to treat this as a real problem.

The average is meaningless, the distribution is the point

Alex is blunt about why the team reports medians and refuses to publish an average. “It’s just that the information is meaningless for decision making,” he said. A five million dollar average headline, like the one making the rounds from another report, tells a company nothing about the risk it is actually accepting.

The percentiles do. For companies above $250 million in revenue, the top 2.5% of cases exceeded $22 million, which is the kind of figure an operational risk team can take to a board and decide how much of the distribution they want to be covered against. The single number is comfortable. The distribution is useful.

An $83K median does not mean breaches are cheap

I raised a concern I have heard from others, that dropping a median of around $83,000 in front of an executive invites the response that breaches are survivable and it might be cheaper to just eat the cost.

Alex did not hedge. “I think that’s a bad CFO,” he said, and made the point that the person reading that figure should be someone who understands what a distribution like that means. Any large company that looks at the median and ignores that its size alone puts it in the extreme tail is not doing operational risk properly. The report’s whole argument is to plan against the extreme cases, not the midpoint.

Small companies take the hardest proportional hit

The most uncomfortable finding for me is that SMBs can lose up to 7% of revenue in the extreme cases while large enterprises rarely cross 2%. The median SMB loss is a modest $38,000, but measured against revenue and thin cash flow it becomes existential, especially since an insurance payout is not automatic and you have to survive long enough to receive it.

Alex connected this to Wendy Nather’s cybersecurity poverty line and made a point I care about deeply. Ransomware crews moved down market a long time ago and industrialized the work, so being small is no longer a defense. It just changes the size of the ask.

AI is real, but offense is ahead of defense

I told Alex I could not find AI as an obvious fingerprint anywhere in the loss numbers, and he agreed the claims data simply does not carry that detail yet. The bigger problem is structural, since the DBIR anonymizes each dataset independently and cannot cross-correlate AI-assisted attacks with claims. What he is confident about is the direction.

“Offensive AI augmentation is way, way ahead of the curve than the defensive one,” he said, and everyone assuming a tidy AI versus AI showdown is ignoring that one fighter has a mean left hook and the other has not found its footing. His practical read is to stop waiting and rethink architecture. On taking flat networks and internet-exposed edge devices seriously, his line stuck with me. “The best time to do that was fifteen years ago. Maybe the second best time is now.”

If there is one thing to do on Monday, Alex pointed at third-party risk. Supply chain incidents are the single most likely to fully exhaust a policy, which means the recorded loss is a coverage cap and not the real number. His takeaway was direct. “Do not underestimate the impact that your third party can have.” Even the insurers, who understand risk better than most of us, have been caught off guard by it.

Thanks to Alex for coming on and for putting real numbers behind a conversation the industry usually runs on vibes. Follow his work through the Verizon DBIR and the new Breach Impact Study, and find him on LinkedIn.

Subscribe now

Valuations are stretching, incumbents are writing enormous checks, and founders are trying to build durable companies on top of a technology that reinvents itself every few months. That said, the people who see this landscape most clearly are often the investors placing bets across it, watching dozens of companies rise, stall, and get acquired.

Over the past few weeks I sat down with four of them, Sid Trivedi (Foundation Capital), Ed Sim (Boldstart Ventures), Jon Sakoda (Decibel), and Chenxi Wang (Rain Capital), to talk through where the money is going and why. Below is a short recap of each conversation, followed by the threads that ran through all of them.

So, let’s get into it!

Sid Trivedi - Cyber Valuations, Moats & the Road to Black Hat

In our conversation on cyber valuations, moats, and the road ahead, Sid Trivedi, a Partner at Foundation Capital, walked through the thesis his firm has been building around for a while now, what they call Services-as-Software. The idea is to look at every task and team across cybersecurity and ask which workflows can be automated, a market Foundation Capital has sized at $4.6 trillion. In Sid’s view, that thesis is largely playing out as expected.

The workforce question came up quickly, as it always does. Sid takes a measured line, telling me “I don’t worry that long term people will lose the ability to work. I think the jobs themselves will change.”

Automation reshapes the work rather than eliminating the worker, a framing I appreciate given how much of the AI conversation collapses into fear.

We also dug into valuations and defensibility, which is where things get harder. This is the era of Palo Alto’s $25 billion acquisition of CyberArk and Alphabet’s $32 billion acquisition of Wiz, of Torq crossing a billion-dollar valuation and Seven AI raising the largest cyber Series A on record.

Sid’s caution is that big raises create growth expectations that capital alone cannot fulfill, and that when frontier labs can replicate a product feature in weeks, the traditional notion of a moat starts to look shaky. Consolidation and best-of-breed will keep coexisting, but defensibility now has to come from something deeper than a feature set.

Ed Sim - Building and Investing When Mythos Changed Everything

has been an inception-stage investor for nearly 30 years and has run Boldstart Ventures since 2010, with roughly a third of the firm’s investments in cybersecurity. In our discussion on why AI security is getting rebuilt, he made the case that much of the security stack is being re-architected in real time, and that the durable moats of the past, which used to last twelve to eighteen months, now erode much faster.

Ed’s blunt read on the market has stuck with me.

“The world needs more cybersecurity, but we don’t need all the cybersecurity companies that we have right now,” he told me, a line that captures both the demand and the coming shakeout.

He was an early investor in Protect AI, which went on to sell to Palo Alto Networks in a reported $700 million exit.

Two ideas from Ed stuck with me from the conversation. The first is data, where he argued that “the biggest heist ever happening right now is that OpenAI and Anthropic created their own forward deployed engineering companies,” a pointed way of naming who actually captures the value from enterprise workflows.

The second is agentic identity, which he frames as a genuine category rather than a feature to bolt on, built around ephemeral, dynamic identities rather than the static accounts we manage today. Across portfolio companies like Keycard, and Surf AI, that thesis about identity and agents is where he sees a lot of the next wave forming, even as agents remain a small share of what is actually running in production.

Jon Sakoda - AI, Cyber & Where the Smart Money Is Going

Jon Sakoda, Founding Partner at Decibel and previously an investor behind companies like Cloudflare, MongoDB, and HackerOne during his time at NEA, brought the sharpest framing on separating signal from noise.

In our conversation on AI, cyber, and where the smart money is going, he pushed back on the idea that AI alone makes a company special.

As he put it, “AI is really only magical to the extent you have a magic power.” AI lowers the barrier to starting up, which means competition goes from thousands of entrants to millions, and domain expertise becomes the thing that actually differentiates.

Endpoint is where Jon is putting real conviction behind that view. He calls it “the Super Bowl of cyber” and points to Decibel’s $100 million seed investment in Ent, founded by veterans of RiskIQ and the Microsoft Security Copilot team, as commitment sizing for a market big enough to take on the incumbents. He describes endpoint as having its own self-driving moment.

On the autonomous SOC, Jon is optimistic but patient. He likens tools like Claude Code to driver assistance for the SOC, useful today, while truly autonomous products still need to log a lot of operational miles before earning customer trust, the same way self-driving cars had to. His investment in Dropzone AI fits that arc.

Zooming out, Jon believes cyber’s best years are still ahead, and that resilience and cyber insurance may end up being larger opportunities than detection and response alone. It is a genuinely optimistic take, grounded in where budgets are actually heading.

Chenxi Wang - Cyber Investing In the AI Exploit Era

, Founder and Managing General Partner at Rain Capital, is one of the most technical investors in the space, with a background spanning a professorship at Carnegie Mellon, an analyst seat at Forrester, and operating roles at Intel Security and Twistlock. In our discussion on cyber investing in the AI exploit age, she laid out how AI changes the economics for attackers, not just defenders.

Her central argument is that vulnerability discovery is shifting from something scarce to a continuous output of computation, and that the window between a vulnerability being found and being exploited is compressing from weeks toward hours.

That reframes what a defensible security company even looks like, since strategies built around scarcity of exploits start to break down when exploitation becomes cheap and constant.

Out of that thesis comes her interest in what she calls guardian agents, AI systems that supervise and govern other AI, along with a hard look at AI agent identity as distinct from the non-human identities we already struggle with, the service accounts and API keys sprawled across every enterprise. Chenxi also had a clear-eyed view of the funding environment, describing capital concentrating at the extremes while Series B and C rounds face real constraints, a dynamic worth watching for any founder mapping out a raise. She also highlighted how cyber as a category is also tied to the broader IT and AI categories, and headwinds there could lead to headwinds for us.

For anyone who wants her ongoing analysis, her Rain Capital Insights newsletter reaches more than 23,000 readers with some of the sharpest monthly commentary on where AI and security collide.

Common Threads

Four investors, four different vantage points, and a striking amount of overlap.

• The clearest thread is the death of the durable moat. Both Sid and Ed circled the same problem, that when frontier labs can replicate features in weeks, defensibility has to come from proprietary data, distribution, and domain depth rather than functionality alone.

• A second thread is identity. Ed and Chenxi both treat agentic identity as its own category, not a feature, driven by the reality that agents need ephemeral, auditable identities that our existing non-human identity practices were never designed to handle.

• A third is the reshaping of security work itself, whether you call it Sid’s services-as-software or Jon’s self-driving SOC, the theme is automation of workflows we have long assumed required humans in the loop, tempered by the recognition that trust has to be earned over time.

Finally, all four are watching the same bifurcated capital markets, enormous deals and record raises at the top, with real pressure in the middle. Chenxi named the Series B and C squeeze directly, and Sid’s caution about spending your way to growth is the flip side of the same coin, as it comes with potential tension and expectations among your investors.

Closing Thoughts

If there is a single takeaway heading into Black Hat, it is that AI is changing both sides of the equation at once, the economics of attack and the economics of building a company to defend against it.

The investors moving early are not the ones with the loudest AI messaging, they are the ones betting on data, identity, domain expertise, and the slow work of earning trust in autonomous systems. Whether the current valuations hold is very much up for debate. That said, it is clear that the smart money is already positioning for a market that looks very different from the one we walked into last year.

My thanks to Sid, Ed, Jon, and Chenxi for the conversations, and I would encourage you to listen to each interview in full!

Subscribe now

Chenxi has seen this industry from the professor’s podium at Carnegie Mellon, the analyst seat at Forrester, the operator chair at Intel Security and Twistlock, and now the cap table, which makes her one of the most technical investors in security. She closed out my July run of conversations with security investors, and this one went deep on how AI is rewriting both the attacker’s economics and the investor’s.

We chatted about:

• Her path from professor to analyst to operator to founding Rain Capital

• The AI Exploit Age, where vulnerability discovery moves from scarce to continuous and exploitation windows compress from weeks to hours

• The Guardian Agent thesis and whether it really takes an AI to govern an AI

• How AI agent identity differs from the traditional non-human identity bucket of service accounts and API keys

• The signals that tell an early-stage investor enterprises will actually buy

• Capital concentrating at the extremes while Series B and C funding stays constrained

• What security leaders should be doing differently over the next twelve months

Prefer to listen?

Apple Podcasts

Spotify

Please be sure to leave a rating and review, as it truly helps the show!

A big thanks to Chenxi for coming back on the show. You can follow her work through Rain Capital Insights, where she writes some of the sharpest monthly commentary on where AI and security are colliding.

Subscribe now