This is great news, especially for me, as I’ve spent a good portion of the past 18 months advocating for security to be an early adopter and innovator with AI if we want to have any chance to keep pace with the attackers use of the technology and its impacts from the industrialization of vulnerability discovery to autonomous exploitation.

It shows up in the data as well, with IBM’s 2026 Cost of a Data Breach report finding more than 50% of organizations reported using agents for threat detection and containment and 25% of breaches being AI-enabled.

Initial access in breaches continue to be tied to what is reachable from the Internet, with exploitation being a top initial access vector, and despite that only 25% of KEV’s that are critical get fully remediated.

While teams such as SOC’s are undergoing major modernization efforts to combat these trends, they’re often doing it just looking internally, while flying blind to broader context regarding what is happening outside the organization.

The truth is AI-driven SecOps are only as good as the external data and context powering them and without the right data, we run the risk of AI reaching the wrong or incomplete conclusions, just faster.

That’s why I wanted to take sometime to walk through the importance of that broader external data, what it tells us and how teams such as Resilient Cyber’s partner Censys provides.

So, let’s take a look.

A lot of the insights and metrics I discuss below are from Censys’s recent 2026 State of the Internet Report, so be sure to grab a copy to check out the full report!

-> Grab the SOTIR Report! <-

A Decade of Looking Inward

We’ve seen ten years of SecOps investments going to areas such as endpoints, logs, cloud posture and identity, all of it aimed at better describing what is going on within an organization.

This is critical of course, as SecOps is responding to activities going on within the enterprise, especially those that seem anomalous or malicious. However, the outside-in view is the one the adversary already has, and organizations often cannot see their own external network footprint as well as an outsider can, and their ability to act on that external exposure is only getting accelerated as attackers adopt AI and agents into their activities from enumeration through exploitation.

I often write a lot about CVE’s and vulnerability management, and organizations tend to look across their estate similarly. This is an important activity, given those vulnerabilities are what adversaries exploit. That said, from sources such as the 2026 DBIR we know there are exploited vulnerabilities with no CVE assigned, especially as institutional sources we rely on such as NVD and KEV stumble from the load of AI-driven vulnerability discovery.

CVE-centric vulnerability management isn’t the same as knowing your organizational exposure and the outside-in view is the one the adversary already has and will be acting on.

Many organizations have made efforts to get external data sources such as threat intel feeds, or even building their own OSINT, or even buying aggregators but many of these sources are either stale by the time they arrive or require significant internal efforts to operationalize, taking from the teams bandwidth to do work directly tied to reducing organizational risks.

We’re also seeing another trend, which is teams that do adopt AI and automation in SecOps have reduced breach costs by almost $2M on average per IBM, which is a great sign, but those efforts ultimately need to be powered by high fidelity context that is sourced both internally and externally.

In my experience building large security programs both at Federal agencies as well as in the commercial sector, there is almost always an emphasis on the internal context and data sources, while external telemetry is treated as optional and it is hard to truly respond to adversarial behavior where were largely flying blind to what that looks like at Internal-scale.

What Good External Data Looks Like

But what does “good” external data actually look like?

This is where I was truly impressed with the scale and vast amount of high quality data the team at Censys possesses. I’ll admit I wasn’t deeply familiar with them prior to meeting with the team and digging in, but once I did and saw not only the data, but also the long list of highly critical private and public sector organizations that rely on them including 50% of the Fortune 500 and 40 national defense and intelligence agencies, I was truly impressed. To put their data in perspective, let’s explain what some of it is.

The first is the scale, where they have indexed 220 million hosts, 17 billion certifications and 2.9 billion web properties/endpoints. They scan the entire public IPv4 address space across all 65,000+ ports and have 17 billion TLS certificates as of 2 September 2026.

This includes a daily refresh of 3.3B services, over 254M IPv4 hosts, 1.2B virtual hosts and a daily comprehensive scan of all ports that is updated daily in their Internet Map.

Next after scale is the coverage, which includes a growing list of IPv4 services which grew from 275M in 2015 to nearly 794M currently, a 188% increase. Their coverage also includes up to 96% of services on the top 10 ports and 92% across the top 100 ports, with new services detected in less than 13 hours on average.

Four key properties of their data includes:

• First party - Censys originates the raw scan data rather than being an aggregator third party. This means several of the largest security vendors and threat intel shops actually depend on Censys as a data source for their own research.

• Continuous - It is refreshed every 8 hours on average and everything being researched within 16 hours and users can trigger live rescans and DNS resolutions as well.

• Longitudal - They posses over 4 years of history in their application, and their ARC research team works from raw data going back 8 years.

• Contextual - Including multi-year X.509 history, web property snapshots, open directory identification and mapping from infrastructure back to domain names.

A Censys agentic investigation from a single provided IOC

This first party data buys defenders source data they can trust, that is already trusted by critical organizations and security vendors alike, at a scale few, if any organizations can claim. The source and fidelity of this data is absolutely critical for AI systems empowering SecOps and internal defensive efforts as well, to understand the ecosystem malicious activities are originating from.

Where Does Context Change The Answer?

We’ve talked about what good data looks like but where does it truly change the conclusions and actions AI-driven defensive systems take?

Censys’ key claim is that AI on the wrong data gets to the wrong answer, just faster. The way to test this out is to look at the workflows the AI SOC is being pointed at and ask where the same question might of yielded a different answer with external context involved.

Censys published their 2026 “State of the Internet Report” today, the latest edition of their annual research built on the same Internet-wide scan data discussed above, and this year it takes measurements across five areas, ports and protocols, vulnerability response, industrial control systems, threat infrastructure, and exposed AI infrastructure, with the stated goal of establishing a baseline they can revisit year over year. I will draw on it throughout the rest of this piece, and it is worth reading in full for the sections I don’t get to.

For our purposes, let’s start with triage, including the asset inventory queues get built on, because the report’s data suggests it is wrong in ways most teams haven’t accounted for.

For example, they found that 34% of SSH instances run on a port other than 22, 68% of HTTP(S) services run on ports other than 80 and 442 and 96% of SOCKS proxies run somewhere other than 1080. For example, a rule checking only port 1080 for SOCKS exposure would be operating on just 4% of the actual population.

This problem gets even worse when assets aren’t in your IP space at all, such as where roughly 70% of the 134,000 exposed ICS hosts Censys observes sit on consume and mobile carrier networks via cellular models, where WHOIS points to the telco rather than the operator, so an operator searching against their registered netblocks will miss their own endpoint.

Now if you consider triage with an emphasis on reachability, which is a topic I often stress, things look different as well. In a demo I got from Alex of Censys, their attack surface management product took a customer’s domains and CIDR ranges and using a vulnerability disclosed a week prior, returned 264 instances visibile on the public Internet, each mapped to its specific CVE, KEV and EPSS score. Reachable of course gets the emphasis from attackers, and should get a prioritization from defenders for that very reason, especially against a 43 day median and 26% KEV remediation rate we see currently in the ecosystem.

Then we have investigation, where context does the most work. Investigators are often handed artifacts, such as IP addresses in logs, a hostname, or a tool fingerprint that rarely explains itself. Two findings in the reports threat infrastructure section make the point.

The first is about geography, with a lot of threat intel reporting treating “traffic from China” or “hosted in the U.S.” as a signal of who the actor is, but Censys data suggests actors don’t pick a country, they pick a provider, based on cost, and how easily infrastructure can be spun up through an API, as well as how tolerant the hosting provider is of abuse. The country is basically a byproduct of that choice, and it tells you less about intent than many assume.

The second and hard problem is the dual use nature involved. The three largest items in Censys’s tracked threat infrastructure are FRP, a reverse proxy for exposing internal services through a firewall, NPS, a similar tunneling proxy with central management and Nezha Monitoring, a server monitoring agent.

Together they make up 85.2% of everything Censys tracks as threat infrastructure and all three are ordinary sysadmin tools that attackers also happen to leverage. “FRP detected” is a true finding that carries almost no binary verdict on its own, since a given instance is as likely to be a developer exposing a test box as an attackers tunnel.

You could have two identical FPR instances, with one sitting on a bulletproof hosting environment that ignores compute complains and another on a mainstream cloud provider with a working abuse reporting function that is responsive. In both cases the fingerprint is the same, what separates them is the surrounding context, such as the providers reputation, what else may be running on the same host, its certificate and DNS history and how long it has been there.

This is the type of context external Internet data supplies and most SOC teams lack, and an agent working without it could potentially flag the developers test system and miss the tunnel, as one example.

When it comes to threat hunting, this is the workflow that benefits the most from historical depth, since the point is to pivot from one node to the cluster. In the demo I had from the Censys team, they fingerprinted C2 frameworks and AsyncRAT forks, labeled hosts on bullet proof providers and walked through open directories where staging scripts and data dumps sat in plain view.

Where a given SOC has a threat hunting function that can use this is a far question given many organizations lack this capability. That said, this is also where AI SOC has a real opportunity because an agent can take an IOC, expand it into surrounding infrastructure using years of DNS and certificate history, and hand an analyst a written-up cluster, which is work most teams never have the headcount for.

A live open directory of threat actor and “EDR Killer” tools in Censys

There’s a couple of other points beyond the perimeter that are interesting here as well. For example, Verizon found third-party involvement in 48% of breaches this year, and Censys told me they are building out supplier monitoring as part of their upcoming Supplier Risk module, which I thought has promise given there’s value related to procurement, M&A diligence, and enforcing vendor SLA’s.

On the Federal front, reachability is functioning as a compliance trigger. CISA’s BOD 23-2 gives agencies 14 days to remove networked management interfaces from the Internet once scans find it, and given the threat activity we’ve seen in recent years, identifying and removing those externally exposed attack paths is critical.

The AI Stack Is Part of the Surface Too

Much of what we discussed above is about defending the environment you know you have. That said, there is plenty of shadow AI already becoming pervasive and the outside in assessment is a great way to identify what the organization has stood up without telling you.

To highlight just how pervasive AI has become, as of July 2026, Censys observed 267,915 hosts exposing AI or LLM-related tooling to the public Internet, up 63% in nine months, across 44 products spanning more than 20 functional categories.

The exposed stack is overwhelmingly tied to plumbing, meaning inference servers, LLM gateways, orchestration platforms, vector databases, and agent control planels, most of which were only ever meant to talk to the app in front of them. Their report attributes much of it to “vibe coding” and shadow AI, but either way these systems land outside of security’s visibility.

n8n is a good example, since it began as a workflow automation platform and has repositioned itself as an AI orchestration layer with native support for agents, model providers and MCP, which means it sites between external inputs, stored credentials and every downstream service it connects to.

Censys found roughly 114,000 exposed instances, 67% of which had the native port directly reachable, a median deployment 103 releases behind the current and 76.1% of versioned hosts in range of at least one CVSS 9.0 or higher vulnerability disclosed in the previous six months. That is the orchestration layer holding the keys to everything behind it, and badly out of date and vulnerable. I would call it the Jenkins of the agent era, and I say that with some affection for having lived through the Jenkins era of DevOps.

OpenClaw on the other hand is a tempo warning. Censys saw two exposed control panels on January 11th, and a peak of 85,478 on April 7th, before a token-leaking CVE and a Chinese government restriction on state-sector use brought the count back down. As the report put it, a new AI product can go from obscurity to 85,000 exposed hosts in weeks, faster than security practices or governance can catch up, and the next one may sit closer to enterprise data as we see Personal AI (PAI) take off such as Meta’s Muse or xAI’s Grok Bot.

Censys is careful to say that exposre does not by itself prove an asset is insecure, with ICS as the exception where exposure itself is the vulnerability. I would extend that exception to agent control panels as well. A console that gives operator-level access to an agent and every account wired into it has no business being reachable from the public Internet, and the OWASP Agentic Top 10 I’m involved in treats that orchestration and credential-holding layer as exactly the kind of asset that deserves its own hardening posture.

IBM’s data points in the same direction, with more than 20% of organizations reporting a breach targeting AI models or applications and the leading causes being compromised API’s plug-ins', and cloud misconfigurations, which is to say the system around the model, rather than the model itself.

Turning Intelligence Into Action

During my discussion with Censys, they explained how they deliberately avoided marketing themselves as an AI security company. Despite extensive use of AI within the product, they see their value as feeding into the AI automations customers already run, which Censys describes as being the intelligence and context layer for AI-powered security workflows, or in Oliver’s framing, AI plus context, both internally and externally.

What they have built on the AI side is early and worth describing as a direction rather than an endorsement. This includes Persona-based summaries tailored to the same host data for a SOC analyst, researcher, or a vulnerability analyst, an MCP server lets an organization’s own agents query the dataset directly, and an agentic investigation feature that takes a set of IOC’s, expands the cluster, and produces a detailed summary.

The more durable idea underneath it all is delivery, with webhooks pushing asset changes in real time into firewalls, SIEM and SOAR, because another console nobody logs into is not security value.

For a security leader evaluating any vendor’s “AI-powered” SecOps claim, that suggests the things worth asking about, such as what data the AI actually sees and whether any of it is external, whether the agent is given a bounded and provenanced source over MCP or is browsing the open web and ingesting whatever it finds, and whether a human is in on the action.

Handing an agent a love map of the Internet changes its risk profile in ways the OWASP Agentic Top 10 catalogs fairly well, from the scope of what it can query, to the permissions on what it can act on, to prompt injection through fetched web content. Teams would be well served to treat the data sources as a privileged integration rather than a search box.

Censys’s forecast in the report is that AI is becoming an infrastructure layer on the Internet rather than a product category, with its attack surface taking shape in real-time. That’s a take I agree with, and add that the AI SOC two years from now is going to be judged less on how clever the agents are and more on what they are allowed to see and the security implications that comes with that.

Censys also has an AI SOC eBook coming that goes deeper on the operational side and their 2026 “State of the Internet Report” (SOTIR) went live recently, for anyone who wants the full dataset behind the figures above.

Closing Thoughts

While this is isn’t an all encompassing discussion, Censys’s dataset os one of the most comprehensive I’ve come across and it is impressive and easy to see the value for various security use cases, including other security tools and capabilities.

It’s clear to me that external Internet intelligence is a major security primitive security programs are often missing and that AI has raised the cost of missing it on both sides, for attackers who now move faster than our patch cycles across industrialized AI-discovered vulnerabilities, and also for defenders who are automating decisions on half of the picture.

If we hand agents the same inside-out data we have always had, we should not be surprised when they got the wrong answer sooner than we did.

This reality should cause teams to step back and ask what their AI SOC can actually see, and what is it missing.

Subscribe now

2,096 were disclosed to maintainers and just 202 have been fixed so far, which is 0.8%. OpenAI's Patch the Planet found 1,646 issues, brought in Trail of Bits to write 615 patches and hand them to maintainers, and 13% have merged.

None of that is a failure. Both programs did something the industry could not do a year ago, and both labs were unusually transparent about the results. Anthropic's own update calls independent human triage and review the rate limiting step. The model is not the constraint. The humans are.

These programs were the best case scenario, with frontier models, frontier researchers, high profile projects that actually wanted the help, and in OpenAI's case patches written and delivered.

If remediation was ever going to keep pace with discovery, it was going to happen here.

Open source has lived this for years, and AI discovery is about to export the same experience to every enterprise codebase, most of which were already underwater before any of this started.

In the video I cover:

• What Glasswing and Patch the Planet actually did, and what their own funnels show about where the bottleneck sits

• The severity gap, with Claude rating 91.5% of its findings critical or high and maintainers rating 51.3% that way

• Why your backlog was already a problem, with FIRST now forecasting 66,000 to 68,000 CVEs for 2026 and Empirical Security finding 15,222 exploited CVEs that never made the KEV

• What attackers are doing with the same models, including Anthropic's research on exploit chains finishing before patches reached devices

• Six practical moves, starting with buying triage instead of more scanners and layering exploitation signals beyond the KEV

Shout to my friend to Patrick Garrity at VulnCheck for reconciling the Glasswing ledger, and to Casey Ellis for the line I keep quoting

The volume apocalypse was already here, it just wasn't evenly distributed.

For the full written analysis, see my article The Bottleneck Was Never Finding Bugs.

The question I close on is the same one from the article, are we going to build the remediation capacity to match, or keep celebrating the size of the backlog?

Subscribe now

The industry spent two decades hardening the perimeter, pursuing approaches such as Zero Trust, and attackers responded by simply acquiring a working credential and walking through the front door as a legitimate user.

As the saying goes, hackers don’t hack in, they log in.

That said, most of the conversation around identity risk stays at the level of controls, such as MFA coverage, privileged access, session management, and so on, and rarely gets translated into what the gap actually costs an organization when it goes unaddressed.

Resilient Cyber’s partner Nametag recently published a report titled “The Cost of Doing Nothing: What Unverified Identity Costs Enterprises Every Year,” which attempts to do exactly that, breaking the cost of unverified workforce identity into four dimensions and modeling it across six industries.

In this article I will walk through the report’s core argument, the four cost dimensions, the industry-level figures, and where I think this connects to the agentic identity problem I have been writing about for much of this year.

So, let’s check it out!

-> Check Out The Report! <-

Logging In, Not Breaking In

The report opens with a framing that will be familiar to anyone following the incident data.

It cites Sophos analysis of 661 incident response cases across 70 countries and 34 industries between November 2024 and October 2025, in which identity-related root causes drove 67% of successful intrusions, with compromised credentials alone accounting for 42% of root causes. Sophos also found MFA absent or misconfigured in 59% of identity-related incidents, and where MFA was correctly deployed, attackers adapted with adversary-in-the-middle proxies and infostealers that lift active session tokens after authentication completes.

The report pairs this with figures from Cloudflare’s 2026 Threat Report, which found that 63% of logins involve credentials already compromised elsewhere and that 94% of login attempts originate from bots rather than humans.

The economic logic here is straightforward, as it is simply cheaper to use a credential that already works than to develop a new exploit or need to compromise a system. A valid username and password pair is a commodity, and the report’s summary of the situation, “the attackers are not breaking in, they are logging in,” is one I would expect most practitioners to nod along with at this point, as we’re used to hearing it, but it also doesn’t make it less true.

None of this is new to security teams, and the report acknowledges as much.

MFA is deployed, the IdP is in place, and the helpdesk has a runbook for password resets. The argument is that this foundation was built to confirm which account is acting, and it cannot confirm which human is acting. That distinction is the entire premise of the report, and everything downstream flows from that core point.

Accounts Versus Humans

The framing I found most useful is what Nametag calls the workforce identity gap, defined as the structural gap between authenticating an account and verifying the human behind it.

Authentication confirms a credential, but does not confirm the person presenting it, and every downstream control, from role-based access to privileged approvals, inherits that assumption without ever testing it.

The report lays out a four-stage maturity framework for closing that gap.

• Stage 1 is manual verification, where helpdesk staff use their best judgment and the organization carries its full loss exposure.

• Stage 2 is what Nametag calls compliance-grade verification, meaning point-in-time selfie matching bolted onto custom integration logic, which the report estimates retains 50 to 60% of baseline exposure.

• Stage 3 adds 3D liveness, cryptographic device binding, and identity orchestration, reducing residual exposure to 15 to 25% of baseline.

• Stage 4 is continuous assurance across the entire workforce lifecycle, with residual exposure in the single digits as a percentage of baseline.

Nametag’s view is that most organizations sit at Stage 2, and that the cost of waiting is the difference between Stage 2 and Stage 4, multiplied by every week the gap stays open.

I would add that many organizations I have seen are honestly closer to Stage 1 than they would like to admit, with verification for high-risk actions like credential recovery still coming down to whether the person on the phone sounds plausible and knows a manager’s name.

The report also argues that compliance-grade identity verification clears the audit checkbox without closing the actual gap, and anyone who has watched a homegrown verification workflow accumulate human resource system webhooks and custom logic over a few years will recognize the maintenance burden it describes.

Four Ways Inaction Shows Up on the Books

The heart of the report is a breakdown of the cost of inaction into four separate dimensions, each owned by a different executive, each accruing in a different part of the budget, and each paid whether or not the others are.

These are four distinct bills rather than one cost that compounds on top of another, which is part of why the exposure is easy to miss, since no single owner sees the whole picture.

The figures throughout are illustrative for a 15,000-employee organization, which matters for how you read them, since Nametag notes they scale roughly linearly with workforce size.

Operational efficiency is the IT labor and overhead of running manual identity verification. The report uses HDI’s benchmark of $25 per helpdesk ticket in labor and tooling, and Nametag’s own deployment data puts the enterprise identity verification figure at $3.45 per ticket, roughly an 86% reduction, primarily from routing verification events through self-service workflows that never touch the helpdesk.

At the modeled scale that works out to $1.25M annually in IT labor at the manual baseline. The report also calls out the hidden costs here, such as custom integration work running into tens of thousands of dollars per use case with roughly 20% annual maintenance on top, and the fact that helpdesk headcount scales linearly with the workforce, so every new employee adds verification volume that has to be absorbed somewhere.

Workforce productivity is the flip side of the same friction. Every hour the helpdesk spends verifying someone is an hour that employee spends waiting, and the report values those hours at fully loaded compensation, ranging from roughly $37 an hour in hospitality and retail to nearly $90 in technology.

Annual productivity loss lands between $1.92M in Hospitality, Retail & Consumer and $4.48M in Technology. The healthcare figure is the one stated in concrete terms, at 22,500 clinical hours lost per year, which the report equates to 5,400 primary care visits. Nametag estimates enterprise identity verification recovers roughly 80% of those hours.

Annual Loss Expectancy (ALE) is where the CISO and CFO share ownership. This is standard actuarial math, the probability of an identity-based breach in a given year multiplied by the average cost when it happens.

The report anchors the cost side on IBM’s 2025 Cost of a Data Breach Report, which puts the U.S. average at $10.22M and the global average at $4.4M, with Healthcare at $7.42M for the fourteenth consecutive year as the most expensive sector.

Baseline ALE ranges from $1.27M in Transportation to $4.97M in Healthcare, and Nametag models a 92% reduction in annual rate of occurrence with enterprise IDV, based on its own deployment data.

The report is direct that this constant comes from Nametag deployments rather than independent research, and applies it uniformly across industries, which is something to keep in mind when reading the residual figures. That said, it is refreshing to see that transparency from a vendor, which isn’t often so common.

Hiring fraud is the fourth dimension, and the one I suspect will be new territory for many readers, so it gets its own section below.

The report’s preferred way of reading all of this is by the week rather than the year.

Taking the four costs together, Healthcare carries roughly $150,000 a week in identity exposure, Technology $134,000, and Industrial Manufacturing $126,000. The annual figure is the headline, but the weekly rate is a more honest way to think about the cost of a deferred decision, since every procurement cycle that slips a quarter has a number attached to it.

Hiring Fraud and Strict Liability

Hiring fraud is the identity risk that arrives before an employee’s first day, and the past two years have made it a mainstream concern rather than a niche one, with the rise of deepfakes and nation state fraud campaigns.

The report cites a Gartner survey finding that candidate fraud makes up roughly 25% of application volume in remote technology roles in 2026, most of it automated AI-generated applications and resume fraud.

The smaller and far more dangerous slice is sophisticated identity impersonation, and here the report leans on Mandiant’s M-Trends 2026, which documents North Korean IT worker operations as a persistent insider threat throughout 2025 with a median dwell time of 122 days before detection and some cases running undetected for over a year.

Those of us who have followed the Treasury, FBI, and DOJ advisories on this know the playbook, with AI-generated profiles, deepfake interview tooling, and U.S.-based laptop farms used to embed operatives directly into Western corporate payrolls. The report notes a single 2025 federal case that named 309 U.S. companies which had unknowingly placed North Korean operatives on payroll, including Fortune 500 firms in technology, aerospace, automotive, and media.

Nametag breaks the cost into three buckets.

• The first is recruiter labor spent investigating suspect applicants, roughly 2,600 hours a year at $43 an hour fully loaded, or about $112,000 annually whether or not a fraudulent hire is ever caught.

• The second is the economics of placements that succeed, with roughly eight fraudulent placements a year at a typical enterprise drawing about $625,000 in salary against the 122-day median dwell plus another $415,000 in ramp and vacancy loss, for roughly $1.08M annually.

• The third bucket is categorical rather than operational. Civil penalties for paying a sanctioned individual are strict liability under federal law, so intent and awareness do not matter.

  The report puts the penalty at up to $377,000 per paycheck issued, with each paycheck treated as a separate violation, and a 122-day median dwell generates roughly nine paychecks. That is a maximum civil exposure of $26.7M per fraudulent placement, before any criminal exposure or remediation cost.

The point the report makes about existing hiring controls is a fair one.

A background check confirms that records match a candidate’s stated history, and a video interview confirms a face matches the documents, but neither confirms the person presenting those records is real or that the face on camera is the one that shows up on day one.

State-sponsored operatives use stolen identities from actual U.S. citizens whose records pass every standard check cleanly, which is precisely why the standard checks do not catch them.

What Doing Nothing Costs By Industry

Taking the four separate costs together and excluding OFAC exposure, the report puts the annual cost of inaction for a 15,000-employee organization at:

• $7.8M in Healthcare, $6.96M in Technology

• $6.54M in Industrial Manufacturing, $5.25M in Education

• $4.31M in Transportation

• $4.12M in Hospitality, Retail & Consumer

Each industry chapter pairs the numbers with a breach the reader will recognize, and the common thread across all of them is that none began with a software exploit.

Change Healthcare began with credentials on a Citrix portal that lacked MFA, with attackers operating for nine days before deploying ransomware and UnitedHealth Group reporting an $872M financial impact in the first quarter following the attack.

Snowflake began with credential stuffing against customer accounts lacking MFA, with data exfiltrated from more than 160 enterprise customers.

MGM and Caesars began with a ten-minute social engineering call to the helpdesk. The Diesel Vortex cargo theft operation in the transportation chapter began with voice-AI impersonation of freight brokers and dispatchers and generated $725M in cargo losses.

The sector-specific structural conditions are what make each chapter worth reading on its own. Healthcare runs on identity at a scale no other sector matches, with physicians carrying dozens of active logins and affiliate clinicians moving through the same identity stack with weaker governance.

Technology concentrates the cost in its most expensive labor, and the report notes identity-driven breaches there average 210 days of dwell, the longest of any sector, because the same DevOps access patterns that enable velocity also make anomalous behavior harder to spot. Hospitality and retail run 70 to 100% annual frontline turnover, which turns the helpdesk into the attack surface of choice.

Over a 24-month horizon, the report models a healthcare organization absorbing roughly $15.7M across the four costs by leaving the gap open, versus $1.3M with enterprise IDV in place and $8.6M with compliance-grade verification, which only closes about half the gap. The costs do not build on one another over that period, they simply keep accruing in parallel for as long as the gap stays open.

Where This Meets the Agentic Identity Problem

The section of the report I want to spend the most time on is the shortest one, a brief aside titled “AI Agents and the Authorization Question.”

Nametag’s argument is that enterprise AI agents act on credentials, authenticating as a human user, holding the same access rights, and executing workflows that move money, change records, and grant access. When an agent’s action triggers a high-consequence outcome, the question of who authorized it has to be answerable, and the verified human layer that closes the workforce identity gap is the same layer that makes agent actions accountable.

I have spent much of this year on exactly this problem. In “Identity Is the Agentic AI Problem Nobody Has Solved Yet“ I argued that the IAM industry built decades of infrastructure on the assumption that requests come from humans or from predictable service accounts, and that agents fit cleanly into neither category.

In “Identity as Infrastructure in the Agentic Era,” Karl McGuinness and I walked through why the problem is less about authentication and more about delegation, or as Karl put it, “agents don’t need your passport, they need your authority”.

Now, to be clear about what this report is and is not, it is a workforce identity verification report, and the agentic material occupies a page. It does not attempt to solve delegation chains, scoped authority, revocation, or any of the substrate problems Karl and I discussed. That said, I think the connection it draws is the right one, and it clarifies something I have been circling for a while.

Every delegation chain terminates in a human.

An agent acting on my behalf carries my authority, and the entire governance model for that agent, from the initial grant through every subsequent tool call, rests on the assumption that the “me” who granted it was actually me.

If the account that provisioned the agent, approved its scope, or authorized the high-consequence action was itself operated by someone who socially engineered a helpdesk reset last Tuesday, then every downstream control built on that grant is governing an attacker’s intent with full fidelity. The identity gap the report quantifies for workforce actions today gets inherited wholesale by every agent those workers stand up, and the volume multiplies with it.

This is why I think the “verify at login” mental model is running out of road.

The report frames verification around four moments where the existing stack assumes a human is present, recovery, helpdesk, hiring, and elevated-privilege approvals, and I would argue that agent provisioning and scope expansion belong on that list as a fifth.

Knowing that the human behind the account is the same human behind the request, every time, is the root of trust that agentic security will have to be built on, and we do not get to skip that step.

There is a budgeting implication in that as well. The report frames these four costs as IT, HR, and security line items, which is where they land today, but if the verified human layer is what makes agent actions attributable, then the spend to close the gap belongs in the AI budget alongside the platforms and tooling it is meant to govern.

Most organizations standing up agents are already carving out a responsible use or AI governance line, and I would argue that human identity verification is a more defensible entry on that line than much of what currently sits there, since it is the control every other agent control depends on.

Also, if you are interested in the rise of Deepfakes, identity and the role of AI, Nametag’s CEO Aaron Painter has a new book coming out called “Deepfaked”, be sure to check it out here!

-> Check Out The Book! <-

Closing Thoughts

This is far from an exhaustive discussion identity challenges or its intersection with Agentic AI, and the usual caveats apply to any vendor-modeled cost report.

The figures are illustrative for a 15,000-employee organization, the reduction constants come from Nametag’s own deployments, and the report itself says the numbers are a starting point for an internal modeling exercise rather than a substitute for real-world analysis tied to your incident history and I would treat them that way.

That said, the underlying inputs are public, the external anchors (IBM, Verizon, Sophos, Mandiant, HDI, and the OFAC penalty schedule) are the ones most of us already cite, and the core argument holds regardless of how the constants shake out.

Authentication confirms an account, and nearly everything we do in security downstream of that assumes it also confirmed a human. The incident data says that assumption is where most intrusions now start, and we are about to hand the same unverified assumption to autonomous systems operating at machine speed.

The status quo, as the report puts it, is an expensive option that does not show up that way on any single budget line, which is why it stays in place. Whether the exact number is $4M or $8M a year for your organization, it is a number, and it is worth knowing before the next procurement cycle slips another quarter. You can read the full report, including the industry chapters, here.

Subscribe now

I previously referenced their excellent publication on Agentic IAM for a blog, and interviewed the authors on the Resilient Cyber podcast. Now, they recently released a great whitepaper on Zero Trust for AI systems and I wanted to take sometime to walkthrough it here, because despite all the hype and media narrative of existential risks, most of the cyber risks related to AI are tied to cybersecurity fundamentals (or a lack thereof in the incidents we’ve seen).

So let’s check it out.

Opening Notes

The publication rightly opens discussing the dichotomy between providing enough agency and autonomy to AI systems to make them useful, but not so much that they present unacceptable levels of risk or potential security impact.

I’ve been calling this the Security vs. Utility tradeoff, something that has long existed by with AI Agents and the ability to take actions, it has become even more problematic. The fact that agents can call tools, take actions, and drive outcomes is what makes them so useful.

However, it is also what makes them so problematic from the security perspective, as threading the needle between the two is not easy, especially in large complex environments, with agents sprawling across endpoints, Cloud and SaaS.

The paper opens discussing some of the frontier model escapes and hacks, which have dominated headlines (e.g. Hugging Face, escapes across the labs by agents and now the Australian government among others). The authors rightly point out that sound security principles such as time-bound auditable authorization, network behavior monitoring and others would have mitigated and identified these activities.

This is a view I strongly agree with, while the industry and mainstream media argues about model alignment and altruism, the reality is most of these incidents were tied to poor security hygiene, posture, configurations and detection and response, a point others such as have made.

A core focus of the paper is related to enforcing Zero Trust at runtime for AI systems and ensuring authorization isn’t delegated to non-deterministic system components (e.g. the model).

Before diving into the specifics, we should also cite how they define Zero Trust:

”Zero Trust Architecture is a security paradigm named for its core principle of “never trust, always verify.” No resource, regardless of its type, is trusted implicitly. Instead, authorization is contextually granted for time bounded activities, limited in scope. With a security posture that always assumes breach, Zero Trust is designed to limit the blast radius of incidents, establishing time and task constrained trust zones so that additional resources may not be compromised.

Why do we need Zero Trust for AI?

The paper also asks an obvious question of, why do we need Zero Trust for AI? The question is isn’t more crucial in the face of doomerism and claims that we just need better aligned models, rather than a found on sound engineering and security principles.

As the authors point out, AI does introduce novel considerations, primarily systems that can reason, have autonomy and can take actions. The paper argues the best mitigation for these novel risks is relying upon existing and proven design patterns such as ZT, including reducing the blast radius when, not if, something goes wrong, because it will.

The case is made for deterministic controls, which is the exact point I’ve been arguing for in various articles I’ve written, such as “Agents Have Boundary Issues”, where I cited other research laying out boundaries agents run into and the need for deterministic controls, not soft guardrails such as model alignment and system prompts.

CoSAI’s paper rightly is upfront about the fact that ZT doesn’t not protect against all risks, such as misaligned reasoning, where an agent has access and authorization and takes actions the user/organization didn’t intend. This is why we’re seeing the rise of “Intent Analysis”, both in the academic and vendor community when it comes to securing agents.

One quote I want to share directly, because of how true it is:

”Even carefully considered controls cannot cover all behaviors in non-deterministic highly capable AI systems. As a result model alignment and safety mechanisms to direct model behavior should be layered on top of ZT controls to provide a defense-in-depth approach”.

It’s kind of sad this has to be said aloud given DiD in a longstanding concept in security, and we know there are no silver bullets. However, the current discourse across the ecosystem, including between the labs and cybersecurity is pitting Alignment vs. Cyber, as if we don’t need both AI Safety and Cybersecurity.

This is a topic and others have been trying to make, pointing out that the cybersecurity community is undercounting the real risks related to AI Safety, while the AI Safety community is overlooking the importance of fundamental cybersecurity controls.

Applying ZT to AI Security

With that out of the way, the paper gets into the meat of things, which is applying ZT principles and methodologies to secure AI systems. This starts with a mental shift and a few fundamental concepts they argue for, such as:

• Assuming a hostile environment where the AI system may intentionally or unintentionally subvert its behavior.

• Presuming breach, and that the data, models, software and even hardware may be compromised and aiming to limit blast radius, something I’ve dug into extensively with leaders such as .

• Scrutinizing all resources explicitly and applying unified analytics to monitor system performance (something that seemed to be missing in incidents such as the OpenAI/Hugging Face one for example).

• Authorization and authentication needs to be done contextually, with no implicit trust and apply least privilege/least-autonomy (the latter of which OWASP and others have been pushing for).

Now while many of these may sound “simple”, they are far from easy, especially in large complex enterprise environments where many of us work and millions of agents are now running already.

The paper argues that AI systems are data-driven, and as a result securing AI is tied to securing access to data, which many would agree with, especially DSPM vendors. To secure the data that is often being accessed by AI systems on behalf of users, CoSAI advocates for agent specific identifies that do not have broad access.

They also highlight the confused deputy problem, which is where an agent’s broad access is exploited to access data or perform actions that exceed the users access level, and the agents serve as a privilege escalation pathway for insider risks or agents compromised by malicious actors.

To mitigate these scenarios, the paper advocates for policy decision points that can evaluate the agents request to resources using 3 pieces of context:

• What chain of delegation authorized the action

• The agentic systems identity, determining the scope of authority that is delegated to the agent for this session or task

• Whether the specific requested action falls within the delegated scope

The paper advocates for a tiered maturity approach moving from binding agent sessions to authenticated user’s identities with per-request authorization through PDP’s evaluating delegating metadata alongside access request. This means moving beyond basic questions of is an agent authorized to do something, but is what it is accessing and the actions it taking appropriate, coupled with comprehensive logging and auditable chains.

To help make the concepts concrete, they provide a reference architecture for AI systems, involving AI models, information platforms and applications as well as high level data and AuthN/AuthZ flows between the components with an overlay of the ZT principles, as seen below:

While I won’t walk through every aspect of the diagram, they specifically put a red line around the “AI Threat Boundary”, due to the non-deterministic nature of the model and therefore must be treated as untrusted. Yes, organizations may use system prompts, filters and other soft guardrails, but as we’ve seen with prompt injection and various other techniques, including a lack of model alignment, AI system can and will be manipulated or behave in ways we don’t anticipate, hence the need for hard boundaries.

Authorization decisions must NEVER be delegated to the model.

Every interaction, data flow and API call in the diagram represents a separate authorization event, which each event requiring an analysis of the agent/users identity and the PDP doing an analysis.

A Zero Trust Matrix for AI Systems

The paper goes on to provide what they call a ZT matrix for AI systems, with four major building blogs:

• The model

• The platform it runs on

• Applications built around it

• Data that flows through it
  

The table they provide breaks down what policies to enforce, what warning signs to identify and what controls security needs to consider:

As you can see above, they recommend key controls across A&A, Security Posture and Operations.

CoSAI then lays out a list of ZT controls for AI systems which they cross-walk to existing frameworks such as the DoD ZT Ref. Arch, CISA ZT Maturity Model and others.

For those of us who have been on the practitioner side for sometime, we are likely familiar with many of these already but they are now applied to aspects of AI systems, such as data, models, and agents. Some of the key controls include verifying model artifacts, HITL or LLM-as-a-Judge, Input/Output Filtering/Sanitization and Threat Detection & Behavioral Analytics.

Closing Thoughts

While much of these fundamental security principles may not be new to many of us, the unique considerations of AI systems, particularly with non-deterministic LLM’s and agents coupled with autonomy, it does warrant a revisiting of how to apply ZT principles to modern AI architectures.

If you walk away with anything from this piece, I hope that it is realizing that authorization can not be left to the whims of a probabilistic LLM, and we absolutely need hard boundaries enforced outside of the model, in the surrounding architectures that these models and agents operate in.

This is a point I’ve been making in my writing and videos for the entire year and it is always good to hear it reinforced from industry leaders such as CoSAI.

Subscribe now

The frontier labs have spent the better part of 2026 proving it, with Anthropic’s Project Glasswing and the OpenAI-backed Patch the Planet effort from Trail of Bits turning models loose on the open source software the world runs on, and surfacing bugs by the tens of thousands.

That said, both efforts now have several months of public data behind them, and the data tells a story I have been writing about since I first covered the “Vulnpocalypse” back in April. Only a small fraction of what the models find is getting reported, and a smaller fraction still is getting fixed.

Finding was never the hard part, fixing is.

In this article, I will walk through the numbers from both programs, lean on my friend Patrick Garrity’s recent VulnCheck analysis of the Glasswing ledger, and make the case that what we’re watching play out in open source is a microcosm of what enterprises are about to face as FIRST projects 66,000+ CVEs this year.

So, let’s get into it.

The Glasswing Receipts

For those unfamiliar, Project Glasswing launched on April 7, 2026, bringing together Anthropic, AWS, Apple, Google, Microsoft, the Linux Foundation, and a number of other large vendors, along with 40+ additional organizations, to point Claude Mythos Preview at critical software, backed by $100M in model usage credits and direct funding to Alpha-Omega, OpenSSF, and the Apache Software Foundation.

Anthropic has said the model found thousands of high-severity vulnerabilities, including some in every major operating system and web browser, with examples like a 27-year-old flaw in OpenBSD and a 16-year-old vulnerability in FFmpeg.

Five months in, my friend Patrick Garrity of VulnCheck went and did what somebody needed to do, which is reconcile Anthropic’s public dashboard against its disclosure ledger, CVE ledger, and GHSA ledger. His piece, “The Anthropic Glasswing Receipts Are Starting to Trickle In”, is an excellent blog on the program, analyzing claims with real world data.

Below is an image from the Anthropic Glasswing initial update blog:

The headline figures are:

• Glasswing has discovered 26,153 findings

• Of those, 2,736 (10.5%) appear in the disclosure ledger at all

• 2,096 (8%) have been disclosed to maintainers

• 245 (0.9%) were withdrawn

• 191 (0.7%) sit in pre-disclosure

• 202 have been fixed

  That last number is 0.8% of everything the model found, that’s what has actually been verified and fixed thus far.

Those 202 fixes are spread across 113 unique projects, which works out to an average of 1.79 fixed findings per project. Garrity also found 18 vulnerabilities that had already been patched before Anthropic reported them, and a gap between the dashboard’s claim of 421 findings fixed upstream and the 202 the ledger actually supports.

The advisory counts don’t line up either, with 82 CVEs in the main ledger versus 70 in the CVE ledger, and 77 GHSAs versus 49. As Patrick put it:

“The receipts are starting to trickle in, they just don’t reconcile.”

Now, to be fair to Anthropic, they have been candid about why. Their own language states that:

“The number of vulnerabilities we’ve disclosed is a subset of the total number of vulnerabilities that Mythos Preview (and other Claude models) has found, since the process of independent human triage and review is the rate limiting step.”

That is the entire premise of this article in a single sentence, written by the people running the program at the frontier lab.

There is another figure from Patrick’s analysis that I think is key to call out as well.

Claude rated 91.5% of its findings as critical or high severity. The maintainers who actually looked at them rated 51.3% that way. So even among the small subset that reached a human, roughly four in ten findings the model called critical or high got downgraded by the person who understands the code.

Anyone who has ever dumped a scanner report on a development team will recognize that ratio immediately.

Patch the Planet’s Ledger

Patch the Planet is the other side of the coin and, in my view, the more interesting experiment, because it was designed around fixing from the start.

Announced on June 22, 2026 as a collaboration between Trail of Bits and OpenAI, the program pairs security engineers with open source projects for a week of dedicated review, authors the patches, and submits them upstream.

Maintainers also get six months of ChatGPT Pro and conditional access to Codex security tooling. The project list includes Python, Go, zlib, cURL, urllib3, PyPI, Sigstore, Let’s Encrypt, Ansible, aiohttp, and rsync, among others.

Trail of Bits publishes a live dashboard, and to their credit, the funnel is right there for anyone to look at. As of September 4, across 59 codebases, the program has found 1,646 issues, with 1,031 (63%) awaiting a patch, 615 (37%) with a patch authored, 400 (24%) with a patch open upstream, and 215 (13%) merged, along with 11 CVEs assigned.

This is an effort where a security engineering firm is writing the patches for the maintainers, with frontier model access, backing from OpenAI, and a week of hands-on engagement per project, and 13% of findings have made it to merged.

The discovery side has clearly worked, with 224 issues reported on a single day in early June and Trail of Bits describing GPT-5.5-Cyber building a bespoke zlib fuzzing campaign in a single day, work that once took skilled researchers weeks. The merge side is running at a fraction of that pace, because merging requires a maintainer to review, accept, test, and ship, and no amount of model capability on the reporting side changes the fact that a maintainer is a human and has 24 hours in a day.

The severity mix of what did get merged is also instructive, with only 17 (7.9%) of the 215 accepted fixes rated high and 129 of them rated low, informational, or undetermined, all consuming the same scarce review capacity a high-severity fix needs.

None of this is a knock on either program. I want to be clear about that, because it is easy to read the percentages and conclude the efforts are failing, when they aren’t.

202 fixed vulnerabilities in widely used software, some of which sat undetected for decades, and 215 merged patches into projects like zlib and cURL, are real security outcomes the community would not otherwise have.

Daniel Stenberg credited AI tooling with helping fix over 100 bugs in cURL, which I covered in the original Vulnpocalypse piece, and that was before either of these programs was fully underway.

These are incredible efforts by our nations two leading Frontier AI labs, along with support from amazing teams such as Trail of Bits. We should all hope these efforts from the labs continue, as this is critical software that runs everything from consumer goods to critical infrastructure.

My point is what the funnel reveals about where the constraint actually lives.

A Microcosm of the Enterprise

I have been making some version of this argument since April, including in “The Bottleneck Was Never Finding the Bugs” and in conversations with Casey Ellis, Jerry Gamblin, and Patrick Garrity, and Glasswing and Patch the Planet are now the best public examples of it.

Open source is where the AI discovery wave hit first because the code is public and the labs could operate at scale, and it helps demonstrate the capabilities to ensure trust by enterprises for their own usage.

Now, as that happens, every dynamic in those two funnels is and will show up inside enterprise environments too.

Let’s first consider the volume.

Jerry Gamblin and Eireann Leverett’s FIRST mid-year forecast update now projects roughly 66,000 to 68,000 CVEs for 2026, running 46.3% above their original forecast, with GitHub Security Advisories up 449% year-over-year and a 164% spike in Q1 disclosures at Mozilla that the authors attribute to Glasswing and Mythos Preview.

As I argued in “Why 70,000 CVE’s is Less Scary Than It Sounds”, the same forecast notes that actionable exploitability metrics have stayed flat, so the volume is largely 25 years of debt getting found rather than a new class of danger.

That said, flat exploitability does not mean flat work. Every one of those CVEs still lands in somebody’s scanner, gets scored, gets ticketed, and gets argued about among enterprise teams when it comes to backlogs, sprint logistics and competing priorities such as feature releases, velocity, and customer-oriented product value.

Now we can consider the triage gap. Glasswing’s severity mismatch is the exact same fight that plays out between security and engineering in every enterprise I have worked in. The scanner says critical, the developer who owns the code says it is unreachable or already mitigated, and the ticket sits in the backlog while both sides dig in.

AI does not resolve that dispute, it just multiplies the number of times it has to happen.

Then there is the ownership problem as well. In open source, the constraint is a maintainer who is often unpaid and reviewing patches on nights and weekends. In the enterprise, the constraint is a product team with a roadmap, a change advisory board, a quarterly release cadence, a legacy system nobody wants to touch, and a vendor whose patch is six months out.

Patch the Planet can hand a maintainer a finished, tested patch and still watch 63% of findings sit in “awaiting patch.” Enterprises rarely even get the finished patch, they often just get a CVE ID and a due date.

Casey Ellis made a point I covered in “Slopdemic, Not Vulnpocalypse (Yet)” that I like to refer back to:

The vulnpocalypse was already here, it just wasn’t evenly distributed.

The teams drowning in backlogs before AI showed up are the same teams now, and I wrote in June that AI is pushing the security poverty line up before it pushes it down. The Glasswing and Patch the Planet numbers are what that looks like in practice.

So what do security leaders actually do with this?

I don’t think the answer is to slow discovery down, because the attackers certainly won’t, and I don’t think it is to buy another scanner. The answer is to invest in the unglamorous parts of the pipeline that the frontier labs are now discovering the hard way.

That means triage capacity that can tell a real critical from a model’s guess at one, remediation ownership that is actually assigned and resourced rather than assumed, and procurement leverage to push vendors on patch timelines, since a growing share of enterprise exposure is in software the organization did not write (e.g. third party code).

It also means being honest about how you decide what gets a human’s attention this week, because the default answer, “start with the KEV list”, is a weaker filter than most teams assume.

As I shared recently, Empirical Security’s recent whitepaper “How to Deal with Speed” put numbers on this.

Across six years of exploitation telemetry, Empirical observed 16,116 CVEs with exploitation activity. CISA’s KEV catalog held 1,307 entries, of which 894 were corroborated by Empirical’s data, which leaves 15,222 actively exploited CVEs that never made it onto KEV. More than half of the KEV entries were last seen with exploitation activity over three years ago, and as the paper points out, a scanner fires the same alarm for those as for a flaw under attack this morning.

KEV is a good compliance baseline and a fine place to start, but as Empirical argued earlier this year in “The KEV Paradox”, treating it as the only prioritization input guarantees you miss the majority of exploited CVEs.

The more valuable move, and the one Empirical makes the case for, is prioritizing on exploitation evidence and probability rather than severity scores, and then tailoring that to your own environment, with the last piece being the most critical and also the least commonly done as a standard practice.

Their data across 500+ organizations found a 29-fold efficiency improvement from prioritizing by exploitation evidence over CVSS for the same remediation effort, which matters a great deal when your remediation effort is the fixed quantity.

The paper also draws the distinction that I think most vulnerability programs still miss, that internet-wide probability and the realized risk to a specific environment are different numbers, and the gap depends on exposure, controls, and what an organization actually runs.

A global model like EPSS tells you what attackers are doing on the internet. It does not know what is reachable in your estate, which assets carry the business, what compensating controls sit in front of them, or where a patch is itself the risky change.

Getting to a local model of exploitability, reachability, and business exposure is how you make a fixed remediation budget go further, and it is the same discipline the Glasswing maintainers were applying by hand when they downgraded four in ten of Claude’s criticals. As the whitepaper puts it, the answer is to sort better before you run.

Much of this is old advice, and AI discovery just removed the excuse that we did not know where the bugs were.

Closing Thoughts

Project Glasswing and Patch the Planet are doing important work, and the community is better off for the vulnerabilities they have surfaced and the ones they have actually closed.

That said, their own ledgers show that a frontier model with $100M in usage credits behind it can find 26,000 bugs and get 202 of them fixed in five months, and that a program built specifically around writing the patches for people still has 63% of its findings waiting on a human.

The labs have solved the part of vulnerability management the industry spent two decades pretending was the hard part.

The rest of it, the triage, the ownership, the change windows, the arguments over severity, is now the whole job, and it is coming to an enterprise near you if it hasn’t already.

Are we going to build the remediation capacity to match, or keep celebrating the size of the backlog?

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

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

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

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

“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! <-

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

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

In all that time, the fundamental challenge has stayed remarkably consistent. Too many findings, too little context, and not nearly enough capacity to remediate.

The past 18 months have changed the math.

AI has industrialized vulnerability discovery, and increasingly exploitation, something I dug into in "Vulnpocalypse: AI, Open Source, and the Race to Remediate." Below, I walk through where the numbers stand, why legacy triage cannot survive contact with this reality, and how Resilient Cyber's partner, Maze, is applying AI agents to the problem.

The Numbers Behind the Vulnpocalypse

Start with data rather than vendor hysteria. FIRST's Mid-Year Vulnerability Forecast, published in June 2026, now projects roughly 66,000 CVEs for the year, up from the February median of 59,427, and actual volume has run 46.3% above that February forecast through April.

The drivers matter as much as the total, a 449% year-over-year jump in GitHub Security Advisory volume and a 164% spike in Q1 Mozilla CNA disclosures directly attributable to AI-assisted tooling.

As FIRST’s Éireann Leverett put it,

“We’re witnessing a major shift in the vulnerability landscape, not because software is suddenly less secure, but because our collective ability to find flaws has been structurally transformed.”

I discussed this dynamic at length with Jerry Gamblin in a recent conversation I wrote up in “Why 70,000 CVE’s is Less Scary Than It Sounds“.

GitHub alone now publishes one in five CVEs, and much of the surge is 25 years of accumulated human debt finally getting found, not a sudden collapse in software quality. Filter the flood through exploitation-focused lenses like CISA's KEV catalog and EPSS and the genuinely exploitable slice has stayed essentially flat. Jerry captured the situation in the FIRST forecast better than I could, writing that

“In 2026, the rain doesn’t stop. The job is no longer counting the drops. It’s knowing which ones will overrun the levee.”

Discovery, Industrialized

The count is only half the story. The same AI capabilities inflating disclosure volume are compressing the time between disclosure and exploitation. AISLE identified all 12 OpenSSL CVEs disclosed in January 2026, and Anthropic reported Claude discovered over 500 high-severity zero-days, including 22 in Firefox.

As Anthropic's Nicholas Carlini put it,

"Current models are already better vulnerability researchers than I am, and in a year, they will likely be better than everyone."

The exploitation side is just as sobering. Sergej Epp's Zero Day Clock found the median time from disclosure to first observed exploit was 771 days in 2018, fell to 6 days by 2023, and is now measured in hours, with 67% of exploited CVEs in 2026 being zero-days, up from 16% in 2018.

As Thomas Ptacek argued, high-impact vulnerability research will soon happen simply by pointing an agent at a source tree and typing "find me zero days."

There’s absolutely no question now for those of us on the defensive side whether AI can find the bugs, we know it can. However, what we’re still figuring out is if we can find, prioritize, and fix what matters in our own environments before attackers exploit it, and right now the evidence suggests we’re losing that race.

Backlogs, Toil, and Throwing It Over the Fence

None of this is landing on organizations with clean programs and manageable backlogs.

Long before AI, organizations admitted to remediating less than 50% of their vulnerabilities, while attackers weaponized flaws in 19.5 days on average against a defender mean-time-to-remediate of 30.6 days, per Qualys.

Yet of the 25,000+ CVEs published in 2022, less than 1% were actually exploited. That asymmetry, an ocean of findings and a puddle of exploitation, has always been the central prioritization problem in our field, now playing out at even greater scale.

The way the industry has historically handled this gap is something I wrote about in “Security Throwing Toil Over the Fence“.

Teams run their scanners, export thousands of context-free findings, and toss them over the fence to developers prioritized by little more than CVSS severity, something the stewards of CVSS themselves recommend against.

Developers wrestle with spreadsheets full of trivial, unreachable, or non-exploitable vulnerabilities, resentment builds between Development and Security, and the actual exploitable risk sits untouched in the noise. When everything is a priority, nothing is.

To be fair, the industry has made real progress. KEV, EPSS, reachability analysis, and threat intelligence are meaningful improvements over raw CVSS burn-down lists, and I have advocated for all of them. That said, they share a common limitation, they are global signals.

KEV tells you a vulnerability has been exploited somewhere and EPSS tells you the probability it will be exploited in the wild generally, but neither tells you whether it is exploitable in your environment, on your asset, with your configuration, compensating controls, and exposure. Exploitability is ultimately environmental, and that context has historically been too labor-intensive to gather at scale, since it required an experienced engineer to investigate each finding by hand.

That capacity constraint is the crux.

Human-speed triage was already failing at 25,000 CVEs a year. It has no chance at 66,000+ in environments where scanners generate findings in the millions and developers ship more code faster than ever.

AI as a Force Multiplier for Defenders

This is why I have argued, including at the SANS AI Cybersecurity Summit earlier this year, that security needs to stop hand-wringing about AI and start wielding it as a force multiplier. Attackers are not waiting on our AI governance committees. If AI has industrialized discovery and exploitation, defenders have to industrialize investigation, triage, and remediation by applying the same agentic capabilities to our side.

For leaders asking whether to build this in-house, the answer is more nuanced than a weekend prototype suggests. As Maze’s Co-Founder and CTO Santiago Castiñeira laid out in a candid talk on build versus buy, a prototype script is easy, but scaling it into a maintainable, audit-proof system with rigorous evals rather than “vibe checks” is a massive undertaking, with hidden costs around LLM inference at scale most security teams have never had to reason about.

Whether organizations build, buy, or blend, the destination is the same. We need triage that runs at the speed and scale of the discovery pipeline now flooding us, while applying the environmental context that global scoring systems structurally cannot.

A Look at Maze’s Agentic Triage

This brings me to Resilient Cyber’s partner Maze, who I recently spent time with for a full platform demo, and who I think represents one of the better examples I have seen of the force multiplier vision actually implemented on the triage front.

The core of the Maze platform is what they call Agentic Triage.

Rather than performing yet another scan, Maze can both conduct scans and ingests findings from the native scanners organizations already run, tools such as AWS Inspector or Wiz, and then turns AI agents loose to investigate each finding the way an experienced security engineer would, checking versions, tracing attack paths, examining the surrounding environment, and rendering a judgment on actual exploitability with the evidence to back it up. Additionally, Maze allows for the unified context from both cloud and code findings and telemetry, which often is siloed between separate tooling.

Their agents make the call based on that evidence rather than static rules, and the platform has been trained on millions of real investigations with multiple layers of validation, because as their team puts it, the agents are trained to never guess at the answer.

The impact of doing this well is significant. Maze estimates that 65% to 85% of cloud findings are not exploitable due to the specific environmental configurations they sit in, which tracks with what most practitioners feel but can never prove at scale, and which echoes the sub-1% exploitation figures I cited above.

What stood out to me in the demo was the depth of the environmental reasoning. In one example, a critical severity finding from a popular scanner was investigated by Maze’s agents, who determined the vulnerability was not exploitable because the affected component, a New Relic observability agent, did not process XML in that environment and the schema files required to trigger the flaw were absent entirely.

In another, a denial-of-service vulnerability was lowered from high to low because the pod had no network exposure, exploitation would require a custom exploit, and the pod was configured to automatically respawn, mitigating the impact even if it were somehow triggered.

Critically, this context cuts both ways, and this is where I think the approach differentiates itself from purely deprioritization-focused tooling.

In a third example, a finding rated medium by the scanner was elevated to critical because the agents determined the asset’s SQS APIs were exposed in a way that allowed an attacker to supply malicious XML, trigger the flaw, access secrets, and ultimately gain control of the file system.

A rules-based system keyed off CVSS, KEV, or EPSS would have left that finding buried in the middle of the backlog. This is the point I think many overlook when discussing vulnerability management at a high level, exploitability is environmental, unique to each organization and each system, and a triage approach that actually interrogates the environment will make calls in both directions that global signals structurally cannot.

Maze also enables organizations to rescore findings not just based on broader vulnerability intelligence sources such as the ones I mentioned above, but also environment context, using impact and likelihood. This takes findings from being generic and with broad generic, to making them scored specifically based on an organizations unique risks and environment.

Cloud to Code Coverage

Another aspect I want to highlight is the coverage across the stack, because most organizations experience vulnerability management as a set of disconnected silos, with cloud findings living in a CNAPP, dependency findings in an SCA tool, code findings in SAST, and no shared context between them. Security then throws each silo’s outputs over the fence separately, and Developers get to deduplicate the mess themselves.

Maze approaches this as one investigation across code and cloud.

In the demo, the platform mapped GitHub repositories to the AWS ECR images built from them and on to the running containers, providing a genuine code-to-cloud view that also enables deduplication of overlapping findings from sources like Dependabot and Wiz.

Their recently launched Maze Code extends the same agentic model into AppSec territory, spanning both dependencies (AI-SCA) and custom code (AI-SAST). On the dependency side, their agents trace the full call chain however many hops deep the vulnerability sits, including through the dynamic calls that traditional reachability parsers give up on, and then check the runtime and cloud environment to determine whether that path is actually exploitable rather than merely reachable.

That distinction matters, and it is the same gap I called out earlier with reachability-only approaches, an attacker being able to reach vulnerable code is not the same as an attacker being able to control the payload and realistically trigger the flaw in that specific environment.

The cross-enrichment flows in both directions, code context enriches cloud findings and cloud context enriches code findings, which is what makes the exploitability determinations credible in the first place.

The launch announcement from Co-Founder and CEO Harry Wetherald opens with a framing I appreciated, noting that AI is supposed to be reinventing application security and that so far we have seen more hype than impact, a sentiment I share about much of the AI security market. Industry analyst of Latio, whose tooling analysis I respect, stated “Maze uses AI agents with full context, which is why it delivers some of the most meaningful findings and fixes I’ve seen”, and his full analyst review of the platform is worth a watch.

The demo also showed their deeper business logic analysis, where agents identified a flaw in an open source e-commerce repository allowing an attacker to abuse the guest checkout flow to gain full account control, exactly the class of contextual vulnerability that pattern-matching SAST tools have historically missed and that has traditionally required a pentest to surface.

Integrations, Workflows, and Compensating Controls

For the practitioners wondering about the operational lift, the deployment model is refreshingly light.

Maze connects to AWS and Azure environments through a read-only IAM role, pulling runtime context via API with no agents to deploy, and GCP support is expected in the next few months. On the workflow side, the platform is designed to disappear into the processes organizations already run, pushing verdicts back into the originating scanners, closing findings automatically, or generating tickets in systems like Jira based on SLAs and automation rules the organization defines.

Remediation guidance both asset-centric and finding-centric, using GitHub and AWS activity trends to identify actual owners and bundling fixes so an engineer can resolve multiple vulnerabilities with a single change, and it can even be output as ready-to-run prompts for coding agents such as Cursor or Claude, meeting Developers where they increasingly work, and leveraging AI for AppSec, which I thought was neat.

Two other capabilities from the demo are worth calling out.

The first is compliance, where the same context-aware evidence trail that justifies triage decisions is being used by customers to support assessments against frameworks including generating deviation reports from a non-production replica of their environment, an approach that saves significant time compared to the manual evidence-gathering most GRC teams still suffer through. This is something I have written about in-depth in a piece titled “GRC is Ripe for a Revolution”.

The second is the movement toward compensating controls, where Maze is integrating with infrastructure like Cloudflare and using Web Application Firewall (WAF) data to further refine exploitability analysis. I find this direction particularly promising, because mature vulnerability management has never been only about patching.

As I emphasized in Effective Vulnerability Management, remediation is one path among several, and a triage system that understands when a WAF rule, network policy, or configuration change already mitigates a finding, or could, is reasoning about risk the way real security teams do, rather than treating the patch backlog as the only lever.

-> Learn More About Maze! <-

Closing Thoughts

This is far from an exhaustive discussion of either the Vulnpocalypse or the platform, and for those who want to go deeper I would recommend Maze’s Introducing Maze Code walkthrough and their Cloud Security Podcast conversation on bridging cloud and code security.

The bigger picture, though, is that the industry is on pace for roughly 66,000 CVEs this year, discovery has been structurally transformed by AI, exploitation windows are measured in hours, and organizations were already unable to remediate half of what they found when the numbers were a fraction of this size.

Human-speed triage is not going to close that gap, and neither is throwing ever-larger piles of context-free findings over the fence to Developers who are already drowning. We have a finite window to apply AI as a force multiplier on the defensive side of this race, and agentic triage grounded in real environmental context, of the kind Maze is building across cloud and code, is a strong exampl of what that looks like in practice.

The rain isn’t going to stop, as as FIRST has argued, the key is knowing which drops are worth addressing so the levee doesn’t overrun.

Subscribe now

I’ve been writing about this shift for a while now, from breaking down the OWASP Top 10 for Agentic Applications to examining Agentic AI Threats and Mitigations, and one theme keeps surfacing across all of it, which is that agent security failures that look wildly different on the surface tend to share the same underlying causes.

That said, the research literature on agent security has been fragmented, organized around attack types, application domains, and benchmarks, which makes it hard to explain why prompt injection, tool misuse, and memory poisoning so often rhyme with one another. A new research publication titled “Isolation as a First-Class Principle for LLM-Agent System Safety” takes a crack at fixing that, organizing the entire space around five isolation boundaries and asking one question of every attack and defense, where does the loss of isolation first occur?

I really like their 5 boundary framing and found it useful for thinking about potential agent risks and failures.

In this article, I will walk through the five boundaries the researchers lay out, the risks and defenses at each one, and then map the taxonomy onto the agent deployment patterns and common security controls (sandboxes, hooks, posture management, runtime monitoring, and hard boundaries among others) that practitioners are actually wrestling with.

Isolation as a First-Class Principle

The paper’s core argument helps simplify what can feel like a complex domain of AI and Agents.

The authors treat isolation, meaning the separation of user inputs, tool access, execution channels, inter-agent communication, and environment-originated context, as the organizing principle for agent safety. In their words,

“agent safety improves when system boundaries are explicit and enforced structurally, rather than left to prompt instructions alone.”

That single sentence is key, because it captures the difference between what many of us have taken to calling soft guardrails and hard boundaries. Soft guardrails are instructions, system prompts, and model training, all of which are probabilistic and all of which can be talked out of their behavior by a sufficiently motivated adversary.

I actually went into detail in a recent video where I discuss AI jailbreaks, system prompts and more as they relate to soft guardrails as security controls:

Hard boundaries are structural, things like permission systems, sandboxes, network egress controls, and deterministic policy checks that sit outside the model and don’t care how persuasive the injected text is. This mirrors the conversation I had with Luke Hinds on the podcast in Your AI Agent Is Running As Root, where he made the point that application-layer controls can be circumvented while kernel-level enforcement cannot be jailbroken.

The taxonomy places the agent core (policy, planning, and memory) at the center, surrounded by five interfaces where things can go wrong. Each boundary is summarized as:

• The user-agent boundary concerns whether user content remains data or becomes control.

• The agent-tool boundary concerns how external capabilities are accessed.

• The agent-execution boundary concerns the transition from reasoning to action.

• The agent-agent boundary concerns communication and coordination across multiple agents.

• The system-environment boundary concerns how the agent system interacts with external content and state as a whole.

  The authors classify prior work by its “primary safety boundary,” the point where the loss of isolation first occurs, which keeps things clean even though most real attacks end up crossing several boundaries before they’re done.

Let’s walkthrough each of the primary boundary types and how the paper discusses them.

Boundary 1 - User-Agent

The first boundary asks whether an agent can keep user content from becoming privileged control.

In a well-isolated system, user input should remain a request, a query, or task data, while system and developer instructions keep higher authority. Failure begins when user-controlled content starts to steer internal policy, which is the classic direct or indirect prompt injection and jailbreak story, where as the authors put it, “a low-privilege source can behave like a high-privilege one.”

What I appreciated is that the survey pushes well past single-turn jailbreaks. Multi-turn attacks exploit gradual steering across a conversation, implicit clues, and long-context overload, leading to the observation that “many systems look safer in one-shot evaluation than they are in realistic sessions.”

The attack surface also expands in multimodal settings, where user-provided images can carry visual or typographic instructions that bypass text-oriented safeguards. And perhaps most relevant for anyone running agents with persistent memory, the strongest recent trend is persistence, with in-context poisoning and memory injection showing that user influence can remain after the original interaction ends. This maps directly to Memory & Context Poisoning from the OWASP Agentic Top 10, which I covered in depth in my breakdown after serving on the Agentic Security Initiative’s review board for the project.

Defenses at this boundary fall into three groups, making authority separation explicit through structured queries, signed prompts, and DSL-style interfaces, hardening the model itself against jailbreaks through safety classifiers and semantic smoothing, and repairing after degradation through unlearning, editing, and refusal-boundary control.

The takeaway from the authors is that user-agent safety “must move beyond short prompts and static refusal scores toward long-session robustness, multimodal authority separation, and recovery from persistent compromise.”

Boundary 2 - Agent-Tool

The agent-tool boundary is where I suspect most enterprise pain will actually materialize, given the explosion of MCP servers and tool ecosystems we’ve watched over the past two years. Clutch Security actually had one of the better reports on this, titled “MCP Servers: What We Found When We Actually Looked”.

They found a 2,000 growth of MCP servers in a single year (not counting 2026), which were widely connected to enterprise services and overwhelmingly running on developers endpoints rather than enterprise servers, making them a major supply chain risk.

The framing here is that “tools should extend what the agent can do without taking over how it decides.” The basic failure mode is that tool-returned content gets treated as trusted instruction, which is the indirect prompt injection story every security team has now heard, but the paper enumerates a fuller failure set, noting the system can fail:

“by choosing the wrong tool, passing unsafe arguments, trusting malicious output, or composing plausible calls into an unsafe workflow.”

The MCP-specific findings deserve attention from anyone deploying agents against tool catalogs. In MCP-style ecosystems, the model sees tool descriptions, capability advertisements, and metadata before it ever invokes a tool, and the authors point out that “metadata is not neutral from the model’s perspective. It can shape preferences, change routing, and bias decisions before real tool output even appears.”

Benchmark work such as MCP Security Bench shows that attacks against the protocol layer are not an edge case but a natural extension of tool-mediated prompt injection. The below image from the paper shows various examples of tool attacks vectors.

As tool use standardizes through protocols and orchestrators, the boundary no longer sits only at the moment of API invocation, but also at discovery, ranking, metadata interpretation, and workflow construction. I flagged tool poisoning against MCP as an emerging concern back in my Agentic AI Threats and Mitigations piece, and the research has since caught up in a big way.

There’s also a trajectory-level insight here that practitioners should be thinking about, which is that a single tool call may look harmless while the full trajectory becomes unsafe. This is why organizations need security tools that watch the entire trajectory, not providing security rigor for individual tool calls in isolation.

The security target is not one prompt or one API call but the full trace of calls, arguments, observations, and intermediate state. The broader lesson, in the authors’ words, is that “safer tool use depends less on the model inferring the right behavior from natural language, and more on interfaces that make capability scope, trust level, and action semantics explicit.”

That is about as clean an articulation of least privilege for agents as you’ll find.

Boundary 3 - Agent-Execution

The agent-execution boundary concerns the point at which internal decisions become real actions, and failure begins when the system treats model output as ready-to-execute behavior without enough mediation.

As the paper puts it, this boundary “turns control errors into operational impact.” A model producing unsafe text is one kind of problem, while an agent that clicks the wrong button, runs unsafe code, or submits the wrong form is another entirely.

I’ve been making this argument repeatedly, in my blogs, videos and my lectures at CMU’s AI programs, pointing out that the potential blast radius and risk to organizations is far great from agents with autonomy and the ability to take actions on production systems than it was for chatbots related to hallucinations or unintended responses.

The browser and GUI agent findings are sobering. Benchmarks like SafeArena and ST-WebAgentBench show that web agents can produce unsafe outcomes through clicks, submissions, and navigation, and the research shows that refusal-trained models remain vulnerable once they act through an interface rather than a chat window. In other words, the safety training that holds up fine in a chat box degrades when the same model is grounded in an interface and taking actions.

This is also a major factor that has led to organizations such as Gartner outright recommended organizations do NOT adopt agentic browsers, and the technology itself having a slower adoption curve than in say, coding agents.

This is where the control conversation gets practical, because defenses at this boundary increasingly focus on containment rather than only prevention, including constrained execution, zero-trust architectures, policy-executable safeguards, and sandbox ecosystems.

This is exactly the design philosophy behind the sandboxing and permission models in modern coding agents, and behind hooks, the deterministic pre- and post-action checkpoints that products such as Claude Code expose so teams can enforce policy in code rather than in prompts (Anthropic’s agentic coding best practices are a useful reference here).

The paper also nods to the broader industry direction of decoupling the brain from the hands, separating the model that decides from the runtime that acts, so unsafe decisions can still be checked, delayed, or blocked before they create side effects. The authors’ bottom line is that safe agent design must treat execution “as a governed interface, not as the automatic continuation of model output.”

This is also the exact premise behind AARM (Autonomous Action Runtime Management), the CSA-powered specification for agent runtime security where I serve as a Co-Lead, and which I recently covered in AARM and the Case for Standardizing the Agent Runtime Security Category.

The paper's conclusion that execution must be a governed interface is essentially AARM's founding argument, that the stable security boundary for agentic AI isn't the model, the prompt, or the orchestration layer, but the action execution boundary, and that deterministic controls need to be enforced there, outside the agent's reasoning loop.

The reason for this of course is that soft guardrails such as system prompts are imperfect (as any security control is), and models are non-deterministic by nature, so we need deterministic controls outside the model to enforce rigorous security.

Boundary 4 - Agent-Agent

The agent-agent boundary concerns what happens when multiple agents communicate, delegate, debate, and share intermediate state.

In a well-isolated system, one agent’s message should remain a bounded contribution rather than an unverified control signal for others. The memorable line from the paper is that:

“a message is not just information. It can also be a carrier of control.”

The research here validates concerns I’ve raised repeatedly about multi-agent architectures as well as the reality that were in the infancy of inter-agent protocols, such as A2A.

The Prompt Infection research cited in the survey found that one compromised agent can pass malicious instructions to others, turning ordinary coordination into an attack channel, and the progression the authors describe is worth quoting because it reads like an incident report waiting to happen, “first one compromised message, then repeated propagation, then communication-level cascade.”

Topology matters too, since network structure, routing rules, and memory sharing determine how fast compromise travels and how hard it is to contain. Work like Trojan Hippo shows that shared memory is itself a high-risk surface, because poisoned memory can be weaponized for later exfiltration or control.

The threat moves from bad messages, to bad agents, to bad shared state, at which point rollback becomes much harder than in a single-agent system. Readers who have gone through my OWASP Agentic Top 10 breakdown will recognize Insecure Inter-Agent Communication and Cascading Failures living at exactly this boundary.

On the defense side, efforts such a Project Agent Memory Guard are starting to materialize. It’s aim is to stop AI agents from being weaponized through their own memory by sitting between the agent and the memory store, screening every operation through a pipeline of detectors and declarative policies.

The section closes with a line I’d encourage every architect building multi-agent systems to keep in mind:

“collaboration is not automatically a safeguard. Without isolation, it can become a mechanism for amplification.”

Boundary 5 - System-Environment

The final boundary concerns how an agent reads and reacts to the outside world.

In a well-isolated system, webpages, retrieved passages, documents, emails, interface elements, and memory artifacts should remain observations rather than hidden commands. Failure begins when environment-originated content is absorbed into agent context and then treated as if it had authority, which is the indirect prompt injection problem that has haunted LLM-integrated applications since the earliest research on the topic.

I continue to cite Google DeepMind’s paper on this titled “AI Agent Traps”, which discusses how the information environment itself from the web now:

becomes a vulnerability where adversarial content can manipulate, deceive or exploit visiting agents.

The survey shows this problem is broader and more persistent than first expected. For web and computer-use agents, the environment is not just read but clicked, navigated, and executed against, leading to the conclusion that “web environments are active adversarial surfaces, not passive information sources.”

Visual prompt injection work extends this to interface appearance itself, showing computer-use agents can be misled through how a page looks rather than what its text says. RAG systems expose another variant, where the issue is often corrupted evidence rather than explicit instruction, with work like PoisonedRAG and BADRAG showing attackers can manipulate knowledge bases so the agent reasons from compromised support, and the disclosure findings cut both ways, since “the environment can both push corrupted knowledge in and pull private knowledge out” through data extraction and membership inference attacks.

It’s easy to see how the adversarial content can quickly become a major problem for agents and this realization sits at the heart of what I call the Security vs. Utility tradeoff for AI Agents. The utility an agent has in terms of autonomy, tools and the ability to take actions, the more problematic it becomes security wise as well.

Defenses here are evolving from detection toward provenance, with approaches like Spotlighting and Task Shield aiming to mark, isolate, or filter environment-originated instructions before they silently become control input, and newer work adding causal attribution and trustworthy evidence selection.

The lesson from the authors is that system-environment safety “will likely depend less on stronger generic refusal and more on better source authentication, provenance tracking, memory hygiene, and context attribution.”

When Boundaries Fail Together

The taxonomy’s real payoff is in cross-boundary analysis.

Serious failures often cross boundaries, and the common pattern the authors describe is sequential escalation, where user input first overrides control at the user-agent boundary, then steers tool use, and finally triggers unsafe execution.

Another pattern starts from the environment, where a malicious webpage or poisoned memory item enters through the system-environment boundary and later propagates into tool calls, agent communication, or action traces. The unit of analysis is the full control path, not a single prompt or tool call, which is why “local robustness at one interface does not guarantee system-level safety.”

The forward-looking agenda the paper lands on is what the authors call isolation-by-construction, building interfaces where the boundary remains visible to the system itself.

Inputs from users, tools, peer agents, and external content should remain distinguishable, capability access should be scoped, propagation paths should be observable through trace-level monitoring, and recovery should be a core requirement once compromise reaches memory or shared state.

They’re also candid about open problems, noting that many benchmarks still test single boundaries while real failures are cross-boundary, and that the field still lacks stable abstractions for authority, trust, and privilege in full workflows.

From Taxonomy to Deployment Patterns

Academic taxonomies are only useful if they map to how agents actually show up in the enterprise, so let’s do that mapping.

As I discussed in my recent video breaking down OWASP’s State of Agentic AI Security and Governance report, agents are landing in organizations through a few distinct patterns, endpoint agents such as coding CLIs and agentic browsers running on user machines, custom or homegrown agents built on cloud platforms and orchestration frameworks, and SaaS-embedded agents that arrive inside the productivity and business platforms you already own.

Each pattern weights the five boundaries differently.

Endpoint agents live and die at the agent-execution boundary, since they run with the user’s permissions, credentials, and file access, which is exactly the “running as root” problem Luke Hinds and I dug into, and why sandboxes, hooks, and OS-level enforcement matter most there.

Custom-built agents concentrate risk at the agent-tool and agent-agent boundaries, because you are the one wiring up MCP servers, tool catalogs, memory stores, and multi-agent topologies, and every one of those design decisions either preserves or erodes isolation.

SaaS-embedded agents shift the weight toward the system-environment and user-agent boundaries, since you control neither the model nor the runtime, and your exposure comes through the content, connectors, and data the agent can reach inside the platform.

This is also where the emerging crop of agent security tooling slots in, and I find it more useful to think about it in terms of two complementary functions rather than vendor categories or acronyms.

The first function is preventative and posture-focused, inventorying agents across all three deployment patterns, understanding their tools, identities, entitlements, and data access, and driving least privilege before anything goes wrong, which in taxonomy terms means knowing where your boundaries are and how much isolation each one actually enforces. Think of it akin to “Shift Left” for Agentic AI, aimed at posture, configurations, policies and more, before agents are running in production, or identifying deviations from desired posture for agents already deployed.

The second function is runtime monitoring and response, watching agent behavior for goal hijacks, anomalous tool use, and cross-boundary propagation, which maps directly to the paper’s calls for trace-level monitoring, attribution, and recovery.

Neither function replaces the hard boundaries themselves, but posture tells you where isolation is weak and runtime monitoring tells you when it has failed, and the paper's cross-boundary escalation patterns are a solid blueprint for what your runtime detections should actually be looking for.

For those wanting a fuller landscape view, I’ve started doing a video series breaking down the OWASP Agentic AI Top 10 one-by-one such as my first video below where I cover Agent Goal Hijack.

You can check out the videos for my breakdown of the OWASP Agentic AI Top 10 pairs naturally with this paper, since nearly every risk in that list is a boundary failure wearing a different name.

Closing Thoughts

It of course is debatable whether the industry needed another taxonomy, and the authors themselves acknowledge theirs is not the only valid way to organize the literature.

That said, I find the boundary-centric framing helpful, because it explains why so many differently-named attacks share the same structure and it gives practitioners a common language that spans research papers, OWASP guidance, and vendor categories alike. This builds on the excellent work of OWASP and others, such as my friend , who’s blog you should follow if you haven’t already, as well as leaders like who created MAESTRO, for threat modeling agentic systems.

The message security teams should take away is one I’ve been hammering for a while now, which is that we cannot prompt or guardrail our way to secure agents. Isolation has to be designed in, enforced structurally, and monitored continuously, and organizations adopting agents across endpoints, custom builds, and SaaS platforms would do well to ask one question of every deployment:

Subscribe now

I have written books on the subject, worked in AppSec programs, ran vulnerability management operations, and spent years in the federal government helping large enterprises operationalize zero trust.

I am a true believer in patching, in secure development, in shifting left, and I am telling you that none of it, individually or combined, is going to be enough to keep pace with where the threat and current landscape with AI’s convergence with cyber is heading.

The economics of offense changed underneath us, and most security programs are still budgeted as if they did not.

You Cannot Patch Your Way Out of This

The vulnerability discovery rate is now compounding on multiple independent curves.

The CVE ecosystem published over 40,000 vulnerabilities in 2025, and projections for 2026 range from 60,000 to as high as 100,000 depending on how aggressively you account for AI-assisted discovery, based on FIRST’s 2026 mid-year projection.

As I covered in AI Is Winning the Cyber Arms Race, offense became a compute problem, and compute keeps getting cheaper and faster. Finding and exploiting a vulnerability is a search task. The cost per token has been deflating faster than Moore’s Law, and that is a structural shift rather than a handful of headline demos.

At the same time, the global codebase keeps expanding. AI-assisted development is accelerating the rate of new code, and every new function creates interaction surfaces with existing code. The growth isn’t trivial either, as I have discussed in the The Attack Surface Exponential, GitHub alone is poised to go from 1 billion commits in 2025 to 14 billion in 2026.

Dependency chains amplify the problem further. The average enterprise application pulls in hundreds of open-source dependencies, each with its own transitive tree often five to seven levels deep, and a single flaw anywhere in that tree is a flaw in every application that imports it.

On the defense side, remediation has a hard ceiling.

The Qualys Threat Research Unit analyzed CISA’s Known Exploited Vulnerabilities program across 1.1 billion remediation records from more than 10,000 organizations over four years. What they found should concern every practitioner. Organizations that increased their remediation effort by a factor of 6.5 in a single year, closing 6.5 times more tickets, saw the percentage of critical vulnerabilities still unresolved at seven days actually worsen from 56% to 63%. Massive effort, negative marginal returns.

This happens because writing the fix is only about 10 to 15% of the enterprise remediation timeline. The rest is organizational work such as impact assessment, cross-team coordination, testing against dependent systems, scheduling deployment windows, deploying without breaking production, verifying the fix.

That bottleneck is organizational, not computational.

AI can help write patches faster, but a 10x improvement in fix-writing speed applied to 10 to 15% of the total timeline produces less than a 2x improvement end to end. That does not change the math when discovery has increased by orders of magnitude.

Meanwhile, the exploitation window has collapsed.

CrowdStrike’s 2026 Global Threat Report puts average breakout time at 29 minutes, with the fastest observed breakout at 27 seconds. The broader exploitation window compressed from 771 days in 2018 to just hours in recent years, as is well documented in the Zero Day Clock.

For the class of vulnerabilities that actually determines whether an organization suffers a material breach, attackers are often discovering and weaponizing before defenders are even notified.

Patching remains necessary. It is a hygiene function that every organization must perform, but the ecosystem math means it can no longer serve as the sole strategy an organization relies on to prevent material breach. Discovery is compounding, remediation has a ceiling, and the gap between them is widening, not narrowing.

A Practitioner’s History with Microsegmentation

The idea that you should limit lateral movement through network segmentation is not new. It has been a foundational security principle for decades. NIST has written about it extensively in publications such as 800-207. CISA’s Zero Trust Maturity Model explicitly includes network as a pillar, and the advanced maturity levels require microsegmentation with dynamic, identity-based policy enforcement.

Every serious security framework includes some version of this requirement.

The adoption numbers tell a different story. Gartner estimates that only 5 to 20% of enterprises have implemented microsegmentation in any form. In cloud specifically, only a small fraction of workloads have any perimeter network security at all. The vast majority of production environments are still running flat or near-flat architectures where compromising a single workload can give an attacker a path to nearly everything.

I lived this problem firsthand during my years helping large federal enterprises implement zero trust. The pattern repeated across agencies and programs. Security teams would identify microsegmentation as a priority. Leadership would agree in principle…then the project would stall.

The first reason was fear of breaking production.

Network policy changes carry real operational risk. In environments where uptime is measured against availability SLAs that carry political consequences, teams default to inaction rather than risk an outage. I watched programs where the security architecture was approved, funded, and staffed, and still never enforced because the operations team could not accept the risk of flipping the switch and potentially impacting business units.

The second reason was operational complexity.

Traditional microsegmentation required deep network engineering expertise, manual policy creation for every communication path, and constant policy maintenance as applications changed. Most organizations did not have the staff, the tooling, or the institutional patience for it. The policies grew stale, the exceptions multiplied, and eventually the segmentation existed on paper while production networks stayed flat.

The third reason, and perhaps the most fundamental, was that nobody actually knew what their applications needed to talk to.

You cannot write effective segmentation policies without a complete understanding of application communication patterns. In most environments I worked in, that understanding did not exist. Application teams knew their own service, but the full map of dependencies, especially transitive ones across shared infrastructure, was something nobody owned.

So the concept sat on architecture diagrams and compliance checklists while production environments stayed open, and every time an attacker got through, the blast radius was the entire environment because nothing constrained lateral movement or egress.

Secure-by-Design Means Architecture, Not Just Code

The industry conversation around Secure-by-Design has focused heavily on how software is written. Memory-safe languages, secure coding practices, developer security education, secure defaults in libraries and frameworks.

All of that work matters and should continue, but Secure-by-Design should apply with equal force to how systems and environments are architected and deployed.

A perfectly written application deployed in a flat network with unrestricted egress and over-permissioned service identities is not secure by design. It is secure code sitting in an insecure architecture. When that application gets compromised, and given the vulnerability deficit it eventually will, the damage is determined not by the quality of the code but by the architecture surrounding it.

NIST and CISA included network segmentation in their publications and guidance because decades of breach data demonstrate that the presence or absence of architectural containment is a determining factor in whether an incident becomes a catastrophe.

That data continued to prove the point in 2026. CrowdStrike reports that 82% of intrusions now use valid credentials through legitimate channels, producing no anomalous signal. Attackers are logging in rather than hacking in. The identity layer sees no violation, the endpoint layer sees no malware, and the question of whether the attacker can move laterally and exfiltrate data comes down entirely to whether architectural constraints exist on those paths.

This is what I mean by building for resilience.

We need to accept that breaches will occur and orient our architecture around limiting the damage when they do. Patching tries to reduce the probability of breach. Detection tries to minimize the time an attacker operates. Architectural containment reduces the blast radius, and it is the only variable fully determined by design choices the defender makes before any incident occurs.

Cloud Made the Problem Worse

On-premises environments, for all their limitations, developed with multiple defensive layers roughly in balance. The network pillar was pervasive, with perimeter firewalls, internal zones, VLAN segmentation, and routing-enforced separation. A compromised credential still had to traverse multiple layers before reaching anything of value.

Cloud inverted that posture. Identity became genuinely strong through AWS IAM, Azure Entra, and GCP IAM, but cloud providers left networking wide open because their economic engine is developer velocity, and network security reads as friction.

As Doug Merritt put it when we discussed this on Resilient Cyber, “developer velocity and security is friction.” That incentive structure produced defaults where every major cloud provider ships allow-all outbound traffic and permits unrestricted communication between workloads in the same network. Kubernetes compounds the problem, with EKS, AKS, and GKE all permitting unrestricted pod-to-pod communication unless explicit network policies are applied.

The endpoint pillar became patchy in cloud at the same time. Containers, serverless functions, managed databases, and AI inference endpoints cannot host traditional agents. Much of the modern compute fabric lives for seconds. The workload types growing fastest are the types least compatible with agent-based security.

The practical result is that defense-in-depth in the cloud collapsed to a single pillar. That pillar, identity, is getting outsized focus, and rightfully so. It is also the pillar most easily bypassed when the attacker arrives with valid credentials, which is what happens in 82% of intrusions.

This is why, as I discussed with Doug Merritt on Aviatrix’s In Progress podcast, the interesting question is never how they got in, it is always a lateral movement and egress problem.

What Containment Looks Like in Cloud

The historic blocker to microsegmentation was cognitive load.

Writing and maintaining policies for tens of thousands of workloads across multiple clouds, regions, and compute models was more than most teams could sustain. That is the version of segmentation I watched fail repeatedly in federal environments.

What changed is AI.

AI is strong at the synthesis and pattern-matching that segmentation demands, specifically baselining application communication patterns, recommending policies based on observed behavior, and identifying anomalous flows against that baseline. The staged path of observe, baseline, monitor, and then enforce that was theoretically correct but practically unworkable a few years ago is becoming operationally realistic.

I recently walked through Aviatrix’s approach to this problem in a pair of detailed demos with their engineering team, and it maps well to what I always wished I had available during those federal zero trust implementation efforts.

The platform starts with visibility, onboarding cloud accounts in read-only mode to discover traffic flows and existing workloads across VMs, containers, Kubernetes clusters, and AI agents. This is the step that most segmentation projects skip or historically involved manual interviews and discussions with application teams, and it is the step whose absence causes everything downstream to fail.

You cannot write policies for communication patterns you do not understand.

From there, Aviatrix deploys lightweight enforcement points at the account level that govern both egress and east-west traffic without requiring global network modifications or changes to the underlying routing infrastructure.

Policy is expressed in terms of workload identity using existing cloud metadata and tags rather than IP addresses, which are meaningless in environments where workloads are constantly created and destroyed.

The enforcement model progresses through a lifecycle, from unprotected to monitored to partially protected to fully protected, giving teams the ability to validate policies against real traffic patterns before activating enforcement. If something breaks, reversal is a single action rather than an escalation path.

Two aspects of their approach address the failure modes I saw most often in practice.

The first is that the platform assumes brownfield environments. Most segmentation tools I’ve evaluated assumed some degree of greenfield architecture, and that assumption almost always wrong. Aviatrix works with whatever the customer has deployed today, as the network exists now, not as we wish it did.

The second is support for a dual-control operational model where a security team manages overarching guardrails and threat blocking through a centralized interface, while application teams manage their own specific policies through Terraform and CI/CD pipelines, in the formats and methodologies they are used to.

This aligns with how modern platform engineering teams actually work, and it distributes the operational burden of policy management across the people who best understand what each application needs.

The platform also extends containment to AI workloads, with the ability to detect communication with LLM endpoints and apply policy to AI agents.

Given that AI agents are rapidly becoming privileged non-human identities with broad cross-service access, and given real-world demonstrations like the GrafanaGhost attack where an AI assistant was weaponized to exfiltrate data through an authorized rendering channel with no anomalous signal, governing AI agent communication paths is not a theoretical future concern.

It is a current operational gap that most organizations have not begun to address.

Looking for a deeper dive for effective containment in the AI era? Grab the guide below!

-> Grab the Guide! <-

Building for Resilience

I named my outlet and brand Resilient Cyber for a reason.

Resilience has always been the more honest framing for security. It does not pretend that prevention will succeed every time and instead, it accepts that incidents will occur and focuses on ensuring those failures are survivable.

Containment is the architectural expression of that principle.

It does not prevent the initial compromise, it prevents the initial compromise from propagating into the kind of lateral movement and data exfiltration that turns an incident into a headline. It holds whether or not the exploited vulnerability has been patched, whether or not the breach has been detected, and whether or not anyone on the security team is awake at 3 AM when the attacker moves.

The cybersecurity industry invested two decades primarily in prevention and detection. Both remain necessary, and both face structural headwinds that limit their effectiveness as standalone strategies.

The threat environment now demands at least equal investment in the architectural layer that governs what happens after prevention fails and before detection catches up. Blast radius should be a metric that CISOs, CIOs, and boards track deliberately and drive down over time, not a number they discover after an incident.

Organizations that treat it this way will be the ones who’s incidents stay local and recoverable, while everyone else is left explaining to leadership and regulators why a single compromised workload gave the attacker access to the entire environment.

Subscribe now

When the perimeter collapsed and work scattered across SaaS applications, personal devices, and home networks, the industry needed an architecture that could follow. SASE promised exactly that. Converge networking and security into the cloud, route traffic through centralized inspection points, and apply policy regardless of where the user sits.

For a while, it worked well enough, and then AI entered the picture and accelerated a set of structural limitations that were already forming.

Over 20,000 enterprises purchased SASE solutions in 2025.

Most have only partially deployed the capabilities they own. Licenses sit unused, bypass lists quietly grow, and policies look complete on dashboards while gaps widen in practice. This is not a failure of execution or a vendor quality problem. It is a sign that the problem SASE was designed to solve has changed underneath the architecture and shelf-ware is pervasive.

Understanding where traditional SASE fits in that complexity, and where it falls short, matters for every practitioner evaluating their current stack.

The Detour Tax

The core execution model of traditional SASE is straightforward.

Traffic is backhauled to a cloud proxy, broken and inspected, and forwarded to its destination. Enforcement depends entirely on routing sessions through centralized inspection points at distant points of presence.

When that architecture was designed, it made sense. The problem is not that it was wrong, the problem is that it was designed for a world that no longer exists.

Every session routed through a distant PoP pays what you might call a detour tax. CRM sessions lag, video calls stutter, and ticketing systems stall. In bandwidth-constrained geographies, SaaS workflows become inconsistent or borderline unusable. Users feel this immediately and respond in the most predictable way possible. They find workarounds, they switch to personal devices, and they use unsanctioned tools. Every workaround quietly increases the attack surface, shadow usage, and security teams rarely learn about it until something goes wrong.

The reliability problem compounds this. When a PoP degrades, a certificate chain breaks, or a decryption policy change propagates incorrectly, the blast radius is broad. A user in Toronto connected through a Detroit PoP may find their location misidentified, their compliance posture incorrectly evaluated, and their sessions flagged for a border-crossing that never happened. Traffic shifts during failover can impact thousands of users at once.

Failure in this model is systemic, not local.

This is a pattern practitioners have seen before. Security architectures that create friction do not eliminate the behavior they are trying to govern. They push it into channels where security has even less visibility. As I covered in Bringing Security Out of the Shadows, this cycle has repeated with every major technology wave. Cloud, mobile, SaaS, and now AI. Security policies that default to blocking breed shadow usage, and shadow usage is always harder to secure than governed usage.

The Visibility Gap

Even when SASE works as designed, there is a structural limit to what network-layer inspection can see.

A network proxy can tell you that a file was uploaded. It cannot tell you what was copied into an AI prompt, pasted into a web form, or moved between SaaS tenants before submission. It can see destinations and payloads when decryption is possible. It cannot capture what a user actually did inside an application.

This gap matters because the most common ways sensitive data leaves an organization today do not look like network incidents. A freelancer copies customer data from a CRM and pastes it into an LLM. An analyst downloads a financial model and uploads it to personal cloud storage. A developer pushes proprietary code through an AI assistant to accelerate a sprint. None of these actions generate anomalous traffic patterns or trigger firewall alerts. They occur at the presentation layer, inside the application, at the moment of user interaction, as work is being created and used.

Even more so, they are increasingly occurring via autonomous agents, which have the ability to call tools and take actions in the enterprise, often with users identities, never appearing anomalous or unauthorized on the surface.

Modern encryption is making this gap worse, not better. TLS 1.3 reduces available metadata. Certificate pinning makes decryption impossible for a growing number of applications. Post-quantum cryptographic implementations are already deployed in major browsers, and they are structurally incompatible with break-and-inspect architectures. Organizations are left with a choice that should not exist. Block traffic you cannot decrypt, or accept the blind spot and allow it. Most choose the blind spot, and the bypass lists grow.

Every application added to a bypass list to preserve compatibility is an application outside the security perimeter.

An architecture that requires exemptions to function is not enforcing policy, it is avoiding it.

AI Did Not Break SASE But It Does Expose a Gap

AI did not create the architectural mismatch with traditional SASE, but it made the mismatch impossible to ignore.

Modern AI workflows are fundamentally non-linear. Employees paste sensitive internal data into prompts. AI agents call external tools, access internal documentation, and move generated output downstream at machine speed. That output flows into reports, code repositories, and customer communications. An organization’s agent workforce will soon operate using employees’ roles and access at 100 times human scale.

All of these interactions happen at the presentation layer, inside the application context, before any new network connection is established. By the time traffic reaches the network, the moment of intent has already passed. A network proxy sees the session but cannot see what is happening inside it.

Traditional SASE vendors respond with the only option their architecture permits. Block AI or allow it. Organizations that block AI push usage into personal, unmanaged tools, fueling shadow AI and expanding the attack surface they were trying to reduce. Organizations that allow AI without context accept data leakage, compliance exposure, and zero accountability for what employees send and receive. Neither approach is ideal or acceptable.

IBM’s 2025 Cost of a Data Breach Report found that 63% of organizations lack AI governance policies. Twenty percent of organizations surveyed experienced a breach due to shadow AI, adding $200,000 to $670,000 in costs compared to incidents without shadow AI involvement. The binary enforcement model is not just architecturally limited, it is actively producing the outcomes security teams are trying to prevent.

Leading analysts expects AI security capabilities, including prompt inspection and application controls, to become a key factor in SASE platform decisions over the next two years. Most current vendors stop at basic visibility or binary block controls. The architecture often simply does not support anything more.

The Shelfware Problem Is Structural

There is a pattern practitioners will recognize from their own environments. SASE licenses are purchased at scale then deployments stall, features are enabled but never fully tuned and exception lists accumulate. Multiple service chains and overlapping policies across SWG, CASB, and ZTNA create troubleshooting complexity that compounds over time and unsurprisingly, rollouts stretch from weeks to months.

Organizations end up running fragmented SASE stacks with multiple consoles and policy engines operating in parallel. Enforcement looks complete on dashboards while gaps persist in practice.

This is not a failure of organizational discipline and instead is a predictable consequence of architectures that require mandatory backhauling and extensive configuration before delivering meaningful coverage. When the deployment path is that long and complex, partial deployment becomes the norm rather than the exception.

The shelf-ware problem is structural, not operational, but it does have operational impacts as deployments stall, visibility is limited, the shelf-ware becomes part of the attack surface and concurrently eats away finite security budgets.

What Changes When Enforcement Moves to the Last Mile

If the risk lives at the presentation layer, in the actions users or agents take inside applications, at the moment data is created, copied, uploaded, or sent, then enforcement has to live there too. Not in a distant PoP after the moment of intent has passed, but at the point of work, before the data ever leaves the endpoint.

This is the architectural shift that separates the next generation of SASE from the current one. Moving enforcement to the last mile changes three outcomes simultaneously.

Security gets stronger because the visibility gap closes. Copy-paste actions, prompt content, tenant context, and output destinations all become visible. Enforcement is based on what users actually do, not inferred from packet metadata. Zero Trust is applied at the application layer per user/agent, per session, per action, and because modern protocols are supported natively, organizations do not need bypass lists to keep critical applications functioning, every session is governed.

User experience improves because most sessions go direct, and as we discussed when user experience improves, security doesn’t get undermined. There is no mandatory detour through a distant proxy, no forced TLS inspection degrading application performance, no latency from routing traffic through inspection points. Applications behave the way they were designed to behave. Users stop finding workarounds because they do not need them.

When security stops creating friction, adoption of sanctioned tools increases and IT spends less time managing exceptions.

Operations simplify because policy is defined once and enforced consistently. One policy engine. One audit trail. No service chaining across separate consoles. No overlapping rule sets between SWG, CASB, and ZTNA producing inconsistent outcomes. Deployments that used to take months compress to days.

How Island Approaches This

To provide a concrete example, I wanted to use Resilient Cyber’s Partner Island.

Island’s approach starts from a simple architectural insight, which is that enforcement should happen locally, as close to the action as possible, whether that action is in a browser, a desktop application, or an agentic AI workflow.

As I covered in The Rise of the Enterprise Browser, the enterprise browser represents a Secure-by-Design paradigm shift from bolt-on products focused on the endpoint or network.

Island enables organizations to say yes rather than no, allowing personal email, personal AI usage, and contractor access within governed boundaries rather than blocking everything and hoping shadow usage does not follow, but the enforcement story extends well beyond the browser.

Island Desktop performs local-first enforcement directly on the endpoint, governing agentic actions, MCP and tool calls, and data and file movements at the device level before anything leaves the machine.

This is not just a traffic steering mechanism that routes sessions to a cloud network for inspection, although it does that where policy requires it. The endpoint itself is the enforcement point. For desktop applications and non-web traffic, Island Desktop applies policy locally and steers traffic selectively to Island’s global network only when deeper analysis or routing adds genuine value.

Backhaul becomes the fallback, not the default.

Island Desktop also facilitates Zero Trust Network Access (ZTNA), which allows users to connect directly to private applications and resources, including private MCP servers. For organizations deploying agentic AI architectures that rely on internal tool registries and private MCP infrastructure, this is a meaningful capability. Agents can reach internal resources through governed channels without exposing those resources to the public internet or requiring traditional VPN tunnels.

For browser-based work, policy is applied natively inside Chromium at the DOM layer before content renders and before data leaves the session. No traffic rerouting, no TLS interception, and no break-and-inspect. Island also provides a browser MCP server that allows AI agents to access web pages through Island, but everything the agent does over that MCP server is governed by policy.

Sensitive data that policy blocks is not simply redacted into an unusable gap, it is replaced with a context placeholder, such as <US SSN #>, so the AI agent can still reason about the structure and meaning of the content without ever seeing the actual sensitive value. That distinction matters because outright blocking breaks agent workflows, while context-aware redaction preserves utility within policy boundaries, and avoids perpetuating the reputation of “security is a blocker”.

Island calls this “the Perfect Packet.” For every session, the most efficient and secure path is chosen based on policy. In most cases, enforcement runs locally, whether on the endpoint through Island Desktop or in the browser through DOM-level controls, and the packet goes direct. Cloud inspection is invoked only when deeper analysis or routing adds genuine value.

For a deeper dive on the concept, grab a free guide “The Perfect Packet: A Guide to Modern SASE Architecture”.

-> Grab the Guide! <-

The full SASE capability set runs through a single platform. Zero Trust network access, secure web gateway, DLP, CASB, AI governance, remote browser isolation, and digital experience monitoring are all unified under one policy engine and one audit trail. There is no service chaining, no policy re-evaluation at different enforcement points, and no need to route traffic to a separate service for inspection.

On AI governance specifically, Island governs AI at the point of interaction, whether that interaction happens in a browser, a desktop application, or an agentic workflow on the endpoint.

Content-aware detection inspects prompts and uploads in real time. Data boundaries define which AI tools, tenants, and workflows are approved for organizational use. Tool calls, MCP access, and agent-to-agent communication are governed and logged, with enforcement applied locally rather than requiring a round trip to a cloud inspection point.

The result is AI access that works within policy, without block pages, without shadow AI, and without forcing a choice between productivity and protection, which is where security tends to introduce the most friction.

The deployment model matters as much as the architecture.

Island offers a phased approach that starts with an extension on existing Chrome or Edge browsers, requiring no network changes, no agent deployment, and no browser migration, but policy enforcement starts immediately.

Organizations can then move to the full enterprise browser for DOM-level enforcement, add Island Desktop for endpoint-level and agentic AI governance, and extend to the global multi-cloud network for environments that need centralized inspection, with each phase delivering standalone value from day one.

This is important because, as discussed above, the most predictable SASE failure mode is not a security breach. It is a deployment that never gets completed. An architecture that delivers value incrementally from the first day of deployment is fundamentally different from one that requires months of configuration before meaningful coverage begins.

This is a modular type of approach I wish more security vendors would take, to ensure we avoid shelf-ware and instead capitalize on security spend to truly reduce organizational risks.

The Question Practitioners Should Be Asking

There’s no question that SASE as a concept is valuable. The converged model that SASE represents, bringing networking and security together regardless of where users sit, remains the right strategic direction. However, organizations do need to ask if the execution model their current architecture depends on can actually deliver on that promise given how work happens today.

If your bypass lists are growing, if your users are finding workarounds, if your AI governance strategy amounts to allow or block at the domain level, if your deployment is still incomplete months or years after purchase, those are not operational problems to be solved with more configuration. They are architectural signals that the enforcement model needs to change.

The practitioners who will navigate this well are the ones who ask the uncomfortable questions about what their current stack is actually delivering versus what the dashboard says it is delivering. The gap between those two things is where the real risk lives but it requires us being honest about shortcomings rather than glossing over them.

Subscribe now

Closed labs argued that frontier capabilities were too dangerous to hand out freely. Open advocates argued that transparency, cost, and control were worth more than a marginal capability lead. Practitioners could mostly watch that argument from the sidelines, because in day-to-day security work the closed frontier models were simply better and the open models were a step or two behind.

That gap has closed, and the debate has stopped being academic. It is now a live architectural decision that CISOs, security engineers, and platform teams are making right now, often without a clear framework for reasoning about the security implications on either side.

I want to walk through how we got here in the middle of 2026, and then spend most of my time on the part I think we are collectively underweighting, which is what the open versus closed choice actually means for defenders and for the software supply chain we all depend on.

How U.S. policy talked itself into a corner

Start with the strategic goal, because the goal and the actions have drifted apart in a way that matters. In July 2025 the administration issued Executive Order 14320, Promoting the Export of the American AI Technology Stack.

The explicit ambition was that American AI hardware, models, standards, and governance would become the default stack for allies and partners around the world. If you wanted the U.S. to win the AI competition with China, exporting the American stack and getting the world to build on it was a coherent way to do it.

Then came the whiplash.

In June 2026 Anthropic launched Fable 5 and Mythos 5, and roughly three days later the U.S. government ordered the company to cut off foreign access to both, citing national security and export-control authority. Reporting from various leading media outlets tied the order to a jailbreak report from a trusted partner, with reporting pointing to Amazon, that suggested the models could be turned into unrestricted cyber tools.

Anthropic disputed how severe the jailbreak actually was and criticized the opaque process. About eighteen days later the restrictions were lifted and the models came back online.

I already worked through the ban itself in Cybersecurity’s Friendly Fire Problem, so I will not relitigate the whole thing here. The short version is that gating and banning a U.S. frontier model did not remove the underlying capability from the threat landscape.

It removed the U.S. ability to watch that capability being used, and it handed every ally in Europe and beyond a concrete reason to question whether building on an American AI stack carries political risk. That is the opposite of what Executive Order 14320 set out to accomplish.

When France and the Netherlands start amplifying calls for AI sovereignty within days of your export action, the export strategy is working against itself.

The quieter forces pushing people toward open weights

The ban gets the headlines, but it is not the only thing reviving interest in open source AI, and I want to be careful not to overstate its role. Several structural forces are converging at once, and most of them have nothing to do with geopolitics.

The first is cost, and it is the one practitioners feel most directly. For a brief window in early 2026 the loudest signal of AI adoption inside big companies was token consumption going up.

That has reversed hard. Coverage from TechCrunch and others documented finance teams now trying to drive that same number down. Amazon reportedly shut down an internal leaderboard that ranked developers by token consumption in late May 2026, with the internal line being that you should not use AI just to use AI. Uber said it burned through its entire 2026 AI coding-tools budget in four months and capped spend at $1,500 per employee per month per tool.

Agentic workflows consume something like 5x-30x the tokens of a standard chatbot interaction, so the economics of running everything through a metered frontier API stopped making sense for organizations operating at scale.

has been making this point for a while, and it lands especially hard in security, where you are often running high-volume automated analysis and per-token costs compound quickly. When Gary Marcus says tokenmaxxing is giving way to tokenminimizing, that is not a vibe, it is a budget line. It also pours some cold water on the theme that the answer to every security problem AI introduces is to use AI to fight it.

The second force is the frontier labs themselves adding friction to their own products in the name of safety. When Anthropic redeployed Fable 5 in July 2026, it did so with a new classifier layer.

Per Anthropic’s own Redeploying Claude Fable 5 post, a Fable 5 request that trips the new cyber classifier is rerouted to Claude Opus 4.8, with the user notified, so the work still completes on a more conservative model. Anthropic was honest about the tradeoff, which I respect, noting that the classifier flags benign requests more often during routine coding and debugging.

If you are a security engineer doing legitimate vulnerability research or debugging exploit-adjacent code, you now have a real chance of being downshifted to a different model mid-task because a safety-margin classifier decided your benign work looked risky. That is a rational safety decision on Anthropic’s part and a genuine capability tax on the practitioner. It is exactly the kind of friction that makes a self-hosted model you fully control look attractive.

I’m in various private group chats with security researchers and leaders and it is full of folks frustrated with the classifiers downgrading their legitimate security work.

The third force is the one that changes everything, which is that open weights have caught up. In June 2026, Z.ai released GLM-5.2, a roughly 744-billion-parameter mixture-of-experts model with around 40 billion active parameters, a one-million-token context window, and an MIT license.

It ranks first among open-weights models on the Artificial Analysis Intelligence Index and fourth overall. On coding benchmarks it beats GPT-5.5 on SWE-bench Pro and lands within a point of Claude Opus 4.8 on FrontierSWE, and it does it at roughly one-sixth the cost. For mainstream coding and engineering work, GLM-5.2 is effectively at parity with the closed frontier.

The gap only opens meaningfully on the hardest ultra-long-horizon tasks. When the open option is at parity, six times cheaper, self-hostable, and cannot be turned off by a government order, the pull is obvious.

Folks such as have used GLM-5.2 as an example of how counterproductive the U.S. ban on closed source frontier models are, and how it hurts defenders more than attackers in his piece “GLM-5.2 not Mythos, is the real security emergency”.

The industry signals are stacking up as well. Alex Karp at Palantir went on CNBC on July 1, 2026 and called the token-based pricing model of the frontier labs “completely wrong,” framing open-weight models as the answer for customers who want control over their compute, their models, their data, and their alpha.

He also asked whether the country really wants to outsource its national security posture to the consensus view of Silicon Valley, and he warned against underestimating how fast China is moving. Say what you want about Palantir’s true motives, but many of his points are ones a lot of folks do share when it comes to AI. The below video has now gone viral:

Separately, Axios reported that Microsoft is exploring a fine-tuned, Azure-hosted version of DeepSeek V4, or another open model, as a lower-cost option inside Copilot.

I want to flag both of these carefully. Karp’s comments are on the record and his framing is his own. The Microsoft reporting describes an exploration that Microsoft says is not final, with the model that would be optional and hosted inside Azure with added safeguards. Neither is a settled decision to standardize on Chinese open weights, and I would not treat them as such. Microsoft isn’t along either though, as it is reported many other Western companies are adopting Chinese AI models as well:

What they do show is that the “open weights are for hobbyists” framing is dead, and serious enterprises and serious buyers are actively pricing the switch. It is also interesting that one of the largest software suppliers to the U.S. Government in MSFT is looking at potentially using DeepSeek, albeit they likely wouldn’t use it for their Government approved offerings.

The political signal is arguably more striking. Former U.S. AI Czar David Sacks used a recent episode of the All-In podcast that I listened to over the weekend to make the case for open source AI directly, arguing that open source is one of America’s strongest cards in the competition with China rather than a liability.

He echoed Karp’s point that what enterprises actually want is control over their compute, models, and data, and he raised the concern that feeding proprietary knowledge to frontier labs is risky when those same labs are launching vertical applications that compete with their own customers.

You can debate how much of that is a fair characterization of the labs, and Anthropic and OpenAI would push back hard. What matters for this discussion is that a figure who sat at the center of U.S. AI policy is now publicly framing open source as a strategic asset, not the thing to be restricted. That is a meaningful shift in where the political center of gravity sits.

Several others have had great pieces on this shift too, such as ’s blog titled “The Token Apocalypse”, or blog “The State of AI: The US is Losing its AI Monopoly”.

The security argument that flips the usual intuition

Here is where security practitioners have to update their intuition. The reflexive take is that closed, gated models are safer because access is controlled. made the sharper argument in his piece that GLM-5.2, not Mythos, is the real security emergency, and I think he is right about the mechanism.

When an attacker uses a closed model, they are operating on the provider’s infrastructure, under monitoring, with trust and safety teams watching for abuse. That is not a hypothetical benefit, it is exactly how Anthropic caught the first documented large-scale AI-orchestrated cyber espionage campaign, which it disclosed in November 2025 and attributed with high confidence to a Chinese state-sponsored group.

The attackers jailbroke Claude Code, ran roughly thirty targets, and let the model handle an estimated 80 to 90 percent of the campaign autonomously, with humans stepping in at only a handful of decision points. Anthropic caught it, mapped it, banned the accounts, and notified victims, because the operation ran on monitored, API-gated infrastructure. Even if you discount some of the lab’s framing as marketing, the visibility point holds, you cannot ban an account you cannot see. This is something enterprise security leaders already know intuitively after years of wrestling with shadow IT/SaaS and now AI.

Now run the same campaign on a self-hosted open-weights model.

There is no usage log, no trust and safety team, no account to ban, no detection to trigger. The capability does not go away when you restrict the closed model.

It relocates into the dark, onto a rack of H200s in an environment nobody is watching. So the current restrictions harm defenders more than attackers, because defenders lose their best monitored tooling while attackers simply migrate to the ungoverned option. Joshua Saxe’s conclusion, which I share, is that the priority should be accelerating AI adoption among defenders and security vendors rather than restricting frontier access, because the open-weights genie is already out of the bottle.

In fact, when I spoke at the SANS AI Security Summit earlier this year I made this exact argument, that security needs to be an early adopter and innovator with AI. It is very hard to do that if we’re being handicapped and having our access to the capabilities restricted.

This connects to something I have been writing about for a while, which is the jagged frontier of AI in offensive security. The comfortable assumption is that offensive capability is gated behind the biggest, most expensive, most restricted models.

The evidence says otherwise. AISLE’s ran Anthropic’s own showcase Mythos vulnerabilities through small, cheap, open-weights models and found that eight out of eight models detected the flagship FreeBSD exploit, including one with only 3.6 billion active parameters costing eleven cents per million tokens.

A model with 5.1 billion active parameters recovered the core chain of a 27-year-old OpenBSD bug. His conclusion is that the moat is the system, not the model, because capability does not scale smoothly with size or price.

Niels Provos reached a compatible conclusion with his work on autonomous zero-day discovery, arguing that finding vulnerabilities is an orchestration problem, not a frontier-model problem.

I sat down with Niels for a full conversation on exactly this, and the through line is consistent. With a good harness, capability that we assumed required a frontier model is available to anyone with modest, older, or open hardware. Gating the frontier does very little to gate the capability.

The next policy mistake is already forming

If the Mythos ban was restriction aimed at the closed frontier, the move that worries me more is the growing appetite to regulate open source itself. Dario Amodei has been consistent that open-source AI is heading down what he calls a very dangerous path, and his June 2026 policy essay, Policy on the AI Exponential, called for FAA-style, government-mandated safety evaluations before any frontier model can be publicly deployed, open or closed.

He points to genuine concerns, including bioweapons uplift from Anthropic’s own red-team testing, cyberattacks on critical infrastructure, and the plain fact that you cannot recall an open-weights release the way you patch a breach. That irreversibility point is real and worth taking seriously.

I would weigh the framing honestly, though. Critics have noted that Anthropic sells API access to Claude, and open models approaching Claude’s capability are a direct competitive threat, which is a relevant data point when a lab argues that its competitors’ release model is the dangerous one.

It is the same skepticism people applied to the arguments against releasing GPT-2 back in 2019, and the safety case and the commercial case happen to point the same direction. I am not assigning motive, but practitioners should hold both things in view at once.

There’s also a strange conundrum involved, where yes, it is in Anthropic, OpenAI etc.’s commercial interest to stifle open source, but ironically, much of the U.S. economy is now riding high due to the AI boom, and the role of the frontier labs, hyperscalers, the venture capital involved, and infrastructure buildout and more. If the labs struggle, it inevitably will reverberate across the U.S. economy as well.

The bigger problem is that regulating open source would fail on its own terms and likely backfire, for reasons and laid out in Banning Open Source AI Would Be a Mistake.

A U.S. rule restricting open weights binds U.S. labs and U.S. developers. It does nothing to GLM-5.2, DeepSeek, or Qwen, which are already downloaded, mirrored, fine-tuned, and self-hosted around the world. You cannot un-release a model (in open source).

Regulating domestic open source because of China would chill American education, research, and competition while handing the global default to Chinese models, which is the exact outcome the policy claims to prevent. It is the chip export-control lesson all over again, where denial accelerated the alternatives rather than stopping them.

Constraint breeds innovation, which is exactly what we’re seeing play out with China’s AI, from chips to models.

Lambert has separately described the current posture as “vibe governance”, where model releases are judged by political instinct rather than transparent technical assessment, and he argues that export bans on model weights are a lasting negative for U.S. leadership.

For defenders specifically, this would widen the same visibility gap the Mythos ban opened. Restricting domestic open source hobbles the vendors and security teams building defensive tooling on open models, while attackers keep running whatever they already pulled down.

You would be regulating the people you can see and leaving untouched the people you cannot.

The uncomfortable part, and why it is not just “China bad”

Here is the part that makes practitioners uneasy, and it should. Much of the leading open source is coming out of Chinese labs. GLM-5.2 is from Z.ai. DeepSeek is Chinese, Qwen is Chinese, Kimi is Chinese.

The nation the U.S. most wants to out-compete on AI is currently producing the open models that are cheap, publicly available, increasingly capable, and attractive precisely because they let enterprises keep their own data and control their own stack. There is real irony in a world where American export policy nudges American enterprises toward Chinese open weights.

I also want to be specific about the risk here, because “China bad” is lazy and it leads to bad decisions. Open weights are not a black box you have to trust blindly. That is the whole point of them. You can self-host them, air-gap them, control every network flow in and out, scan the weights, monitor inference, and log everything.

In a lot of ways a locally hosted open model gives you more control and more visibility than a closed API where your data leaves your environment and you trust the provider’s word about what happens to it. For data-sovereignty-conscious organizations and entire nations, that control is the feature.

But the risks that remain are real and they are not the ones people usually name. The concern is not that the model phones home, because you can prevent that. The concern is what is baked into the weights and the pipeline that produced them.

Poisoned or backdoored weights, where a model behaves normally until a specific trigger activates hidden behavior. Training-time bias, whether deliberate or incidental, that shapes outputs on politically or strategically sensitive topics. Jailbreak susceptibility that varies by model and is hard to fully characterize. Supply-chain tampering anywhere between the lab that trained the model and the checkpoint you actually download. These are not exotic, they are the AI-native versions of problems we have spent a decades learning to take seriously in software.

This is a software supply chain problem, and we have seen this movie

When Tony Turner and I wrote Software Transparency, with Steve Springett as technical editor and Allan Friedman writing the foreword, the core argument was that a software-driven society cannot run on components it cannot inspect.

We spent years pushing SBOM, provenance, and transparency because you cannot secure what you cannot see, and because trust in a supplier is not the same thing as verification of an artifact. The entire discipline grew out of watching supply-chain attacks like SolarWinds and the log4j scramble teach us that the thing you did not build, did not inspect, and cannot attest to can be exactly the thing that hurts you.

AI models are now the most consequential unaudited dependency most organizations have ever adopted, and we are integrating them at the center of our development pipelines and security tooling with far less rigor than we would demand of a random npm package. The leading model hosting platform, Hugging Face now has almost 3 million models alone.

A model is a supply-chain artifact. It has provenance, or it should. It has a build process, which is the training data and the training run. It has a distribution channel, which is the checkpoint you pulled from a hub. It has integrity properties you would want to attest to and verify. Almost none of that infrastructure exists in a mature form for AI weights the way it now does for software components.

That said, no surprise that my friends at OWASP have been working on this problem for quite some time, with their AI Bill of Materials (AIBOM) project, where they seek to make AI systems transparent, auditable and secure. For those unfamiliar, an AIBOM is a “a structured machine readable inventory of AI components such as models, datasets, agents tools, guardrails, and runtime elements along with evidence of origin, rights, integrity and evaluation.” I dove into this topic with one of the projects leaders, Helen Oakley:

That is the real through line for practitioners.

The open versus closed AI decision is a software supply chain decision, and the disciplines we built for software transparency map almost directly onto what we now need for models.

We need provenance for weights and for training data. We need the equivalent of an SBOM for a model, an artifact that tells you what went into it and lets you reason about it. We need integrity verification so you know the checkpoint you are running is the one the lab actually published. We need the ability to inspect, scan, and continuously monitor model behavior in the environments where we run them (e.g. runtime visibility and enforcement).

Some of this is emerging. Model cards, dataset documentation, and early work on model signing and attestation are steps in the right direction. That said, AI is moving far faster than traditional software supply chain security did.

The point is that we already know how to think about this. We do not need a brand-new philosophy for AI supply chain security. We need to take the transparency and provenance thinking we spent the last decade building for software and apply it to models with the same seriousness, before the integration is so deep that retrofitting it becomes another decade-long slog, that never fully materializes.

What practitioners should actually weigh

So strip away the geopolitics and the headlines, and here is how I would frame the decision for a security leader choosing between open and closed AI, neutrally, because both are defensible depending on your context.

Closed frontier models give you provider-side monitoring, faster patching of newly discovered issues, some assurance of abuse detection, and typically a small capability edge on the hardest tasks.

You pay for that with metered token costs, with data leaving your environment, with exposure to a provider’s safety classifiers reshaping your workflows without warning, and with the political and continuity risk that a model you depend on can be gated or pulled by forces outside your control. The Fable and Mythos episode was a live demonstration that this last risk is not theoretical.

Open-weights models give you control, cost efficiency, data sovereignty, the ability to fine-tune for your use case, and continuity that no government order can revoke overnight. You pay for that by owning the entire security burden yourself. You have to treat the weights as an untrusted supply-chain artifact, verify provenance and integrity as best you can, control the network boundary, monitor inference, scan for anomalous behavior, and accept that backdoor, bias, and poisoning risks are yours to manage rather than the provider’s.

If you are going to run a Chinese open-weights model, and many organizations will for entirely rational cost and control reasons, the answer is not to pretend the risk away and it is not to refuse on reflex. The answer is to wrap it in the same supply-chain rigor you would want for any critical dependency you did not build.

Most organizations are going to end up running both, matched to the task, which is the same conclusion AISLE reached about being model-agnostic by design. We’re even seeing the rise of Model Fusion, where a panel of models are fused together through routers, such as OpenRouter, and often outscore a single model alone. OpenRouter shared some excellent insights into this, in a blog titled “Fusion Beats Frontier”.

That is fine, but what is not fine is making the choice without a security framework, because the failure modes on each side are different and both are real.

Vulnerability exploitation is now the leading initial access vector according to the 2026 DBIR, defenders are already behind, and AI is the largest force multiplier available to close that gap.

Getting the open versus closed decision right, with clear eyes about the security tradeoffs of each, is one of the more consequential architecture calls a security team will make this year.

The strategic mistake would be to keep treating this as a binary morality play about open being reckless or closed being safe, neither alone is true.

The capability is diffusing regardless of policy, the open models are at parity for most of what we do, and the security question is not whether these tools exist but whether we can see and govern how they are used.

That has always been the harder and more important question, and it is the one the software supply chain community has spent a decade learning to answer.

Subscribe now