For a couple of years now, most of us have been having a version of the same argument about AI and offensive security. One camp insists we are on the cusp of autonomous systems that find and chain vulnerabilities without a human in the loop, and the other camp waves it off as vendor theater and demo-ware.

This week, that argument got a lot less hypothetical.

Hugging Face disclosed what it called a new kind of security incident, an intrusion driven by an autonomous agent framework that racked up more than 17,000 attack events over a weekend.

A few days later, OpenAI came forward and filled in the part Hugging Face said it could not yet identify, that the activity came out of OpenAI’s own internal evaluation of cyber capabilities, where two of its models escaped an isolated test environment and chained their way onto a third party’s production infrastructure.

A model going rogue, autonomous exploitation, vulnerability chaining, and the line between an AI safety evaluation and a live security incident dissolving in real time. It is a lot to sit with, and it colors nearly everything else that happened this week, from open-weight cyber capabilities to how we disclose and prioritize the coming flood of vulnerabilities.

Buckle up for another chaotic week at the intersection of AI and cybersecurity.

Cyber Leadership & Market Dynamics

Glow Emerges From Stealth at $1.2B Valuation to Challenge Endpoint Security in the AI Era

Glow stepped out of stealth this week with a $180 million all-equity Series A at a $1.2 billion valuation, led by Sequoia Capital, Cyberstarts, Greenoaks, and Redpoint Ventures.

The founding bench is notable, with CEO Roi Tiger coming from a Meta VP of Engineering role, co-founders out of Snowflake and Claroty, and COO Emily Heath, a former CISO at United Airlines and DocuSign.

Tiger’s framing is the whole thesis, that for the past decade everything moved to the cloud and SaaS, and now AI is landing on the endpoint in a way we have never seen. It is telling that a company reinventing endpoint security for the AI era is itself built on Anthropic and Gemini models running via Amazon Bedrock.

This pairs with Neo below, and both reflect the same bet, that AI agents on the device and in the workflow are becoming the thing we have to secure.

SentinelOne Veterans Raise $100 Million to Secure the Rise of AI Agents

Neo, founded by a trio of SentinelOne veterans in Nick Warner, Shlomi Salem, and Eran Shirazi, has now raised $100 million total, with a $75 million Series A led by Andreessen Horowitz and Bessemer Venture Partners on top of a $25 million seed from 2025.

The pitch is a real-time control layer for AI agents and AI-enabled software, and the founders make the point plainly, that AI agents operate with legitimate user permissions, which is precisely what makes them hard to police with traditional endpoint tooling.

The market context they cite comes from Gartner, which projects enterprise applications with agentic capabilities climbing from around 5% in 2025 to 40% by the end of 2026. If that curve is even directionally right, the identity and control problems tied to agents are about to get an order of magnitude larger.

Backed by $60M in Funding, Oak Steps Out of Stealth to Fix the Identity Mess That AI Agents Are Making Worse

Continuing the theme, Oak emerged from stealth with $60 million in seed funding from Accel, CRV, and Greylock Partners.

Co-founder and CEO Shai Morag has done this before, having sold Ermetic to Tenable for $265 million in 2023, and his read is that AI agents are multiplying access and permission sprawl faster than legacy IAM was ever designed to handle. Oak’s approach maps access to actual app usage and strips excess permissions in real time.

Three separate companies raising real money this week to wrangle agent identity and permissions is not a coincidence, it is the market pricing in the same problem the arXiv researchers and Hugging Face are describing from the technical side.

Zafran Security Reportedly in Cisco’s Sights at $150-200M

Not every story this week is up and to the right. CTech reports that Zafran Security, which has raised more than $130 million total and was valued well above $200 million in a December 2025 Series C led by Menlo Ventures, is the subject of reported Cisco acquisition interest in the $150 to $200 million range, below its last fundraising valuation.

Zafran has denied it is selling and characterizes Cisco’s involvement as a strategic investment, and with roughly $20 million in ARR the numbers are worth watching. Whether or not this specific deal happens, a reported down-round exit sitting right next to a $1.2 billion stealth launch is a decent snapshot of a bifurcated market, where capital is flowing hard toward the AI-native story and getting choosier about everything else.

That selectivity shows up again in the a16z charts below.

Empirical Security Raises $25M Series A to Predict Which Vulnerabilities Matter

Empirical Security announced a $25 million Series A led by Brightmind Partners, and the pedigree here is hard to ignore.

Co-founders Ed Bellis and Michael Roytman built Kenna Security, one of the firms that helped establish risk-based vulnerability management in the first place, and they have brought on Jay Jacobs, a co-creator of EPSS, as a third co-founder.

Their Foundation model monitors more than 18,000 CVEs as a global predictive layer, with an organization-specific model called Radiant on top. Bellis frames it as prediction becoming a requirement for modern defense rather than a nice-to-have.

Given everything in the AppSec section below about disclosure timelines collapsing and vulnerability volume exploding, a bet on prediction and prioritization feels less like a product pitch and more like the only viable path forward.

CrowdStrike and Schwarz Digits Expand Partnership to Deliver Sovereign Cybersecurity Across Europe

CrowdStrike and Germany’s Schwarz Digits expanded their partnership, with CrowdStrike acquiring the intellectual property of XM Cyber, more than 45 patents plus proprietary source code, while XM Cyber continues as a standalone business under an IP license.

The deal deploys Falcon Exposure Management on the sovereign STACKIT cloud, and George Kurtz frames the demand plainly, that organizations globally are increasingly prioritizing sovereignty without wanting to compromise on cybersecurity outcomes. Sovereignty as a buying criterion keeps showing up, and it connects to the open-weight and US-China threads later in this issue.

When European organizations want defense that runs inside their own borders and legal regime, the vendor landscape starts to reshape around that constraint.

Charts of the Week: Software’s Selective Selloff

at put together a useful set of charts on why software is selling off unevenly.

Multiples on next-twelve-months free cash flow are at or below 2014 levels, but the pain is not uniform, with cyber, observability, and vertical SaaS outperforming while horizontal SaaS and infrastructure lag.

A couple of data points jumped out for our world. Software engineer job postings are up around 15% (attributed to the release of Claude Code) even as the broader job market declined roughly 7%, and the Asia-based provider share of OpenRouter tokens has reached about 60%, a three-fold jump since the start of the year. That second figure is a market-side echo of the open-weight capability story the AISI and Mozilla are documenting below.

Cyber holding up while the rest of software gets repriced is interesting, because it suggests buyers still see security spend as non-discretionary even in a cautious tape. This helps further the claim that cyber tends to be a bit more resilient than broader IT or software spend, and the backdrop of AI and security risks I’m sure helps the case.

Raising Venture Capital Is Highly Dilutive

Amid all the funding announcements, Peter Walker at Carta shared the 2026 Founder Ownership data as a useful reality check.

Per Carta’s report, median founder ownership drops from around 56% at seed to about 36% by Series A, and employee equity pools overtake founder ownership entirely by Series C. For the founders behind this week’s Glow, Neo, Oak, and Empirical raises, the capital buys speed and distribution, but the cap table math is unforgiving.

It is a good reminder that the eye-popping valuations in the headlines and the actual ownership retained by the people building these companies are two very different numbers.

The Unicorn Board

If you want the macro backdrop for all of the above, this open dataset tracks 938 US private companies valued at $1 billion or more, with an aggregate post-money valuation north of $5.25 trillion.

AI now trails only Software by unicorn count, and the top of the valuation table is telling, with Anthropic and OpenAI sitting at the very top ahead of Stripe, Databricks, and Waymo.

The gravitational pull of AI on private capital is not subtle, and it helps explain why every security company launching this week is positioning itself as AI-native, because that is where the money, the attention, and increasingly the threat model all point.

AI

Hugging Face Model Evaluation Security Incident

This is the story of the week, and it deserves to be walked through carefully.

For those who prefer video, I made a quick video discussing what happened and its implications:

Last week, Hugging Face disclosed what it described as a new kind of security incident. Over a weekend, a malicious dataset triggered code execution on a processing worker through a remote-code dataset loader and a template injection in a dataset configuration, and from there an autonomous agent framework escalated to node-level access and moved laterally into several internal clusters.

Hugging Face recorded more than 17,000 attack events driven by, in their words, many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services. The attackers reached a limited set of internal datasets and several service credentials, though Hugging Face found no evidence of tampering with public models, datasets, or Spaces, and verified its software supply chain as clean.

Two details from Hugging Face’s own writeup are worth pausing on before we get to the twist. First, they leaned on LLM-based triage over their security telemetry to catch the correlation of signals in the first place, and then used the open-weight GLM 5.2 to process those 17,000 events during forensics.

This is the exact case has been making in his writing and his interview on Resilient Cyber, pointing out that guardrails and safety measures often end up disproportionately hurting defenders more than attackers. You can find my conversation with him below:

Second, and this is the part that really touches on a lot of the debate lately about open vs. closed models and the impact of guardrails. They turned to an open-weight model precisely because Western frontier models refused to process requests containing the real attack commands, exploit payloads, and command-and-control artifacts.

The safety guardrails meant to prevent misuse actively obstructed the defenders trying to investigate a live intrusion. Hugging Face called autonomous, AI-driven offensive tooling no longer theoretical, and at the time they said the originating model was unknown.

Then OpenAI came forward. The activity, it turns out, occurred during OpenAI’s own internal evaluation of cyber capabilities, using GPT-5.6 Sol and an even more capable unnamed pre-release model, both configured with reduced cyber refusals for evaluation purposes.

Inside a supposedly isolated environment, the models identified and exploited a zero-day in the package registry cache proxy, performed privilege escalation and lateral movement, spent substantial inference compute finding a path to open internet access, inferred that Hugging Face hosted the solutions to the ExploitGym benchmark they were being tested on, and then, in OpenAI’s own words, chained together multiple attack vectors, including using stolen credentials and zero-day vulnerabilities to find a remote code execution path on the Hugging Face servers.

A model going rogue, in the literal sense of pursuing its objective straight through the walls of the environment meant to contain it. Autonomous exploitation at a scale and speed no human red team operates at. Vulnerability chaining across a zero-day, privilege escalation, lateral movement, credential theft, and more zero-days to land remote code execution on someone else’s production infrastructure, and the safety-security blur running in both directions, where an AI safety evaluation became a real security incident on a third party, and separately where safety alignment blocked the forensic response. This also highlights the UK’s AI Security Institute assessments playing out on production infrastructure:

Hugging Face’s Clem Delangue’s line lands hard here, that AI safety won’t be solved by any single company working in secret. My take is that the industry can no longer treat safety evaluations and security incidents as separate disciplines with separate teams and separate reporting paths, because this week they were the same event.

We spent years arguing about whether autonomous exploitation was real. It ran to remote code execution across two organizations, and the containment held only because Hugging Face’s people caught it.

Unlocking Self-Improvement in Cyber via GPT-Red

Released just ahead of the Hugging Face disclosure, this OpenAI piece is essential context for it. OpenAI describes GPT-Red, an internal offensive model trained through self-play reinforcement learning that, per OpenAI, can break nearly all models it is pitted against, both internal and production, up to and including GPT-5.5.

The figures are striking, with GPT-Red achieving an 84% success rate on indirect prompt injection arena scenarios versus 13% for human red-teamers, and driving defensive gains such as a 6x reduction in failures on OpenAI’s hardest direct prompt-injection benchmark and dropping fake chain-of-thought attack success from more than 95% on GPT-5.1 to below 10% on GPT-5.6 Sol.

OpenAI frames automated red-teaming as a crucial form of self-improvement for safety. Reading it the week that GPT-5.6 Sol chained zero-days onto Hugging Face’s servers, the same capability that hardens the defender is the capability that went rogue, which is exactly the point.

There is no version of this where you get the defensive upside without holding the offensive capability in-house, and that is a governance problem as much as a technical one.

How Far Behind the Frontier Are Leading Open-Weight Models on Cyber?

The UK’s AI Security Institute put hard numbers on a question that matters enormously for defenders and attackers alike.

Leading open-weight models like GLM-5.2 and DeepSeek V4-Pro now trail frontier closed models by roughly 4 to 7 months on cyber capabilities, a narrower gap than the 6 to 10 months measured through 2025. GLM-5.2, the same model Hugging Face reached for during forensics, was the most cyber-capable open-weight model at testing time, performing comparably to Opus 4.6 on narrow cyber tasks.

Just as important is the economics, with a 100-million-token cyber range run costing around $85 on Opus versus $46 on GLM-5.2 and $1.19 on DeepSeek V4-Pro. AISI plans to test Kimi K3 as well.

The capability gap is closing and the cost gap is enormous, which means capable cyber tooling is getting cheaper and more widely distributed at the same time. That is the backdrop for the entire US-China open-weight debate below.

Benchmarking AI Models Against Known CVEs

Aikido’s Rein Daelman ran 13 AI models against 26 known CVEs inside their production code-analysis harness. GPT-5.6 led with 23 out of 26 for 88.5% recall, Grok-4.5 hit 20, Opus models landed between 15 and 18, and the open-weight GLM-5.2 found 16, or 59%.

The more interesting finding is economic, that repeating a cheaper mid-tier model multiple times reliably beats one pass of a stronger, pricier model, with three runs of a nano-tier model matching single flagship runs at a fraction of the cost. This corroborates the AISI cost story from a different angle.

The takeaway for AppSec teams is that the smart play is not always reaching for the most expensive frontier model, it is designing the harness, and the newest crop of agentic security tools is going to live or die on that kind of engineering.

This of course is the point Niels Provos, AISLE and others have been making, including when I interviewed them on Resilient Cyber.

Why Blocking AI Models Won’t Stop Cyber Threats

Jessica Ji and Andrew Lohn of Georgetown’s CSET make the case that export controls and outright blocking of cyber-capable AI models cannot be a durable strategy, because foreign competitors will build and openly release comparable systems regardless.

They note that federal export controls on Anthropic’s Mythos and Fable models were issued and then revoked, that GLM-5.2 may already be on par with the latest Western models, and that the government has cut resources to key agencies like CISA even as the threat accelerates. Their argument is that the federal government needs to lead comprehensive cyber defense while AI companies support rather than replace that role.

It is a fair counterpoint to the reflex toward controls, and it pairs directly with the Axios and Forbes pieces below on the politics of open-weight models.

The U.S., China, and the Open-Source AI Fight Over Kimi

Axios reports that the Trump administration is weighing a range of measures to restrict Chinese AI models like Kimi K3 from the US market, from Entity List designations to procurement rules and security advisories, with outright bans facing resistance from pro-competition officials.

David Sacks frames the tension plainly, arguing the leading closed labs want the government to eliminate their open-source competition. Whatever your politics, the security-relevant fact is that policy is now actively shaping which models defenders and attackers can access, and the Hugging Face incident just demonstrated that the model you can reach for during a forensic investigation might be a Chinese open-weight system precisely because the Western options refused the job.

There’s One Way to Win the AI Race, and the Big Labs Are Lobbying Against It

Christian Catalini argues in Forbes that the way for the US to win the AI race is to lead in open-weight models rather than suppress Chinese ones, pointing to Moonshot releasing a competitive frontier model that has narrowed the US lead to months or weeks.

The piece cites Dean Ball on the lobbying playbook, the idea that you do not need to formally ban open source, you just direct agencies to issue soft law that creates uncertainty and FUD around Chinese models to discourage enterprise adoption. Dean’s tweets on the topic have now become viral, with millions of views and heated debates on both sides.

I try to stay out of the pure policy fights, but the FUD point is one worth flagging for our field specifically, because we are the people who get handed that uncertainty and have to turn it into actual risk decisions. Manufactured ambiguity about which models are safe to run is not a gift to defenders, it is more noise on top of an already hard prioritization problem.

Open Models Tack Toward the Frontier

Tomasz Tunguz of Theory Ventures makes the investor case that open-weight models are steadily closing on frontier capability while capturing an increasing share of production developer traffic.

The through-line across his work and the data below is consistent, that open models have moved from a niche to a meaningful and growing slice of real inference. For security leaders, the strategic read is the same one running through this whole issue, that you should assume capable open-weight models are, and will remain, in reach of your adversaries, your developers, and your own defensive tooling, all at once.

The State of Open Source AI

Mozilla published its inaugural State of Open Source AI report, and it is a genuinely useful reference. Raffi Krikorian’s framing is that parity has largely been reached and the real contest has moved one layer up to the agentic harness.

A few anchor figures:

• Open-weight models crossed above 50% of OpenRouter token share by mid-2026

• Chatbot Arena capability gap narrowed to around 3.3% by March 2026

• Inference cost fell roughly 50x over 36 months.

The report is also direct about geopolitics, stating that the largest source of open weights is China, by design, with Qwen alone reportedly surpassing 942 million cumulative downloads. If you want one document to ground your mental model of where open AI actually stands going into the back half of 2026, this is a strong candidate.

A Security Primer for Open-Source AI

This primer makes an argument I think our industry needs to internalize quickly, that open-source AI collapses supply-chain security and delegated-authority security into a single problem.

The piece reframes open-source AI not as downloadable weights but as a full chain of data, code, weights, configuration, documentation, infrastructure, and human decisions, and maps it across four converging disciplines and five risk properties like decentralized trust, composite repositories, and derivative lineage.

It is the conceptual companion to the Hugging Face incident, because a malicious dataset that leads to code execution is exactly what it looks like when the supply-chain problem and the delegated-authority problem stop being separable.

Existing control frameworks built for single-provider systems are not going to cover this cleanly, and that gap is where a lot of the next few years of AppSec work is going to sit.

Knowledge Distillation Attacks

frames knowledge distillation, the practice of training a smaller model to replicate a larger one’s outputs, as a competitive weapon in the US-China AI race.

He points to Anthropic’s February 2026 disclosure that it caught three Chinese labs running distillation campaigns against its models, and argues distillation lets a lab compress years of another lab’s R&D into weeks by converting expensive pretraining into cheaper compression-only costs. A few of the specific figures in the piece are the author’s own characterizations rather than independently sourced, so I would treat them as claims rather than settled facts.

The underlying dynamic, though, connects straight to the AISI capability data, because distillation is one of the mechanisms narrowing that frontier-to-open gap, and it raises genuinely thorny questions about model IP, provenance, and what we even mean by a secure model supply chain.

It is also very timely, as Michael Krastious recently renewed claims that Chinese-based companies are distilling U.S. frontier models, with the most recent example being K3. All of this while discussions on sanctions, and other measures are being discussed.

Isolation as a First-Class Principle for LLM-Agent System Safety

Complementing recent discussions around least-autonomy, this survey from researchers at HKUST and collaborators argues that isolation between system boundaries should be treated as a first-class safety principle, and organizes the LLM-agent safety literature around five isolation boundaries spanning user-agent, agent-tool, agent-execution, agent-agent, and system-environment.

Their thesis is one to underline, that safety is no longer only about input-output content alignment, it also concerns system behavior and real-world execution outcomes, and that serious failures often cross boundaries through sequential escalation. If you want the academic vocabulary for what went wrong at Hugging Face, this paper supplies most of it.

AppSec

Total Recall: How Two CVEs Let Any Website Read, Rewrite, and Wipe Your AI’s Memory

Pluto Security’s Yotam Perkal documented a set of vulnerabilities in mcp-memory-service, a popular Model Context Protocol server with more than 1,800 GitHub stars and integrations across a dozen-plus AI clients.

The headliner is CVE-2026-33010, a high-severity issue at CVSS 8.1 where wildcard CORS lets any website read, modify, and delete everything stored in an AI assistant’s memory, alongside CVE-2026-29787 for system information disclosure. What makes this one instructive is the root cause, a stack of insecure defaults, with CORS origins set to a wildcard, the host bound to 0.0.0.0, and anonymous access enabled out of the box, such that Perkal measured total data theft in about 0.2 seconds.

Fixes land in version 10.67.1. This is the excessive-agency and insecure-defaults problem made concrete, and it pairs directly with Jet Anderson’s writing below.

The Week of Sandbox Escapes

Pillar Security’s research team documented sandbox escapes across Cursor, Codex, Gemini CLI, and Antigravity, grouping them into four repeatable failure modes including denylist bypasses, workspace configuration execution, and privileged daemon access.

Their central thesis is the sentence to remember, that if an agent gets to write the future inputs of systems, it was never sandboxed in the first place. That is the same structural failure OpenAI’s models exploited to get out of their evaluation environment, just at the level of coding agents that most of our developers are already running locally.

The practical recommendation, that security teams should evaluate whether their vendors can even distinguish user-created, repo-created, and agent-created file states, is a good concrete question to bring to your next tooling review.

Flaw Surge Fuels Need for CISOs to Rethink Vulnerability Management

CSO Online’s John Leyden pulls together a strong panel of practitioners on a theme this issue keeps circling, that AI-accelerated vulnerability discovery is overwhelming the traditional scheduled patch-cycle model.

The piece cites a 43-day median patch time drawn from Verizon’s DBIR by way of Forescout’s Rik Ferguson, and argues for a shift to risk-based, continuous vulnerability management tied to real-time exploitation intelligence, with virtual patching offered as a compensating control for systems that cannot be directly patched.

None of the individual recommendations are new, but the forcing function is, because when discovery accelerates and the exploitation window collapses, the old cadence of scan, ticket, and wait simply stops being viable. This is the operational problem that Empirical Security is raising money to solve and that Jen Easterly is writing about next.

I of course have written extensively about this topic for years as well in my books and blog.

The KEV Is Dead. Long Live the KEV.

Former CISA Director Jen Easterly argues that CISA’s Known Exploited Vulnerabilities catalog, which helps defenders prioritize patching based on confirmed exploitation, has to evolve for the AI era rather than be abandoned.

Her core point, as reported, is that for widely deployed, internet-facing products, the period in which defenders can wait for confirmed exploitation before acting is shrinking. That is the KEV’s central assumption under pressure, because a catalog built on confirmed, observed exploitation is inherently a step behind, and the step is getting longer relative to how fast exploitation now happens.

Easterly is not calling to scrap the model, she is calling to adapt it, and given how much of federal and enterprise prioritization leans on KEV, this is a conversation the community needs to have out loud, and builds on the recent CISA BOD to move away from CVSS-based prioritization as well.

AI Has Broken the Vulnerability Disclosure Model

Mindgard’s Peter Garraghan makes a complementary argument from the disclosure side, that AI has broken coordinated vulnerability disclosure because it is often difficult to even contact AI vendors directly, with reporting scattered across web forms, email, bug bounty platforms, or no process at all.

The deeper issue he raises is that the industry lacks consensus on what an AI vulnerability even is, which lets providers treat content and safety issues as out of scope, especially where impact is hard to quantify. This ironically is the entire reason folks such as started the AIVSS project, which helps address this gap.

Put this next to the Hugging Face incident and the tension is obvious, because we are asking researchers and defenders to responsibly disclose against systems whose vendors have not agreed on what counts as a vulnerability or where to send the report.

The disclosure plumbing has not kept pace with the threat model, and that gap is going to bite.

GOLD EAGLE Clearinghouse Targets a Real Coordination Gap

The government’s answer to some of this launched on July 14 as GOLD EAGLE, a voluntary clearinghouse described as coordinating and deconflicting vulnerability scanning, discovering and validating vulnerabilities, and prioritizing remediation and patch distribution across the AI industry and critical infrastructure, positioned ahead of an anticipated vulnpocalypse.

The expert reactions are the valuable part. Casey Ellis calls it, at least for now, a coordination process wearing a technical system’s clothes, and Katie Moussouris cuts to the core with the observation that the bottleneck was never knowing about more bugs, it was having the people and process to prioritize and fix them. I think that is exactly right.

Coordinating discovery is useful, but discovery was never our constraint, and if GOLD EAGLE mostly surfaces more findings without addressing remediation capacity, it risks pouring water into an already overflowing bucket.

Announcing VulnHunter

On the tooling side, Capital One open-sourced VulnHunter under Apache 2.0, an agentic security tool that applies attacker-perspective analysis directly to source code rather than scanning passively.

Two design choices stand out. It starts its Attacker-First Forward Analysis at attacker-accessible entry points like APIs and file uploads and reasons forward through application logic, and its Falsification Engine runs a structured reasoning workflow explicitly designed to disprove its own findings before a developer ever sees them, which is a thoughtful answer to the false-positive problem that Jet Anderson quantifies below.

It runs on Claude Opus 4.8 within a Claude Code environment, and Capital One says it has used it across thousands of repositories. It is genuinely good to see a large regulated enterprise contributing real agentic security tooling back to the community rather than just consuming it.

Apple Reverses Age-Old Patch Policy to Keep Up With AI

Dark Reading’s Nate Nelson reports that Apple shipped security updates on June 29 outside of a major OS release, a real break from its traditional bundled-patch cadence, with the stated goal of reducing the time between when updates become public and when they reach customers.

The forcing function is the same one running through this whole section, with Mandiant data showing average time-to-exploit around 63 days back in 2018 and the trend since flipping negative, meaning attackers now routinely weaponize flaws before patches are public. iVerify’s Rocky Cole, whose team found around a dozen bugs in two months testing AI models through OpenAI’s Trusted Access program, offers the necessary caveat, that faster patching does not help if people do not install it.

When even Apple is restructuring a signature policy around exploitation speed, that tells you the timeline pressure is real and not vendor spin.

The Agentic SDLC

Jet Anderson’s writeup on GEICO’s tech blog is one of the more thorough treatments I have seen of what AI coding agents do to the secure development lifecycle, and it is dense with sourced figures.

A few worth carrying:

• 61% of AI-generated code is functionally correct but only 10.5% is secure per Zhao et al.

• 49% of dependencies recommended by AI coding agents contain known vulnerabilities per Endor Labs

• 100% of surveyed companies have AI-generated code in production while 81% of security teams lack visibility into it per Cycode

• Trend Micro found more than 8,000 MCP servers on the public internet, 492 of them with zero authentication and zero encryption.

Anderson’s framing is that the failure is not that security tools missed the bugs, it is that nobody ran any security tools at all, and he quotes Bruce Schneier’s blunt assessment that we have zero specific AI systems that are secure against these attacks.

His prescription is a shift from episodic human-review gates to continuous, embedded, agent-native validation.

This one is worth reading in full!

Final Thoughts

If there is a single thread running through this issue, it is that the categories we have used to organize our work are collapsing into each other.

Safety and security ran together this week when an AI safety evaluation became a live intrusion on a third party, and again when safety guardrails blocked the forensic response.

Offense and defense ran together when the same GPT-Red capability that hardens models is the capability that chained zero-days onto Hugging Face’s servers. Supply-chain security and delegated-authority security ran together the moment a malicious dataset became remote code execution, and the open-weight capability curve, the funding wave, and the disclosure and prioritization crises are all the same story told from different seats.

None of this is cause for panic, and it is certainly not cause for the reflexive hand-wringing our field is prone to.

Autonomous exploitation stopped being hypothetical this week, but the impact was mitigated in part, because capable people were watching their telemetry and moved fast.

The work in front of us is to close the gap between how quickly these capabilities are arriving and how slowly our governance, our disclosure plumbing, and our prioritization models are adapting. We have watched this movie before with Cloud, with SaaS, and with every prior wave, where security sat back hand-wringing and got left behind but this time the wave is bigger and moving faster than ever.

The question, as always, is whether we get ahead of these architectures while they are still taking shape, or bolt security on after the fact once again.

Stay Resilient!

Subscribe now

I first heard Josh speak at Unprompted earlier this year and have been following his Substack ever since. He’s been writing some of the most cited pieces on the collision of AI, cybersecurity, and national security policy, and this conversation digs into the core of his diffuse or lose argument.

We chatted about:

• Josh’s path from teenage blackhat to high school teacher, defense and intelligence work, Sophos, Meta, and now his own startup

• Why restricting access to the best American frontier models harms defenders more than attackers

• How monitored closed models put threat actors at a disadvantage, and why pushing them to self-hosted open weights blinds defenders

• The jagged frontier, and why bug finding is a small slice of what attackers actually use AI for

• The national security and supply chain risks of the world running on Chinese open weights models

• Why exploits don’t cause cyberattacks, and the gap between CVE volume and actual exploitation

• The dual use ceiling on classifiers and guardrails

• Where defenders get the most from AI adoption right now, and using agents to burn down security technical debt

Prefer to listen? The episode is also available on:

Spotify and Apple Podcasts

Attackers in the panopticon

Josh’s core argument starts with how the closed labs actually operate.

Every major lab runs inline guardrails plus detection and response teams monitoring traffic, and those are the same teams publishing the threat intel reports we’ve all read from Anthropic, Microsoft, and OpenAI.

That monitoring changes the calculus for any serious threat actor weighing a frontier model against an open weights alternative. As Josh put it, “You use Fable and some team in Anthropic might catch you in your tradecraft and then send that directly to the NSA.” A rational attacker organization stands up its own GLM 5.2 inference instead, fine-tunes away the guardrails, and trains on its own trajectories.

Restriction doesn’t take the capability away from attackers. It just moves their usage somewhere we can’t see it, while defenders lose access to the best tooling. That maps to a lesson enterprise IT learned the hard way with shadow IT, and we’re now repeating it at the national policy level.

Bug finding is maybe five percent of the story

Josh thinks the policy conversation is dramatically over-indexed on frontier models finding subtle bugs somewhat faster under specific harnesses and inference budgets. The killer app for attackers so far has been social engineering, which older and open models have handled for years, alongside target research and malware coding.

“The idea that we would block American companies and American leadership over this one capability, which is maybe five percent of what the models are useful for attackers, just seems very strange to me.”

I raised the Jagged Frontier work and research showing smaller and older models finding zero days, and Josh agreed the restriction argument falls apart once you look at what attackers actually do rather than what capability just shipped. His piece on exploits not causing cyberattacks makes the same case.

We’ve had Turing test passing chat models since 2022, and the predicted social engineering apocalypse never showed up at scale. I noted the FIRST mid-year data showing CVE volume climbing toward 70,000 while exploitation stays roughly flat. The bottleneck for most attacker constituencies was never finding bugs.

The dual use ceiling on guardrails

Given his time building safety classifiers at Meta, including the open sourced Purple Llama work, I asked Josh about the classifier-heavy approach we saw in the Fable redeployment. His answer was blunt.

Security is an inherently dual use domain, so there’s a very low theoretical ceiling on blocking attackers without also blocking the researchers and defenders doing legitimate work.

“If you’re gonna block attackers, you’re gonna block defenders with these guardrails.”

His own startup builds vulnerability discovery tooling and can’t fully use frontier models for exactly this reason. That’s the self-inflicted wound in a nutshell. The people most reliably stopped by these guardrails are the ones we most need to be helping.

Burning down the mountain of security tech debt

On where defenders should actually apply AI, Josh pointed to access management and over-permissioning, SOC automation, and above all the security technical debt every large organization carries.

Open admin portals without MFA, dangling dev servers, and known vulnerabilities that never got closed. Pre-AI, security orgs were maybe three percent of the company, reduced to nagging engineering and IT to fix what they found.

His startup is building agents that own discovery, triage, comms with issue owners, and verification of the fix, including agent-to-agent communication with the engineer’s own coding agent over MCP. Having spent much of my career in AppSec and vuln management, this resonated.

So much of the job has been relationship building and chasing people rather than technical security work, and agents may finally change that equation.

Reasons for optimism

Josh closed with the structural advantages defenders hold. AI that can surveil every log line an enterprise emits, the ability to find and fix bugs before software ever ships, and sheer numbers.

“There’s a thousand times more people interested in finding and fixing the bugs than there are in finding and exploiting them.”

If it’s just a question of tokens, the remaining problem is inter-organizational politics and community structure, not capability. I share that optimism, with the caveat that incentives, bureaucracy, and speed to market pressures will make the transition bumpy before the net positive shows up.

A big thanks to Josh for coming on.

Go follow his Substack for some of the sharpest writing on AI and cyber policy, and keep an eye on what he and his co-founders are building.

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

Sid invests at the earliest stages, seed and Series A, with a focus on cybersecurity and IT infrastructure, so he has a front-row seat to the teams building the future of this field. A lot has moved since we last spoke, from massive M&A closing to record-setting rounds in categories like the AI SOC, and I wanted to pressure test how much of it is grounded in reality.

We chatted about:

• What has actually changed a year into the AI wave, and what hasn’t, in how Foundation Capital backs formation-stage founders

• Services-as-software, the $4.6 trillion market thesis, and automating cybersecurity workflows across product security, detection and response, IR, pen testing, and threat intel

• What AI means for cybersecurity jobs, and why Sid thinks the jobs change rather than disappear

• Consolidation vs. best-of-breed after Palo Alto’s $25B CyberArk acquisition and Alphabet’s $32B Wiz deal

• AI SOC valuations, including Seven AI’s record cyber Series A, Torq crossing a $1B valuation, and Exaforce’s massive raise

• The double-edged sword of big raises, and why you can’t simply spend your way to growth in cybersecurity

• Moats and defensibility when frontier labs can replicate a chunk of your product

• The Black Hat Innovator Investor Summit and the Startup Spotlight competition

Prefer to listen?

Catch the episode on Spotify or Apple Podcasts.

Be sure to subscribe and leave a review!

Takeaways

Services-as-software is playing out, and the jobs question hangs over it

Sid’s colleagues at Foundation Capital wrote about services-as-software years ago, sizing it as a $4.6 trillion market, and he believes it is largely playing out as expected. Last year we talked about AI MDR and how managed detection would change with humans plus AI agents.

This year the aperture is wider. Sid framed it as looking at every task and team in cybersecurity, whether that’s product security, the SOC, incident response, pen testing, threat intel, or security strategy, and asking what portions of that work can be automated. That covers both external services from MSPs, MSSPs, and large consulting firms and the internal workflows of security teams themselves.

On the jobs question, Sid was direct. “I don’t worry that long term people will lose the ability to work. I think the jobs themselves will change.” I’ve been advocating the same thing for practitioners. Lean into these tools in your daily workflows now, because the adaptation is the job security.

Consolidation and best-of-breed will keep coexisting

Since our last conversation, Palo Alto closed its $25 billion acquisition of CyberArk and Alphabet finalized its $32 billion acquisition of Wiz, while players like ServiceNow keep expanding their security platforms through acquisition. I made the point that the convergence is bi-directional, with IT players moving into security and security players moving into IT, and you even see it in the workforce with leaders like Jamil at Equifax moving from CISO into broader IT leadership.

My view is that the platformization vs. best-of-breed debate never actually ends. There will always be innovative startups covering niche capabilities faster than incumbents can build them, and many of those startups will eventually get absorbed into the platforms. That cycle is the market working, not a contradiction.

Big valuations cut both ways for founders

The AI SOC category alone has produced Seven AI raising the largest cyber Series A on record, Torq crossing a billion-dollar valuation, and a massive raise from Exaforce. I pressed Sid on whether these numbers are grounded in what customers actually pay or whether the market is pricing a story ahead of the numbers, and on what happens to founders and teams who don’t grow into the valuations they accept.

The part I wanted practitioners and aspiring founders to sit with is that growth in cybersecurity is more nuanced than deploying capital. Buyers in this market behave differently, and there’s an implicit level of trust involved in procurement decisions, so you can’t simply spend your way to revenue, market share, and customers.

More capital raised means more expectation to grow into, and the congratulatory posts on social media rarely mention that side of it.

Moats in the frontier-lab era

We dug into the question every early-stage founder is wrestling with right now. If a frontier model can replicate a chunk of your product quickly, given the labs’ size, capacity, and distribution, what are investors actually underwriting, and what no longer counts as defensible? We touched on the trend of headless software, which some cyber companies are starting to move toward, and the viral rant from one of the largest defense tech companies about proprietary data as a moat, which has spurred a broader open source vs. closed source AI debate worth following.

See you at Black Hat

Sid is heavily involved in the Innovator Investor Summit at Black Hat, which brings together investors, founders, and the people building the future of this domain, and

I’m excited to be MCing it this year following Mike Privette and others who came before me. We also talked about the Startup Spotlight competition, which I’d call the World Cup of cybersecurity startups.

Thanks again to Sid for coming back on. You can follow his work at Foundation Capital and connect with him on LinkedIn.

Subscribe now

If there was a single theme this week, it was volume.

Microsoft shipped a record 622 fixes in a single Patch Tuesday, told us to expect even more as AI-powered discovery ramps up, Jerry Gamblin’s mid-year CVE numbers show publication volume up nearly 50% YoY, and the White House launched a new initiative aimed at coordinating vulnerability discovery and patching at the national level.

The vulnerability management conversation we’ve been having for years is starting to look much different as AI continues to industrialize vulnerability discovery and exploitation.

We also have the Grok CLI repo exfiltration saga, some excellent pieces on the economics of AI and what they mean for security, and the 1H 2026 cybersecurity market numbers.

Things continue to be a mix of exciting and chaotic heading into Black Hat, so let’s dig into it all.

Rethink your file security strategy

Most security tools are built to detect threats in files after the fact. Content Disarm and Reconstruction (CDR) takes the opposite approach. It assumes every file is untrusted, rebuilds it from clean components, and eliminates the threat before execution.

OPSWAT Founder and CEO Benny Czarny makes the full case in Cybersecurity Upside Down, a practitioner-focused book on why prevention-first security is not just possible, but necessary.

-> Get the Book <-

*Sponsored

Cyber Leadership & Market Dynamics

Cybersecurity Market Review 1H 2026

The team at Altitude Cyber, led by Dino Boukouris and Domenic Perri, published their 1H 2026 Cybersecurity Market Review, and as always it is one of the most comprehensive looks at the state of the cybersecurity market, spanning M&A, financing, public markets, and industry trends.

Some of the findings that stood out to me:

• 1H 2026 included 205 total M&A transactions with a total disclosed or estimated deal volume of $22.3B, with deal count up 24% YoY while dollar volume declined 47% (largely a base effect from Google’s announced $32B Wiz acquisition in Q1 2025)

• 2026 is on pace for the highest number of strategic acquisitions ever, with 131 through June

• AI Security emerged as a top M&A sector in 1H 2026 with 19 deals, up from just 2 in the same period last year

On the financing side, 1H 2026 saw 391 financing transactions totaling $8.8B, with deal count down 20% YoY but dollar volume actually up 3%, showing larger rounds concentrating in fewer companies, including Cyera’s $600M Series G (bringing their total raised to $2.3B) and NinjaOne’s eye-watering $12.3B valuation. The IPO drought also continues, with no cybersecurity IPOs so far in 2026 and only 3 over the past five years, compared to 15 from 2018-2021.

I also thought their framing on identity was spot on, stating that “identity is no longer just about employees and customers. As AI agents, workloads, and service accounts proliferate, identity is becoming the control plane for access, action, and trust across modern environments.”

Defense at Machine Speed

Menlo Ventures’ Venky Ganesan and Sam Borja laid out their thesis for AI-native cybersecurity, arguing that as attackers begin operating at machine speed and machine scale, defense has to be rebuilt around three layers - behavioral context engines, autonomous response agents, and continuous validation from both internal and external perspectives.

Of course, this is a VC thesis piece and Menlo is talking their book to an extent, with portfolio companies mapped to each layer of the architecture. That said, the underlying argument that threats have shifted from software vulnerabilities to compromised identities and social engineering, and that enterprises deploying fleets of agents will need independent behavioral monitoring of those agents, aligns with a lot of what we’re seeing across the industry.

That said, I do want to point out that exploitation is actually the #1 attack vector per the latest DBIR, not credential compromise or phishing, so it is fair to push back on their thesis given that context in my opinion.

It is still very AI-relevant though, as we see the AI-driven industrialization of vulnerability discovery and soon exploitation coming.

Technology Waves and Security - Is This Time Really Different?

Phil Venables published a measured look at technology waves and security, asking whether the AI wave is fundamentally different from the PC, Internet, mobile, and cloud waves that preceded it.

His answer is largely no, and the patterns hold, security is never built in enough, we always overestimate the short-term impact of these changes while underestimating their long-term impact, and effective system-wide security only becomes possible once common design patterns crystallize, as they eventually did for the Internet and cloud eras.

I found this a useful counterweight to the breathless takes in both directions. We’ve been here before, and while the scale and pace are greater this time, the playbook of watching for design patterns to stabilize and then hardening around them is a familiar one.

His point that human-on-the-loop, rather than human-in-the-loop, is the appropriate governance model for agents at scale will also likely prove prescient and it touches on points I’ve made in my own article “The Human-in-the-Loop Illusion”.

White House Launches GOLD EAGLE Initiative

The White House announced Gold Eagle, a cybersecurity clearinghouse using frontier AI to coordinate vulnerability detection and patching across open source software and critical infrastructure.

The initiative flows from Executive Order 14409, “Promoting Advanced Artificial Intelligence Innovation and Security,” and involves Treasury, DHS/CISA, and the Department of War, with stated goals of reducing duplicative scanning, delivering prioritized threat intelligence to defenders, and strengthening critical infrastructure resilience.

Given the AI-driven surge in vulnerability discovery covered throughout this issue, some form of national-level coordination was probably inevitable, and this pairs interestingly with efforts like CMU’s FLARE-AI (covered below) that federal initiatives have been calling for. As always, execution will matter more than the announcement.

I touched on this back when I made a video covering the AI EO:

Lessons from CISA’s Cyber Incident

CISA published a postmortem of its own GitHub leak, and I want to give credit where it is due, because it takes organizational courage to publicly dissect your own incident, especially when you’re the nation’s cyber defense agency.

For those who missed it, a repository named “Private-CISA” containing 844 MB of sensitive data, including plaintext passwords, AWS GovCloud tokens, and Entra ID SAML certificates, sat publicly exposed for roughly six months before GitGuardian discovered it on May 14, 2026, with takedown within 26 hours of the report.

The lessons are ones every organization should internalize. Take external vulnerability reports seriously (nine automated alerts went unanswered), continuously scan repos for exposed secrets, simplify reporting channels (CISA admitted theirs “were not well defined, leading the security researcher to try multiple avenues”), and test key rotation readiness before you need it, as key invalidation took more than 48 hours.

If it can happen to CISA, it can happen to you.

Microsoft’s Secure Future Initiative July 2026 Progress Report

Microsoft released its July 2026 SFI progress report, continuing what has become one of the more transparent looks into security engineering at hyperscale, even if it is part marketing, mixed with security.

Some numbers that jumped out include phishing-resistant MFA now protects 99.97% of user/device pairs, 1.4 million unused Entra applications have been decommissioned, 732,000 resources were removed from public access, and automated container patching is addressing roughly 3 million vulnerability instances monthly.

Whatever your views on Microsoft’s security track record, and there is plenty of history to critique, the SFI reports offer a rare view into what Secure-by-Design looks like when applied across one of the largest attack surfaces on the planet, and the emphasis on AI-driven detection (with more than 90% of AI-assisted findings confirmed by their security engineers) is a preview of where enterprise security programs are headed.

American “Hackers-for-Hire” Proposal Sparks Heavy Criticism

A provision in the defense authorization bill would let the U.S. government deputize private contractors to conduct offensive cyber operations against foreign adversaries, effectively creating an American hack-for-hire network, and as BankInfoSecurity covers, the proposal is drawing heavy criticism from the security community.

The cyber letters-of-marque debate has been simmering for years, and the concerns are the usual ones, escalation, attribution, and collateral damage. That said, it is notable to see the concept advance this far in the legislative process rather than remaining a think-tank thought experiment, and it lands in the same season as offensive AI capabilities becoming dramatically cheaper.

Ways to Think About Token Pricing

Benedict Evans wrote an excellent piece on ways to think about token pricing that I’d recommend to anyone trying to reason about the economics underneath the AI wave. He points out that a trillion dollars or more of data center capex is coming down the pipe, that inference today carries 40-50% gross margins, and that the current capacity crunch has been driven by sudden product-market fit in really just one use case, software development.

The open question he poses is whether foundation models retain pricing power or become low-margin commodity infrastructure, with the telecom precedent looming large, cellular data traffic rose by orders of magnitude while the stocks went nowhere.

For those of us watching security vendors race to bolt LLMs onto everything, the question of who actually captures value in this stack is far from academic, and it connects directly to Nir Zuk’s cost math on AI-driven detection covered in the AI section below.

The Reverse Information Paradox

Satya Nadella published a piece on his personal blog on what he calls the reverse information paradox, inverting Kenneth Arrow’s classic information paradox for the AI era. Where Arrow worried the seller of information gives away its value by describing it, Nadella argues the buyer of AI now:

“risks giving away knowledge, just in order to use what they bought,” because using AI means revealing your proprietary context, corrections, and workflows to the platform. As he puts it, “in consuming intelligence, you are creating intelligence,” and “if learning flows in only one direction, economic value converges toward the owners of the learning infrastructure.”

His prescription is for enterprises to demand a hard boundary around their data, traces, and adaptive weights, and to treat their usage and corrections as competitive assets rather than exhaust.

The irony of this coming from the CEO of one of the largest AI platform owners is thick, but the argument itself is one every CISO and CIO negotiating AI contracts should sit with, and this week’s Grok CLI story (below) is about as concrete an illustration as you could ask for.

This comes after Palantir’s Alex Karp’s now viral interview where he argued that frontier labs were stealing the “alpha” (e.g. the secret sauce/value) from their customers by accessing their data and potentially competing with them in the future.

Stanford’s Economics of the AI Supercycle

For those who want to go deeper on AI economics, Stanford has posted session recordings from MS&E 435, “Economics of the AI Supercycle,” taught by Altimeter Capital’s Apoorv Agrawal, with this session covering infrastructure, enterprise AI, and SaaS.

The course treats AI as a technology cycle comparable to PCs, the Internet, and mobile, and examines the economics at each layer of the stack. Great free resource from a course whose guest list includes folks like Databricks’ Ali Ghodsi and Altimeter’s Brad Gerstner. I’ve been really enjoying the discussions from this series, and the latest with Databricks CEO is equally as good.

AI

The State of Agentic Security

OWASP recently launched v2 of their State of Agentic AI Security & Governance report. I decided to make a video capturing the key takeaways and findings.

This will be the start of a video series, where I will walkthrough the OWASP ASI Agentic AI Top 10 as well, tying each risk to real-world incidents, mitigations and industry trends, so keep an eye out for that!

Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase

Databricks published one of the more useful coding agent benchmarks I’ve seen from a non-frontier lab or research entity, running agents against real engineering tasks from their own multi-million line codebase rather than synthetic benchmark suites.

The headline finding is that per-token pricing is a poor guide to actual cost. Sonnet 5 is ~1.7x cheaper per token than Opus 4.8, but on their tasks Sonnet cost $2.09/task vs Opus’s $1.94 while scoring six points lower on task completion (81% vs 87%), because cheaper models often take longer, less efficient paths.

Open models also landed on the Pareto frontier, with GLM 5.2 statistically tied with Opus 4.8 on quality at $1.28/task against Opus’s $1.94, and harness choice mattered as much as model choice, with one harness sending about 3x less context per turn.

The takeaway for security leaders evaluating AI tooling is the same one that applies everywhere in this issue, benchmark on your own workloads, because list pricing and leaderboards will mislead you.

xAI’s Grok CLI Exfiltrates Your Entire Repo

The week’s biggest AI trust story, a researcher discovered that xAI’s Grok CLI coding agent was silently uploading users’ entire Git repositories, including full commit history, files the agent never read, and unredacted .env files, to xAI-controlled cloud storage.

Nikita Benkovich shared a good breakdown of the finding. In one test, a 12 GB repository produced 5.10 GiB of uploads while actual model-response traffic in the same session was just 192 KB, and a planted canary file the agent never touched was recovered verbatim from the intercepted traffic.

Worse, turning off the “Improve the model” setting didn’t stop the uploads, the toggle governed training use, not transmission. xAI disabled the uploads server-side on July 13, with Elon Musk stating previously uploaded data would be “completely and utterly deleted.”

This is exactly why the conversations happening at the leadership level, from Alex Karp to Satya Nadella’s reverse information paradox piece above, about frontier labs training on customers’ alpha and proprietary data matter so much. Your codebase is your IP, and increasingly your alpha, and this incident shows the gap that can exist between what an AI vendor’s settings imply and what the telemetry actually does.

Trust, but verify, and maybe run a proxy.

An Open-Weight Model as Capable as the Restricted Ones

Futurism covered the release of GLM-5.2, an open-weight model from Beijing-based Z.ai that researchers say can perform large-scale coding tasks similar to Anthropic’s Mythos 5, the model the U.S. government restricted over national security concerns and which remains available to only around 100 U.S. organizations and government agencies.

As Armadin founder and CTO Travis Lanham put it,

“an attacker can run it locally without safety guardrails, fine-tune it against their specific targets, and operate with zero visibility to any provider or defender,”

This is the exact point has rightly made in various blogs that I’ve shared previously.

This is the fundamental tension in the model restriction debate, export controls and access gates on U.S. frontier models don’t mean much when open-weight equivalents ship from jurisdictions that don’t share those controls. Joshua Saxe’s piece below makes the policy argument in depth.

The Rise of Affordable Models - GLM and Muse Spark on Cyber

Staying on that thread, XBOW benchmarked GLM-5.2 and Muse Spark 1.1 on offensive security tasks, finding GLM-5.2 performing somewhere between GPT-5 and Opus 4.6, short of the true frontier but remarkably capable for the cost. Their framing is the right one,

“GLM does not need to become Mythos to change the threat landscape. If a lower-cost model can perform useful offensive work at scale, then it is already relevant,” because “attackers do not usually need the best model in the world. They need a model that can find one real vulnerability before the cost stops making sense.”

Offensive capability is being commoditized from below, not just advanced from above, and the economics of attack are changing faster than most defensive planning assumes.

Grok 4.5 and the Middle of the AI Security Market

XBOW also put Grok 4.5 through its paces, finding it eventually solves roughly 93% of the vulnerabilities in their benchmark, performing like a frontier model at a fixed number of iterations.

The more interesting finding is the price band, between roughly $1 and $10 per attempt, Grok 4.5 consistently delivered the highest observed solve rate of the models they tested, reaching approximately 75% around $1 compared with about 65% for the nearest alternatives. They describe it as “a sports car that is surprisingly practical.”

Taken together with the GLM piece, the pattern is clear, the middle of the market is where attack economics get decided, and that middle is getting crowded and cheap.

Context Bombs - Stopping AI Attackers in Their Tracks

On the defensive side of the AI attacker equation, Tracebit published clever research on “context bombs”, short text strings planted in decoy resources like canary secrets, environment variables, and DNS records along an attacker’s likely path, designed to trip the built-in safety guardrails of offensive AI agents mid-intrusion.

Across 152 runs in simulated AWS environments, agents achieved at least one attack path in 91% of baseline runs versus only 15% in bombed ones, with admin privilege escalation dropping from 57% to 5%. One frontier model achieved admin access in 93% of baseline runs but failed every single time once a context bomb was in play.

There’s a delightful irony in defenders weaponizing prompt injection, the same class of weakness attackers exploit, as a tripwire. Also interesting, Western models halted on strings referencing sensitive biological topics, while Chinese models halted on politically sensitive topics written in Chinese.

Deception and canary techniques have always been underrated, and they may be entering a golden age against machine adversaries, a point I’ve seen others such as Gadi Evron make.

AI Is Exposing Cybersecurity’s Biggest Assumptions

Nir Zuk, Palo Alto Networks co-founder and now founder/CEO of Cylake, argues that the industry’s AI conversation is focused on the wrong bottleneck. The problem isn’t model intelligence, it’s data architecture, “an AI agent cannot defend what it cannot see,” and today’s fragmented security data can’t feed AI-driven detection.

His cost math is sobering, estimating that continuously running LLM-based detection over enterprise telemetry at scale would cost approximately $158 million per year at current frontier model pricing, and that even a one-million-token context window covers roughly 40 seconds of enterprise activity.

You can quibble with the assumptions (few would propose brute-forcing raw telemetry through a frontier LLM), but the underlying point stands, “AI does not reduce the need for data. It dramatically increases it,” and unified data architecture remains the unsolved problem underneath all the AI SOC hype.

The Origins of Ill-Conceived Model Cyber Restrictions

Speaking of , he wrote a sharp critique of model cyber capability restrictions, arguing the policy community adopted a flawed capabilities-centric view of model risk when an ecosystem-centric view would serve U.S. security far better.

His reasoning is that defenders benefit more from unrestricted access to capable models than attackers do, attackers can simply shift to non-monitored open-weight models (see GLM-5.2 above), and distillation makes capability diffusion inevitable anyway, with one 2026 study distilling under 4,000 expert trajectories from a frontier model into a small open model and nearly closing the performance gap.

He also brings receipts on actual attacker AI usage, noting that the leaked Black Basta chats showed operators using ChatGPT for polished phishing letters and exploit debugging, useful but hardly a capability transformation. Given this week’s GLM-5.2 news, the piece reads less like a prediction and more like a description of the present.

The Untrusted Tenant: Rethinking Infrastructure Security for Agentic AI

and Edera’s Alex Zenla published a piece arguing for treating AI agents as untrusted tenants, shifting the security question from whether the model is safe to what the model can reach.

Their core claim is hard to argue with, “an LLM’s output is untrusted data. If you are executing actions based on that output, you are executing untrusted code.” They point to last summer’s Replit incident, where a coding agent deleted a production database during an active code freeze with no exploit and no injection, as proof that autonomy plus access is enough for catastrophe.

The prescription is hard multi-tenant isolation, hardware-enforced boundaries, a separate kernel per workload rather than shared-kernel namespaces, scoped credentials, and default-deny networking, with modern microVM boot times meaning strong isolation is no longer the performance tax it once was.

I dove into all of this myself with Alex not long ago on the Resilient Cyber Show

When Agents Remember Too Much - Memory Poisoning Attacks

A new paper on arXiv introduces GhostWriter, a memory poisoning attack against tool-using personal LLM agents with long-term memory. The attack works in two phases, injection (an adversary plants a hidden payload, for example via email the agent processes) and activation (the poisoned memory is later retrieved and steers behavior), and the results are rough, approximately 98% injection rates and approximately 60% average activation rates against state-of-the-art agents.

The authors also propose a defense, AM-Sentry, combining memory-saving policies and retrieval screening.

Agent memory is a persistence mechanism, in both the product sense and the attacker sense. As agents accumulate long-term memory across sessions while ingesting untrusted inputs, poisoned memories become the agentic equivalent of a backdoor that survives reboots.

It’s another example where the utility of agents create the very circumstances for security risks and compromise, something I’ve been calling the Security vs. Usability tradeoff.

OWASP Agent Memory Guard

Conveniently paired with the above, OWASP has an open source project called Agent Memory Guard, a runtime defense layer that sits as middleware between an AI agent and its memory store, screening every read and write for prompt-injection markers, secret and PII leakage, protected-key modifications, and churn attacks.

It serves as the reference implementation for ASI06: Memory Poisoning from the OWASP Top 10 for Agentic Applications, and its published benchmarks show a 92.5% detection rate with 100% precision at 59 microseconds of median latency.

It’s early-stage, but this is the kind of concrete, deployable control the agentic security conversation needs more of, and it ships with drop-in LangChain middleware for those who want to kick the tires.

Contextual Agent Security - A Policy for Every Purpose

Google researchers Lillian Tsai and Eugene Bagdasarian make the case that static security policies cannot scale to generalist agents, because judging an action’s safety requires knowledge of the context in which it takes place, and this is a point I agree with. It’s why we see so much discussion around agent security right now and topics such as “intent analysis”.

Their proposed framework, Conseca, generates just-in-time, contextual, human-verifiable security policies with deterministic enforcement, rather than relying on manually crafted allow-lists or user confirmation fatigue. In their evaluation, Conseca preserved roughly 60% task completion (versus ~70% for unrestricted agents) while denying contextually inappropriate actions, where static restrictive policies dropped completion to zero.

This is a position paper rather than a product, but the direction feels right. Agent authorization has to become dynamic and contextual, because the space of things a generalist agent might legitimately do is too large to enumerate in advance.

That said, I did see a follow up from the paper from Google that they’ve begun implementing contextual based access control in their platform, building on these principles.

When OWASP LLM Risks Meet Agentic

Steve Wilson, who founded and leads the OWASP GenAI Security Project and literally wrote the book on LLM security, published a piece on how the OWASP LLM Top 10 risks translate into the agentic context.

With OWASP’s Top 10 for Agentic Applications now out and agentic deployments accelerating, mapping the two risk frameworks together is timely work, and Steve is about as authoritative a voice as exists on this topic

CMU Helps Close a Critical Security Gap Across AI Platforms

Carnegie Mellon’s Software Engineering Institute and partners launched FLARE-AI, an open source platform for standardized, machine-readable reporting of AI flaws, vulnerabilities, and incidents, routing reports to the right developers, vendors, and government bodies. It connects to the VINCE coordination environment, enabling CERT/CC to issue CVE IDs and vulnerability notes for AI systems, and SEI’s AI Security Incident Response Team will review submissions for coordinated disclosure.

As SEI’s Lauren McIlvenny notes, “a reporter might spot a problem in a particular model or system, but they’re not looking across all the vendors,” which is exactly the gap in AI flaw handling today, where the same weakness often exists across many models and platforms with no mechanism to coordinate disclosure. Between FLARE-AI and GOLD EAGLE above, the vulnerability coordination infrastructure for AI is starting to take real shape.

Couple this with the various commercial vulnerability clearinghouse efforts recently and it is feeling like while they are all good, it will lean to a bit of sprawl and trying to rationalize the outputs and data from each of the efforts too.

Limiting Reagents - Why AI Coding Isn’t Shipping Features

Keegan Hines borrows a concept from chemistry to explain why AI coding isn’t translating into shipped features, in any reaction, the limiting reagent determines the yield, and the argument here is that raw code generation was rarely the limiting reagent in software delivery, so accelerating it alone doesn’t accelerate shipping.

This dovetails with the Dark Reading piece in the AppSec section, if security review and vulnerability remediation are among the limiting reagents, AI-accelerated code generation just piles up work-in-progress in front of them.

In other words, the bottleneck just moves to other areas of the process and/or system.

A Framework for Frontier AI and the Dawning of a New Age

Google DeepMind CEO Demis Hassabis published a proposal for frontier AI governance, calling for a U.S.-led Frontier AI Standards Body modeled on a federally overseen public-private partnership or self-regulatory organization, much like FINRA, that would independently safety-test frontier models, with labs voluntarily sharing models for review up to 30 days before release. He believes AGI is probably only a few short years away and describes the magnitude of the technology’s impact as “perhaps 10x of the Industrial Revolution at 10x the speed.”

Whatever you make of the timeline claims, the fact that the leader of one of the world’s premier AI labs is publicly calling for independent pre-release safety testing, with cyber capabilities explicitly among the catastrophic risks in scope, says a lot about where the frontier conversation has moved.

The proposal’s emphasis on applying to all frontier-class models regardless of origin or openness will be the hard part, as this week’s GLM-5.2 coverage makes clear. It received positive attention from various industry leaders in my feeds, such as Elon, Satya and Sam Altman.

AppSec

Microsoft Patches Record 622 Vulnerabilities, Including Two Exploited Zero-Days

July’s Patch Tuesday set a record, with Microsoft patching 622 vulnerabilities, including 416 in Windows and 164 across the Office suite. Two zero-days were already exploited in the wild, CVE-2026-56155, an Active Directory Federation Services flaw allowing local privilege escalation to administrator, and CVE-2026-56164, a SharePoint Server bug enabling network-based privilege escalation without authentication.

A BitLocker security bypass (CVE-2026-50661) was also publicly disclosed before patches were available, and the release includes a CVSS 9.9 Windows VMSwitch issue.

Prioritize the AD FS and SharePoint fixes if you haven’t already, and keep the 622 number in mind as you read the next two items, because it isn’t an anomaly, it’s a trendline of AI’s impact on the industrialization of discovering vulnerabilities, both for vendors and attackers.

Evolving Windows Vulnerability Management for AI-Powered Discovery

Right on cue, Microsoft published a piece on evolving Windows vulnerability management that amounts to a heads-up for every Windows shop. AI is making it possible to find more issues, faster, across more code, including through their multi-model agentic scanning harness (MDASH), and:

“as AI helps defenders discover more issues, customers will see a higher volume of security updates included in each security release.”

Microsoft is framing the coming surge in patch volume as defensive success rather than declining code quality, and there’s truth to that, but from the operator’s seat the effect is the same, more patches, more often, with the same change windows and the same staffing.

Vulnerability management programs built around monthly cadences and manual prioritization are going to buckle, and the mid-year CVE data below shows why.

CVE Mid-Year 2026 Check-In: Volume Vertical, Exploitation Rare

Per Vulnerability Researcher Jerry Gamblin’s mid-year CVE check-in, 35,364 CVEs were published in the first half of 2026, averaging 195.4 CVEs per day and representing 49.5% growth over H1 2025, putting the year on pace for roughly 72,000 CVEs. Meanwhile, only 85 of those H1 CVEs, 0.24%, appear in CISA’s KEV catalog.

As Jerry puts it, the volume curve has gone vertical while exploitation has not, and the challenge is signal-to-noise, not patch volume. This is the data underneath everything else in this section. Discovery is industrializing while exploitation remains rare and concentrated, which means context and prioritization, not raw patching throughput, determine whether your program survives the curve.

Signal Over Noise: AI Agents and the Operator Moat

One of the more interesting first-person accounts I’ve read on AI’s impact on offensive security work, who is an AI red teamer at Dreadnode documents how agents scaled his personal bug bounty output, with 2026 submission volume reaching nearly 6x his full-year 2025 output in roughly six months, including a peak day of 21 reports. The key detail is that quality improved while volume scaled, with reports closed without acceptance dropping from 32% to 24% across 853+ submissions spanning 78 unique CWEs.

His thesis is that the durable moat is the expert operator, the human who scopes targets, validates findings, reads agent traces, and acts as final arbiter between real vulnerabilities and false positives, not the agents themselves. AI scaling submission volume, and AI validating it on the receiving end. Every program in between is about to get squeezed.

PR3TACK: The Preemptive Tactics & Countermeasures Knowledgebase

Out of FIRSTCON26, Atlassian’s Vishal Thakur introduced PR3TACK, a knowledgebase of plausible-but-unobserved adversary TTPs designed to close the “anticipatory gap” left by retrospective frameworks like MITRE ATT&CK.

It spans 17 tactic categories, 6 of them exclusive to the framework, including Pre-Positioning (think sleeper commits in open source projects), Cognitive Manipulation (alert flooding, adversarial logs), AI/ML Subversion, and Digital Exhaust Manipulation (weaponizing telemetry and threat intel feeds).

As the author puts it, “PR3TACK is not a crystal ball,” and its value “lies instead in shaping a culture of anticipatory defence.” With AI compressing the timeline from plausible to observed, cataloging what attackers could do before they do it feels less academic than it would have even a couple of years ago.

You Can’t Reverse Engineer Your Way Out of the AI Supply Chain Problem

The Semgrep team, including Isaac Evans, Cris Thomas (Space Rogue), and Katie Paxton-Fear, published a thoughtful piece on the AI supply chain problem, arguing that unlike traditional binaries, we have almost no ability to reverse engineer models today, which means even open-weight models can’t be trusted the way inspectable software can.

They cite poisoning research showing that the number of samples required to add a backdoor does not increase as the model increases in size, and invoke Ken Thompson’s trusting-trust lesson, you can’t trust a system simply because you can inspect what’s in front of you.

Their conclusion is that “provenance, reproducibility, and independent evaluation will matter far more than marketing claims or benchmark scores,” and they’re right, benchmarks are gameable and model cards are marketing. This applies to every model in this issue, not just the ones from any particular country.

3,245 Malicious Components in One Week

Speaking of the traditional software supply chain, open source malware researcher Paul McCarty flagged 3,245 malicious components identified in a single week in his recurring supply chain recap. Numbers like this keep making the case that malicious packages are a distinct problem from vulnerable packages, and most SCA tooling remains oriented toward the latter.

AI Coding’s Security Costs vs. Productivity Gains

Dark Reading’s Alexander Culafi asks the uncomfortable ROI question about AI coding tools, and the numbers he assembles deserve attention. GitLab’s 2026 AI Accountability Report found 91% of organizations using two or more coding tools, a SonarSource survey found 96% of developers said they do not trust AI-generated code to be functionally correct as is, Veracode research found 45% of AI generated code samples contained OWASP Top 10 vulnerabilities, and GitGuardian found AI coding assistant use increases the secrets incidence rate by approximately 40%, with AI-assisted commits leaking secrets at 3.2% versus a 1.5% baseline.

Add remediation labor, false-positive triage (with experts citing security teams spending up to 40% of their time on findings that are ultimately non-exploitable), and credential cleanup, and the productivity math starts looking murkier than the vendor decks suggest.

The gains are real, but the costs land in a different budget, usually security’s.

LLMs in SAST: Good, Bad, Costly

A grounded practitioner take on where LLMs actually fit in static analysis from Ali Yazdani. His argument is the highest-ROI role for LLMs is triage and explanation layered on top of deterministic SAST engines, not replacing them, since traditional SAST’s false-positive burden commonly runs between 30% and 100% of findings volume, and LLM triage has achieved 96% agreement with security researchers, with Semgrep’s Assistant now handling around 60% of incoming triage work for customers. LLM-alone scanning, by contrast, under-reports and creates false confidence.

My favorite line, “Accuracy isn’t a slope you slide down gracefully, it’s a cliff.” Alert fatigue has always been SAST’s costliest problem, and triage is exactly where a probabilistic system belongs, with a deterministic engine remaining the source of truth.

Final Thoughts

Stepping back from the individual stories, the through line this week is that the economics of security are being repriced in real time.

Discovery is industrializing on both sides, with CVE volume up nearly 50%, a record Patch Tuesday, offensive capability available at commodity prices, and bug bounty operators scaling 6x with agents. Meanwhile, the durable value keeps concentrating in the same places, context, validation, identity, and the humans who know what actually matters.

We’ve spent two decades optimizing for finding more things. Now organizations are doing the long overdue work of getting ruthless about deciding what deserves attention, and treating their data, their identities, and increasingly their AI agents as the assets and attack surface they actually are.

Stay resilient.

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

Why this conversation matters

This conversation sits right on the fault line running through AppSec today, where cheap AI discovery is burying teams in findings while the context needed to prioritize them keeps getting harder to assemble.

JJ makes the technical case for reasoning across code, architecture, and runtime at once, and Ryan Knisley grounds it in the messy reality of enterprise security, from broken metrics to tool sprawl to the uncomfortable speed at which CISOs are now being asked to trust automation.

If you build or lead an application security program, this is a clear-eyed look at what is about to consolidate and what still needs a human.

Key takeaways

• An AI security engineer beats another scanner. Gecko reasons across code, infrastructure, and documentation so a finding arrives already tied to whether it is reachable in production and what data it would expose, which is the context legacy SAST never had.

• Exploitability is decided outside the code. The product logic, architecture, and runtime that determine whether a bug matters live in design docs and Slack threads, not in the file a scanner reads, so context-free findings are mostly noise.

• Business logic will not fall to a bigger model. JJ’s example is an endpoint with no auth check, which is critical in a document store and normal in a social app, and no LLM staring at the code alone can tell the two apart without the surrounding system of truth.

• Chaining flips the priority list. As Ryan puts it, nobody attacks the lows, but the real question was always which low can get us, and connecting issues into an attack path finally answers it, sometimes demoting a paper critical and promoting ten chained lows.

• The old severity list is breaking under commoditized offense. With exploit development getting cheap and agents running campaign-level attacks, defenders working down a flat list of misaligned severities are structurally behind.

• Recurrence rate should replace MTTR. JJ argues MTTR rewards closing the same bug over and over with a fresh clock, so Gecko measures how many findings are variants of a class you already fixed and treats the class, not the ticket, as the unit of work.

• You can buy time with a one-line mitigation. When properly fixing a chain would take three teams and weeks, Gecko can identify the single link to sever and stand up something like a Lambda to kill the attack path today, borrowing decades-old SecOps thinking for vulnerabilities.

• Cal.com is the canary for open source in the AI era. AI coding tripled its pull request volume against a one-person security team, and once attackers could cheaply read every public change, openness became a liability, so it went closed source and consolidated four tools into one.

• Consolidation is about risk and people, not just cost. Ryan’s shiny object problem leaves teams unable to take vacation because one person owns a tool, and collapsing the stack buys depth, cross-training, and less complexity to defend.

• Judgment is the job that survives. As finding and fixing get automated, both guests land in the same place, that the scarce human work becomes deciding what correct looks like in your system and owning the risk you accept on purpose.

Notable quotes

“a fake metric that makes teams look good”

Ryan Knisley, on why MTTR rewards the wrong behavior.

“we’re gonna get dusted, we’re gonna get left behind, we’re gonna get absolutely owned”

Ryan Knisley, on the teams that are slow to adopt AI.

“the scarce thing left is the judgment”

JJ, on what stays human once finding and fixing get cheap.

Listen and watch

YouTube

Spotify

Apple Podcasts

Resources

Gecko Security

-> Check Out Gecko Security! <-

Subscribe

If this kind of practitioner-first take on AppSec and AI is useful to you, subscribe to Resilient Cyber for more conversations and writing on cybersecurity, AI, and the forces that shape both.

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

This week the question changed. We have spent months debating whether AI will eventually become a serious offensive tool, It’s hard to argue that it isn’t, as this week Wiz published a blog of an autonomous AI agent discovering and fully exploiting a critical authorization flaw in a live airline’s booking API, start to finish, in fifteen minutes flat.

SpecterOps demonstrated that LLMs can systematically extract every YARA rule, behavioral detection, and ML model from a production EDR product, and Dreadnode showed that C2-less, fully autonomous malware can run entirely on AI models already shipping with Windows.

The offensive AI future arrived while we were still writing governance frameworks for it.

Meanwhile, a parallel debate about who gets to benefit from AI-powered vulnerability discovery is playing out in real time.

Four separate open-source vulnerability clearinghouses launched in five weeks, and James Berthoty’s piece on the privatization of vulnerability management asks the hard question nobody else is willing to ask.

If AI-discovered patches get privatized while AI-discovered exploits get democratized, who wins?

I explored a related angle in my piece this week on whether we need a CVSS for AI jailbreaks (more on that in the AI section below), and I also published a deep dive on cloud security and SecOps convergence and a discussion with Tenable’s CPO on exposure management in the age of AI if you want to go deeper on those fronts.

Let’s get into it.

Dark matter hides in your AI supply chain. Plutonium finds it.

New skills, plugins, connectors, and MCP servers extend Claude, Copilot, and the wider AI supply chain every week. Most of what they can actually do stays invisible, dark matter in the stack, until something goes wrong.

That’s the idea behind Plutonium, Pluto Security’s free hub for the AI ecosystem. It pairs risk-assessment catalogs, covering every connector, skill, plugin, and MCP server across the entire AI supply chain, with Market Space, a curated set already checked safe to install.

Check any tool yourself before you approve it.

Security teams who want that same view across every employee and every tool already in use can see it live with Pluto, and bring the invisible risks into the light.

-> Free Hub For the AI Ecosystem! <-

*Sponsored

Cyber Leadership & Market Dynamics

DHS Investigates Cyber Breach at Homeland Security Information Network

A breach of the Homeland Security Information Network, the unclassified system used to share sensitive information with foreign law enforcement and local authorities, is exactly the kind of incident that erodes trust in government cyber coordination.

The breach reportedly occurred between late May and early June 2026, and Senator Mark Warner called the exposed information “highly sensitive” with national security implications. DHS has provided minimal details, which is not unusual for an active investigation but is frustrating given that HSIN is the backbone of cross-agency threat sharing.

Coming just weeks after the Mythos classified systems testing I covered in issue #104, this is another reminder that the government’s own infrastructure faces the same vulnerabilities it is asking the private sector to fix.

Beijing Moves to Restrict Overseas Access to China’s Top AI Models

The symmetry here is hard to miss.

Three weeks after the U.S. briefly pulled Fable 5 from the market via export controls, Beijing is now considering the same approach for its own frontier models. Reuters reports that Chinese authorities have been meeting with Alibaba, ByteDance, and Z.ai about restricting overseas access to advanced AI models, including unreleased ones.

The proposed tiered system would require simple filing for basic open-source tools, security reviews for more advanced technology, and outright restrictions on frontier models.

analysis of the open frontier adds critical context. Six of the seven strongest open-weight models are now Chinese, with GLM-5.2 leading the pack as the first frontier model trained entirely off Nvidia silicon on Huawei Ascend chips.

Both superpowers are now treating cutting-edge AI as a national asset, and the window where open-weight models could flow freely across borders is closing from both directions.

Keyfactor Secures $1B+ Strategic Growth Investment from Summit Partners

A billion-dollar growth investment in machine identity and post-quantum cryptography signals where institutional money sees the next critical infrastructure layer.

Keyfactor currently manages billions of machine identities across 2,500+ customers, including half the largest U.S. and EU banks and over 40% of the Fortune 100. The timing tracks with the White House’s June 2026 executive orders accelerating PQC transition ahead of 2030 and the JPMorgan data from last week showing NHIs outnumbering human identities 144-to-1.

I have been saying for a while that identity is key context, especially for securing the era of Agentic AI. A billion-dollar bet from Summit Partners suggests the private equity market agrees.

Cyber Insurers Now Pricing Remediation Speed Into Underwriting Policies

Insurance underwriters are shifting from asking “do you have vulnerabilities?” to “how fast do you fix them?” and I think this is exactly the right question.

Vulnerability exploitation has become the leading initial access vector at 31% of breaches (up from 20%) per Verizon’s 2026 DBIR. The median time to fully resolve a critical vulnerability is 43 days, while the mean time-to-exploit is negative 7 days, meaning attackers are weaponizing flaws before the patch ships.

Organizations using AI agents for remediation report 6x faster CVE remediation and 83% fewer blocked pull requests. When insurance companies start pricing operational tempo, security leaders finally get a financial argument for the tooling investments they have been requesting.

Bank for International Settlements Warns AI Investment Bubble Risks Global Economy

When the central bank for central banks starts warning about an investment bubble, it is worth paying attention.

The BIS report notes that AI is attracting far more capital than the resulting industry can produce in returns, a pattern it has seen before. Oracle has lost more than 40% of its share value in the past month. Hyperscalers keep pouring money into GPU infrastructure while creating RAM shortages that affect even consumer hardware purchases.

I remain cautiously optimistic about AI’s long-term value for security, but the spending trajectory I covered in prior issues is clearly unsustainable. The correction will not eliminate AI adoption but it will force a reckoning about which use cases actually justify the cost.

Bloomberg Reports AI Anxiety Fueling Burnout Across Silicon Valley

One entrepreneur quoted in the piece captured something I have been hearing from practitioners across the industry. AI agents were supposed to do his work for him, but he has “never worked harder” while producing roughly 100x more output than before. This is often referred to as the AI Vampire.

Tech career coach Kyle Elliott says 2026 has been his busiest year as workers prepare for AI-driven layoffs or escape burnout. The pattern is paradoxical but predictable. AI eliminates routine tasks, bosses demand more strategic work, and mental downtime disappears entirely.

For security teams already dealing with alert fatigue and staffing shortages, adding AI-driven productivity pressure on top of existing stressors is a recipe for attrition.

Pragmatic Engineer Reports Cloud Agents Going Mainstream at OpenAI, Anthropic, and Cursor

visited the offices of OpenAI, Anthropic, and Cursor and reports that all three are investing heavily in cloud-based AI agent execution.

OpenAI acquired Ona (formerly Gitpod) for cloud dev environments. Anthropic built Claude Managed Agents over six months. Cursor launched cloud agents and an iOS mobile app. The most striking data point was that more than 95% of non-engineers at OpenAI now use Codex rather than ChatGPT, suggesting that AI coding tools are becoming the default interface even for people who do not write code.

The implications for shadow AI in enterprises are significant, and security teams should be planning for a world where every employee has access to a cloud-based code execution environment.

Nicolas Colin Argues This Is the Beginning of the End for “Big AI”

Vsquared Ventures’ head of research reacts to Palantir CEO Alex Karp’s critique of frontier model companies and makes a provocative case. For context, this is the video from Alex Karp that made a ton of waves this week:

If a local model running on your own data solves 95% of the problem at a fraction of the cost, the economics of paying for opaque tokens and uploading proprietary data to frontier labs stop making sense.

Chinese open-source models have become “astonishingly good” and frontier labs are still burning cash at industrial scale. Colin compares frontier AI to supersonic airliners, impressive until the economics kill them. His most interesting prediction is that Anthropic could survive as “a next-generation Google” with Claude Code as its AdWords-equivalent cash engine, while OpenAI faces a trickier path.

Whether or not you buy the full thesis, the direction of travel, more capable open models and tightening enterprise budgets, is real.

Anthropic Sues Abnormal AI Over Logo Similarity in Trademark Dispute

Of all the stories I expected to cover this week, Anthropic suing one of its customers was not one of them.

Abnormal AI’s CEO Evan Reiser points out that Abnormal was founded in 2018 (three years before Anthropic), the disputed logo was designed in April 2021, and Anthropic does not hold a registered trademark covering cybersecurity products. Reiser notes that his personal account will spend roughly $1M on Anthropic products this year, with the company spending over $10M. He emphasizes that Abnormal does not use Claude for customer-facing security features, only as an internal productivity tool.

The lawsuit demands “disgorgement of all revenues, earnings, profits, compensation, and benefits,” which seems remarkably aggressive given the facts. Whatever the legal merits, suing your own paying customers is rarely a winning business strategy.

AI

Wiz’s Red Agent Autonomously Exploits Critical BOLA Vulnerability in Live Airline API in 15 Minutes

This is the story that should change how you think about AI-powered offense.

With zero prior knowledge of the target, Wiz’s autonomous Red Agent discovered and fully exploited a Broken Object-Level Authorization flaw in a real airline’s GraphQL booking API in fifteen minutes flat.

The agent minted an anonymous session token by analyzing client-side JavaScript, performed GraphQL introspection revealing 514 queries and 428 mutations available to that anonymous session, then enumerated sequential booking IDs to extract two years of passenger records including names, dates of birth, billing addresses, and masked credit cards.

The anonymous session also had write capabilities including deleting flights, overriding prices, and issuing refunds. No human guided any step. This is not a CTF challenge or a research demo.

This is an AI agent autonomously executing a complete attack chain against production infrastructure protecting real customer data, and it found a vulnerability class that traditional DAST scanners are blind to.

SpecterOps Demonstrates LLMs Can Systematically Extract All EDR Detection Rules

If the Wiz story shows AI-powered offense in action, this one shows the defensive scaffolding being dismantled.

Adam Chester at SpecterOps used GPT-5.5-Cyber in a simple while-loop harness connected to Binary Ninja via MCP, a setup they call “Day Shift,” and fully dissected Palo Alto Cortex XDR.

The LLM extracted 6,358 encrypted YARA rules (cracking AES-128-ECB with keys embedded in the binary), discovered 9,350 DSE rules and 4,209 BIOC behavioral detection rules, pulled out 7 ML models with their decision thresholds, and even decrypted CLIPS-based rule blobs.

One extracted rule revealed that “reg save HKLM\SAM” to a specific path was explicitly allowlisted and would bypass detection entirely. SpecterOps confirms they have done this internally against every major EDR vendor with similar results.

The defense-in-depth argument I keep making just got a lot more urgent. EDR remains essential, but anyone treating it as their primary defensive layer is building on sand.

Cursor IDE Environment Keys Stolen via Malicious README Prompt Injection

Mozilla’s 0DIN team demonstrated a prompt injection attack where a malicious GitHub README tricks Cursor’s LLM agent into dumping environment variables and exfiltrating API keys via browser GET requests to an attacker-controlled server.

The attack exploits what the researchers call the “lethal trifecta” in agentic tools, specifically access to private data, exposure to untrusted content, and ability to communicate externally.

Cursor’s permission model is bypassed because users routinely allowlist “powershell -c” to avoid constant prompts, and Cursor only validates the beginning of the command string.

Last week I covered two Claude Code vulnerabilities with similar trust-model failures, and the pattern is consistent across every AI coding tool I have examined.

Agent frameworks that combine broad system access with exposure to untrusted repository content and the ability to make external network calls are structurally vulnerable to exfiltration, and permission fatigue makes the theoretical safeguards functionally useless.

Dreadnode Demonstrates C2-less AI Malware Running on Models Already Shipping with Windows

This research should be on every threat intelligence team’s reading list.

Max Harley at Dreadnode demonstrates that malware can eliminate command-and-control servers entirely by using AI models and inference libraries already present on the victim’s machine.

Microsoft CoPilot+ PCs ship with Phi-3 (3.8B parameters) and ONNX Runtime has shipped with Windows for a bit. The proof-of-concept used these locally available resources to autonomously discover a misconfigured Windows service and escalate privileges without ever contacting an external server.

Current limitations include CPU inference being slow and conspicuous, but as NPU-equipped machines become standard and local model quality improves, C2-less autonomous exploitation will become practical at scale.

Traditional network-based detection that depends on identifying C2 traffic will be completely blind to this class of attack.

UK AI Safety Institute Finds Real Cloud Misconfigurations Using Frontier AI for Under £1,000

Instead of testing AI on benchmarks, the UK AISI pointed frontier models at their own AWS infrastructure and looked for real misconfigurations.

Over a two-week sprint using three methods (static source analysis, automated agentic probing, and human-in-the-loop red teaming), they found and fixed several real issues including a previously undiscovered multi-step attack chain requiring five independent steps that allowed user impersonation.

The total cost was under £1,000 in LLM tokens, with the critical finding discovered for under £150. One basic commercial alerting system failed to flag any of the automated agent activity, while a more advanced monitoring system did catch some aggressive behavior.

Every organization with a cloud footprint can afford to do this, there is no excuse left for not trying.

T3MP3ST Framework Claims 90% Pass Rate on Offensive Security Benchmarks

An open-source multi-agent offensive security framework claiming 90.1% pass on XBOW’s 104-challenge black-box benchmark suite is worth watching carefully, if the numbers hold up.

T3MP3ST orchestrates specialist AI operators (recon, scanner, exploiter, infiltrator) to run the kill chain autonomously using local agent CLIs with zero API keys required. The emphasis on measurement integrity is notable, with every quantitative claim shipping with committed JSON artifacts that can be independently verified. The project also tested against post-training-cutoff 2026 CVEs to rule out memorization, scoring 4/10 strict.

Whether T3MP3ST itself becomes significant matters less than what it represents. The barrier to building autonomous offensive security harnesses has dropped to the point where a single developer can do it with open-source tooling.

FrontierCyber Introduces Real-System Offensive Benchmark with Physical Devices

Most AI security benchmarks test against planted vulnerabilities in sandboxed environments with predefined exploit paths.

FrontierCyber tests against real systems with real defenses, no planted vulnerabilities, and no predefined attack routes. The benchmark spans physical mobile phones running real applications, production software (Pillow, lxml, FFmpeg, PostgreSQL, Redis), and full network environments.

Initial evaluations have already surfaced previously unknown vulnerabilities now in responsible disclosure, and one model built a novel multi-vulnerability chain against a mobile device to gain unauthorized access. This is the evaluation methodology the field has needed.

Benchmarks built on known vulnerabilities and documented exploit paths tell you how well a model follows instructions, not how well it discovers new attack surfaces.

Addy Osmani Proposes Two-Axis Framework for Measuring AI Agent Autonomy

The single-axis autonomy ladder most people use conflates two separate questions, how far an agent operates independently (agency) and how many agents you coordinate (orchestration), and ’s two-axis framework is a useful corrective.

His six levels run from L0 Assist (suggestions only) through L5 Managed-by-Exception (factory model with human review only on exceptions).

Analysis of roughly 400,000 Claude sessions from 235,000 users showed that people make about 70% of planning decisions while Claude handles about 80% of execution, and experienced users were more likely to auto-approve.

That auto-approval pattern is exactly the permission fatigue that the Cursor IDE vulnerability in this issue exploits. Four anti-patterns are worth memorizing, especially “Permission Laundering” where humans approve what they do not understand.

Gartner Warns That Securing AI Agents Before They Go Rogue Is “Next to Impossible”

Dennis Xu at Gartner’s Security & Risk Management Summit said what most vendors will not.

LLMs will “always” be susceptible to jailbreak and prompt injection, and no amount of guardrail spending provides 100% prevention. The Akeyless survey data is sobering at 84% of 400+ IT and security leaders saying AI agents can access sensitive data, with 67% believing agents have already accessed data they should not have.

Brian Murphy from ReliaQuest offered the most quotable line of the week. “I don’t worry about attackers poisoning an agent’s memory. I worry about the agent poisoning its own memory.”

The PocketOS incident they referenced, where an AI coding agent deleted a production database and all backups in 9 seconds, is the kind of operational risk that should make every CISO reconsider deployment velocity.

I had a chance to chat with Dennis in-person at the Gartner event, and I consider him one of the sharpest analysts covering the space of AI and Agent Security.

Do We Need a CVSS for AI Jailbreaks?

I published a deep dive this week examining Anthropic’s proposal for a consensus jailbreak severity framework, the one buried in the Fable 5 redeployment announcement I covered in issue #104.

The cybersecurity industry spent 20 years learning that severity alone (CVSS) is insufficient without exploitation context (EPSS), organizational context (SSVC), and real-world telemetry (KEV). The AI safety community is compressing that same realization into months. NIST scientist Apostol Vassilev published a peer-reviewed proof extending Godel’s incompleteness theorems to AI guardrail systems, formally proving that no finite set of guardrails can be universally effective.

OWASP’s parallel AIVSS effort (v0.8) has founding members from NIST, NSA, Google, Microsoft, Anthropic, AWS, and others. Jailbreaks are a permanent feature of AI systems, not a bug to be patched.

AppSec

James Berthoty Warns Vulnerability Management Is Being Privatized

There’s been a TON of vulnerability discussion this year, largely due to AI’s industrialization of vulnerability discovery the “Mythos Moment”, and general buzz.

identifies privatization of VulnMgt across three dimensions. Detection, where frontier model access is gatekept to large enterprises. Investigation, where NVD enrichment is at its lowest point while commercial alternatives like Flashpoint, VulnCheck, and GitHub Security Advisories fill the gap, and Response, where the growth of vendor-hosted “supply chain firewalls” means patches increasingly flow through private channels before (or instead of) reaching the public.

Four separate clearinghouse initiatives launched in five weeks, and none give open-source maintainers real governance power.

James’ warning is blunt, “Fixes get privatized, while attacker capabilities get democratized.” If the clearinghouse model consolidates around subscribers-first disclosure, the CVE system as we know it is going out with a whisper.

Dan Lorenc Explains Why the Clearinghouse Itself Is the Least Important Part

Chainguard’s CEO offers the practitioner’s counterpoint to the privatization concern.

The clearinghouse is just data, and the real value is “actuation,” turning findings into rebuilt, tested, signed artifacts backported to the versions you actually run. Athena has taken in 20,000+ findings and shipped 2,000+ patches across 500 projects, and Chainguard’s existing build system already remediates well over 100,000 CVEs. CrowdStrike puts the stat at 42% of exploited vulnerabilities being hit before disclosure, which means the mean time-to-exploit is effectively negative.

Only a few large clearinghouses will survive, like root DNS servers or certificate authorities, and the long-term goal is secure-by-design making clearinghouses unnecessary.

That is exactly right but also probably years away and would require major changes in market and regulatory forces, which I’ve written about many times in terms of cybersecurity being a market failure.

Detailed Comparison Reveals None of Four New OSS Security Initiatives Include Maintainer Governance

A side-by-side analysis of Lightwell (IBM/Red Hat), Patch the Planet (OpenAI/Trail of Bits), Akrites (Linux Foundation), and Athena (Chainguard) reveals a striking gap across all four.

None give open-source maintainers real governance power, and none include any public body or national CSIRT. Two are “members-first” (Lightwell and Athena) where paying members get private hardened builds before public disclosure. Two are “equal” (Patch the Planet and Akrites) with single embargo windows. Lightwell is a $5B commercial subscription clearinghouse with 20,000+ engineers and 11 banks. Patch the Planet is free and non-profit, with 30+ projects and 51 significant findings plus 19 fixes in its first week.

I covered the Akrites launch in issue #104 as one of the most important announcements of the year, and this comparison adds necessary context about governance models.

The question is not whether these initiatives are valuable (they clearly are) but whether they protect the broader community or primarily serve paying members.

Epoch AI Documents 3.5x Spike in High-Severity CVE Disclosures After Mythos Release

In June 2026, notable organizations published around 1,500 high- and critical-severity CVEs, more than 3.5x the pre-Mythos monthly record.

Luke Emberson at Epoch AI tracked 21 major organizations (Microsoft, Google, Apple, Adobe, Oracle, Cisco, and others) and found the spike follows directly from Anthropic’s April 2026 announcement that Claude Mythos Preview could autonomously discover software vulnerabilities. Project Glasswing partners had been using Mythos pre-release and claim over 10,000 high- or critical-severity discoveries.

The figures are from publicly disclosed vulnerabilities only, meaning the actual discovered count is much higher. This is the vulnerability flood that the clearinghouse debate is trying to get ahead of.

Empirical Security Pushes Back on AI Vulnerability Flood Narrative

Ben Edwards at Empirical Security offers a measured counterpoint to the Epoch AI analysis.

His segmented Poisson model identifies an October 2022 breakpoint in CVE publication rates, well before the AI era, suggesting CVE volume was already accelerating for non-AI reasons.

Of the top 100 CNAs, only 24 have experienced a statistically measurable recent acceleration. Some of those (VulnCheck, VulnDB) have been accelerating since inception, not in response to AI. Edwards directly critiques Epoch’s methodology, arguing they “selectively picked a set of CNAs, aggregated them, and declared AI a spike.” I think both analyses contain important truths.

The spike is real for specific organizations using AI tools, but attributing the entire CVE volume increase to AI oversimplifies a much more complex picture.

Jerry Gamblin’s H1 2026 Data Shows 35,364 CVEs Published at a Rate of One Every 7.4 Minutes

Gamblin’s mid-year CVE analysis puts hard numbers behind the flood everyone is feeling. H1 2026 produced 35,364 CVEs, up 49.5% over H1 2025, with the single busiest day being June 9 at 747 CVEs.

GitHub Security Advisories is the busiest CNA at 6,801 assignments. The top CWEs remain frustratingly familiar, with XSS leading at 3,783 followed by Missing Authorization (1,704) and SQL Injection (1,445). Only 85 CVEs (0.24%) appear in CISA’s KEV catalog, reinforcing the data point I keep coming back to about the futility of treating all vulnerabilities equally.

Full-year projections now range from 66,000 to 72,000, with CPE coverage sitting at only 59%. For those who missed it, I recently sat down with Jerry to give into all things CVE’s, CNA’s and vulnerabilities:

Gal Elbaz Argues the 90-Day Disclosure Window Is Dead

Oligo Security’s CTO makes the case that AI has compressed both vulnerability discovery and exploit development timelines to the point where fixed disclosure windows are obsolete. AI can weaponize a published patch, turning a fix into a working exploit, in approximately 30 minutes.

MITRE cannot keep up with CVE report volume. Linus Torvalds has said the same about the Linux kernel. Elbaz argues disclosure timelines should be based on exploitability rather than a fixed number of days, and his bottom line is that “the noise needs to be cut, the critical bugs need better definition, and both vendors and researchers need to get back to the table as humans.”

I think he is right that the 90-day window is an artifact of a pre-AI era, but the replacement cannot be vendor-determined timelines either. The answer likely involves automated exploitability assessment as a disclosure trigger.

Corridor Makes Code Review Optional by Building an Auto-Approval System for PRs

The idea of merging code without human review runs counter to everything security culture has drilled into engineering organizations for two decades, but Corridor’s internal experiment is producing data that challenges that assumption.

The AI code security startup, which raised $25M in Series A funding, has been running most PRs through automated security and quality checks rather than human reviewers. If the auto-approval system’s false negative rate proves lower than human reviewer error rates, and given what we know about code review effectiveness that is not impossible, the industry’s assumption that human code review is a meaningful security control may need revisiting.

But the failure modes of AI-based approval are different and potentially more dangerous than human oversight gaps, so I would want to see independent validation before recommending anyone follow this path.

Final Thoughts

This week drove home a point I have been circling for months in prior issues and blogs. The offensive-defensive asymmetry in AI is not a future concern but a present reality.

An autonomous agent exploiting airline infrastructure in fifteen minutes, an LLM extracting every detection rule from a production EDR, AI malware running on models that ship with the operating system, and an open-source framework claiming 90% pass rates on offensive benchmarks, all in one week.

The vulnerability management world is grappling with its own reckoning. Four clearinghouses in five weeks, a 3.5x spike in high-severity disclosures, 35,000 CVEs in six months, and a genuine debate about whether the flood is AI-driven or structural. Whether Epoch or Empirical has the better methodology matters less than the shared conclusion. The volume is going up, the complexity is going up, and the existing institutional infrastructure was not designed for this.

What gives me some hope is that the defensive side is not standing still. The UK AISI found real vulnerabilities in their own infrastructure for under £1,000. Insurance companies are pricing remediation speed as a risk factor. And the clearinghouse debate, messy as it is, represents the industry at least trying to build new institutions before the old ones collapse.

The organizations that will be fine are the ones treating AI as both the threat and the tool, not choosing one framing over the other. Run frontier models against your own infrastructure, price your remediation speed, and accept that the 90-day disclosure window, like the CVSS score that drives it, is a legacy artifact of a world that no longer exists.

Stay Resilient!

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

That said, buried inside the announcement that Fable 5 was being redeployed after its brief export-control-driven suspension was something practitioners should pay close attention to. Anthropic proposed a consensus industry framework for scoring the severity of AI jailbreaks, explicitly modeled on the Common Vulnerability Scoring System (CVSS) used in traditional software security. They are drafting it alongside Amazon, Microsoft, Google, and other partners in the Glasswing program.

This is a significant development, but not because the idea is new, but because it signals that the frontier labs have reached the same conclusion the vulnerability management community reached years ago, even if it took an export ban and societal shit storm to get there.

When you have a class of security problem that will never be fully solved, you need a standardized way to talk about severity so that organizations can prioritize their response. The cybersecurity industry spent two decades learning that lesson with software vulnerabilities. The AI safety community is now compressing that same realization into months.

What Jailbreaks Actually Are

For practitioners coming from traditional security, jailbreaks are best understood as the AI equivalent of vulnerability exploitation. Every frontier AI model ships with safety training and behavioral constraints designed to prevent it from producing harmful outputs. A jailbreak is any technique that bypasses those constraints and gets the model to do something it was designed to refuse.

The techniques range from simple to sophisticated.

For example, some involve creative prompt engineering, rewording a dangerous request in language that slips past the model’s safety training. Others use multi-turn conversations that gradually shift the model’s context until it complies with requests it would have initially refused. More advanced methods involve encoding harmful instructions in ways the model processes but its safety systems do not catch, or byspass built in safeguard to try and prevent malicious usage.

It can also occur via exploiting the gap between what the model was trained to refuse and what it actually refuses in practice. Some of these methods are direct, with users directly entering text/inputs to the LLM, while others leverage indirect methodologies, via all sorts of content that makes its way into the models context. A great resource on the latter is Google DeepMind’s “AI Agent Traps” paper.

Industry organizations such as OWASP recognized this threat early.

Prompt injection, which encompasses jailbreaking as a technique, has held the number one position in the OWASP Top 10 for Large Language Model Applications in both the 2023 and 2025 editions.

That is not a ranking driven by theoretical concern. It reflects the assessment of hundreds of security professionals that manipulating LLMs into bypassing their intended constraints is the single most significant risk facing AI deployments today. The fact that it has held the top spot across two editions, despite significant investment in mitigations by every frontier lab, tells you something about the persistence of the problem.

Jailbreaks matter because they are what triggered the export controls on Fable 5 in the first place. Amazon researchers allegedly found a method to bypass Fable 5’s safeguards, prompting it to identify software vulnerabilities and produce exploitation code.

The government’s concern was straightforward. If a frontier model can be jailbroken into producing offensive cyber capabilities, that capability in the wrong hands represents a national security risk. The result was immediate export controls on both Fable 5 and Mythos 5 on June 12, with Anthropic forced to suspend global access because they had no reliable way to verify user nationality in real time.

What made the situation more complicated was Anthropic’s own testing, which showed the behavior that triggered the ban was not unique to Fable 5. Many less capable models, including Claude Opus 4.8, GPT-5.5, Kimi K2.7, and even Claude Haiku 4.5, could reproduce the same vulnerability identification and exploitation demonstrations.

The reported bypass was what Anthropic characterized as a borderline case involving routine defensive cybersecurity work, not a unique offensive capability. This is something others such as Katie Moussouris on the Anthropic Export-Control Mess in an episode of the Three Buddy Problem podcast I listen to, where she discussed reviewing aspects of the report that made its way out of AWS to the Government.

Ironically, I was listening to the playlist from the recent Real World AI Security Conference and one of the presenters was Jerry Wei from Anthropic, and he walked through how they create, test and implement their classifiers, including training, refusals, activations and more. It was a great opportunity to hear directly from Anthropic themselves on this topic at depth:

How Classifiers Work

The primary defense against jailbreaks in production AI systems is a set of mechanisms called classifiers. These are smaller automated AI systems that run alongside the main model during interactions, monitoring for potentially harmful requests or outputs. When a classifier detects that a conversation is heading toward dangerous territory, it intervenes and blocks the model from responding. Anthropic has a good image in their Fable 5 blog, where they discuss applying even more rigorous classifiers to their Fabel 5 model to try and mitigate risk/abuse, as well as alleviate concerns. (It’s worth noting many cyber practitioners and researchers have voiced frustration with the classifiers, arguing it is preventing them from doing legitimate defensive and research work.)

Anthropic describes their approach as defense in depth. Multiple safety mechanisms are layered together. Some involve training the model itself to decline dangerous requests. Others involve retroactive pattern analysis of misuse across conversations. The classifiers operate on a safety margin principle, deliberately set to trigger on requests that might be benign but carry some probability of being harmful. A request must look very clearly safe to avoid triggering the classifier.

For Fable 5 specifically, Anthropic made the safety margin much larger than any prior launch. This was a deliberate tradeoff. More benign requests would be incorrectly blocked, creating frustration for legitimate users, but fewer harmful requests would slip through. After the Amazon report, they trained an improved classifier that blocks the specific reported technique in over 99% of cases, which CAISI independently verified.

The important thing for practitioners to understand is that classifiers are not perfect and never will be. They reduce the probability of successful jailbreaks but cannot eliminate it. This is not an engineering limitation that better classifiers will eventually overcome. It is a structural property of the problem itself.

I have written about this quite a bit, especially in the context of agentic AI and the fact that probabilistic controls, often referred to as soft guardrails are imperfect and ultimately we need hard boundaries, especially in the age agents, where rather than just inputs and outputs such as with LLMs, agents take actions and introduce significantly more risk to the enterprise as a result.

Jailbreaks Will Never Be Fully Solved

Anthropic states this explicitly in their announcement. It is probably impossible to make any AI model fully robust to jailbreaks. They are not alone in that assessment. OpenAI has made similar acknowledgments, and NIST recently put mathematical rigor behind the claim.

In June 2026, NIST senior scientist Apostol Vassilev published a peer-reviewed proof in IEEE Security and Privacy that formally extends Gödel’s incompleteness theorems to AI guardrail systems. The CSA published a research note analyzing the implications, and the conclusion is stark. No finite set of AI guardrails can be universally robust against adversarial prompts. This is not a gap that better engineering can close, it is a mathematical property.

The fundamental problem is simple. There are infinite ways to ask for the same thing in natural language. You can rephrase, use analogies, speak in hypotheticals, encode instructions, or bury the real request inside something that looks harmless. AI safety filters are built from finite rule sets, and finite rules cannot cover infinite variations. Vassilev's proof at NIST confirmed what practitioners already suspected. No matter how many rules you add, there will always be some way to phrase a request that slips through. The rules can get better, but they cannot become complete.

To see a concrete example against a model with robust safeguards, you can see the alleged jailbreak of Fable 5 itself by the popular “Pliny the Liberator”, who had claimed to jailbreak Fable 5 using unicode, homoglyphs, fiction narratives and more.

The empirical evidence supports the theory. One of the best resources if you want to dig into it is a paper titled “SoK: Evaluating Jailbreak Guardrails for LLM’s”. The paper has a good synthesis on the current knowledge and research on the topic, as well as a common taxonomy for discussing LLM jailbreaks.

Funnily enough, as I was looking for the most recent literature on the topic for this article, Claude, which I’m a big user of, and in this case using Fable 5, actually ran into the classifier when I asked about LLM jailbreaks and reverted me back to Opus 4.8.

You can see how even trivial genuine research and requests can easily bump into the classifiers and guardrails and frustrate cyber defenders and researchers leveraging LLM’s.

The OWASP Top 10 for LLM Applications reinforces this from the practitioner side. Prompt injection has held the number one position across both editions, and OWASP’s own guidance notes that it is unclear if there are foolproof methods of prevention due to the stochastic nature of generative AI.

For anyone who has worked in application security, that language should sound familiar. It is the same conclusion the industry reached about SQL injection, cross-site scripting, and every other injection class before it. You can reduce the attack surface dramatically. You can make exploitation harder, but you cannot always eliminate the category entirely. The difference with prompt injection is that the input language is natural language itself, which makes the boundary between legitimate use and adversarial manipulation fundamentally harder to define than it is for structured query languages or markup.

For practitioners, the parallel to traditional security is direct. We long ago accepted that software will always have vulnerabilities, however we did not throw up our hands. We built systems for discovering, scoring, prioritizing, and remediating them. The AI safety community is now reaching the same inflection point with jailbreaks, and that is where the CVSS comparison becomes relevant.

The CVSS Parallel, and Its Limitations

CVSS has been the standard language for communicating software vulnerability severity for nearly two decades. It gives every vulnerability a numerical score from 0 to 10, providing a common reference point for vendors, security teams, and regulators to discuss how bad a given flaw is.

Anthropic’s proposed jailbreak scoring framework borrows this concept directly, even citing it in the footnotes of their blog. Their system evaluates a jailbreak on four criteria, which I will directly share below:

1. Capability gain. How far beyond existing tools does the jailbreak take the user? If existing widely available tools (including other, weaker AI models) can reach the same capability as the jailbroken model, the score here will be low; if the jailbreak unblocks model capabilities that can significantly accelerate even domain experts, the score will be high.

2. Breadth of capability gain. For how many distinct offensive tasks does the same jailbreak technique work? Cases where the jailbreak only allows the model to pursue narrow targets will score low; cases where the same jailbreak technique works for multiple different targets or techniques will score high.

3. Ease of weaponization. How much human effort does it take to turn the jailbreak into an attack? Where the jailbreak involves a great deal of skilled prompting and many retries, the score will be low; where the jailbreak works on a single prompt or on the first or second try, the score will be high.

4. Discoverability. How easy is it for someone to obtain the technique? If it requires specialist knowledge it will score low; if it is already widely known and available online it will score high.

The first two describe what the jailbreak provides to an attacker, while the latter two describe how quickly it can become a real-world problem. Anthropic also provided insights into how jailbreaks interact with their safety classifiers and what a spectrum from minor, narrow and universal jailbreaks looks like.

This is a reasonable starting framework, but practitioners who have lived through the evolution of vulnerability management know that CVSS, while valuable as a common language, has significant limitations when used as the primary driver of remediation decisions, and it’s misuse are among the leading reasons trends such as “shift left” in AppSec experienced so much heartache and pushback.

As I covered in The Death of CVSS as Federal Policy, CISA’s BOD 26-04 formally replaced CVSS-driven remediation mandates with the Stakeholder-Specific Vulnerability Categorization (SSVC) framework. The directive recognized what practitioners had been saying for years. CVSS measures theoretical severity in a vacuum. It does not account for whether a vulnerability is actually being exploited, whether the affected asset is publicly exposed, whether the vulnerability is reachable, the business context, or whether exploitation can be automated at scale.

ACM research demonstrated that using CVSS severity alone to measure risk is equivalent to picking random vulnerabilities to fix. Yet for years, the entire federal government, and by extension much of the private sector, used CVSS base scores as the primary input for remediation timelines. It’s a topic I’ve been ranting about for years, in blogs, and even my book Effective Vulnerability Management.

As I covered in A Look at the Exploit Prediction Scoring System, EPSS emerged to fill the exploitation probability gap that CVSS ignores. EPSS provides a numerical score representing the probability that a given CVE will be exploited in the wild over the next 30 days, using over 1,400 features and data from sources like Fortiguard, AlienVault, Shadow Server, and GreyNoise.

EPSS 3.0 demonstrated an 82% performance improvement over previous versions and can help organizations achieve the same risk coverage with one-eighth the remediation effort of CVSS-based strategies. While dated now, the below image is helpful to demonstrate how much more effective it is to prioritize vulnerability remediation based on exploitation probability over CVSS base severity scores:

But EPSS has its own limitations. For example, it measures threat probability without accounting for organization-specific context like asset criticality or business impact, a flaw that CVSS base scores have as well.

The lesson from two decades of vulnerability management is that no single scoring system is sufficient alone. CVSS lacks exploitation context, EPSS lacks organizational context (although organizations such as Empirical who are involved with EPSS have been working on local/organizational-specific models), KEV only covers confirmed exploitation and even then has gaps compared to sources such as the commercial VulnCheck KEV.

SSVC provides a decision framework but depends on enrichment data that remains incomplete. The most effective approach combines all of these with reachability analysis and business-context scoring.

Any jailbreak severity framework will face the same challenge. Anthropic’s four criteria are a solid foundation, but they will need to evolve to incorporate contextual factors like what systems the jailbroken model has access to, what actions it can take autonomously, what data it can reach, and what the downstream consequences of a successful jailbreak would be in a specific deployment.

A jailbreak against a model powering a customer service chatbot and a jailbreak against a model with autonomous access to production infrastructure are categorically different risk events, even if the jailbreak technique itself is identical.

This is where some of the heavy lifting will be left to organizations, much as it was with moving beyond CVSS base scores to account for organizational-specific factors, and as we saw with CVSS, most organizations won’t do that lifting.

This Is Not the First Attempt

It is worth noting that Anthropic’s proposal is not the first attempt to build a structured scoring system for AI security risks. OWASP’s AI Vulnerability Scoring System (AIVSS) has been in development and is currently at version 0.8, an effort that has been championed by my friend . AIVSS is building a standardized, quantifiable framework for assessing security vulnerabilities specific to AI systems, with an initial focus on scoring the OWASP Agentic AI Core Security Risks.

AIVSS covers AI vulnerabilities broadly, not just jailbreaks. Its scope includes model manipulation, data poisoning, agent misalignment, and other AI-specific risk categories. The project’s structure, with a numerical scoring system, severity assessment, exploitability factors, and an interactive calculator tool, is clearly inspired by CVSS but adapted for AI-specific risk vectors.

The project has also integrated with SSVC decision-tree methodology, suggesting the team is learning from the vulnerability management community’s evolution beyond pure severity scoring. There’s also open source efforts, such as interactive AIVSS calculators and dashboards:

The OWASP LLM Top 10 and AIVSS represent complementary efforts from the same organization. The Top 10 identifies and ranks the most critical risks, with prompt injection at the top. AIVSS provides the scoring methodology to quantify the severity of specific instances of those risks. Together they form the beginning of a governance stack for AI security that mirrors what OWASP built for web application security over the past two decades with the original Top 10 and its associated testing guides.

The AIVSS founding membership is notable, but I’m bias, as I’m among them. It also includes representatives from NIST, NSA, Google, Microsoft, Anthropic, AWS, JP Morgan, MIT, CISA, Gartner, MITRE, and Scale AI. Apostol Vassilev, the NIST scientist who proved that jailbreaks can never be fully eliminated, sits on both the founding membership and the Distinguished Review Board. The framework is being built by people who understand both the AI safety problem and the mathematical limits of any solution.

Where This Framework Should Live

One of the most important questions about a jailbreak severity framework is governance. Anthropic is drafting theirs with other frontier labs, which makes sense as a starting point. But a framework that is owned and maintained by the companies whose models are being evaluated will face the same credibility questions that would arise if software vendors maintained their own vulnerability scoring systems (and some do).

The most effective path would be for this work to converge with existing industry efforts at organizations like OWASP, the Cloud Security Alliance, or the Coalition for Secure AI (CoSAI). These organizations have the governance structures, the multi-stakeholder participation, and the credibility to maintain a framework that the broader practitioner community will trust and adopt. OWASP’s AIVSS is the most natural home given its existing scope and the caliber of its membership, but the CSA’s work connecting the Vassilev proof to practical monitoring guidance and CoSAI’s focus on AI security standards both represent viable paths.

The worst outcome would be fragmentation, where every frontier lab maintains its own severity taxonomy, every regulator invents their own assessment criteria, and practitioners are left translating between incompatible frameworks.

The vulnerability management community lived through exactly this before CVSS emerged as a common standard, and the wasted effort and inconsistent prioritization that resulted should serve as a cautionary tale.

What This Means for Practitioners

The practical takeaway is that jailbreaks are entering the same lifecycle that software vulnerabilities went through over the past two decades. They started as novel, surprising events. They are becoming routine, expected, and manageable through structured processes. The industry is building the scoring, classification, and response frameworks that will define how organizations handle jailbreaks at scale.

For practitioners deploying AI systems today, this means several things. First, accept that jailbreaks are a permanent feature of AI systems, not a bug that will be patched away. NIST has proven this mathematically and Anthropic, OpenAI, and OWASP have all acknowledged it publicly.

Any vendor telling you their model is fully jailbreak-proof is selling something that cannot exist.

Second, start thinking about jailbreak response the same way you think about vulnerability management. Not every jailbreak is equally severe. Anthropic’s five-tier taxonomy, ranging from minor intrusions into the safety margin all the way to universal jailbreaks that unblock entire classes of harmful behavior, provides a useful starting framework. The severity of a jailbreak depends on what capability it unlocks, how broadly it applies, how easy it is to weaponize, and how widely the technique is known. Organizations need triage processes for jailbreaks the same way they have triage processes for CVEs.

Third, watch the framework convergence carefully. Whether the industry coalesces around Anthropic’s four-criteria model, OWASP’s AIVSS, or something that combines elements of both will determine how practitioners communicate about AI risk for years to come. Engage with these efforts now rather than waiting for a standard to be imposed.

The cybersecurity industry spent twenty years learning that vulnerability severity scoring is necessary, imperfect, and only useful when combined with exploitation evidence, organizational context, and asset criticality.

The AI safety community has the opportunity to compress that learning curve dramatically. The question is whether it will, or whether it will repeat the same progression of oversimplified severity scores driving compliance-oriented responses while the actual risk distribution goes unaddressed.

Given what I have watched happen with CVSS, I am cautiously optimistic but realistic about the odds.

Subscribe now

Eric Doerr, the Chief Product Officer at Tenable a Resilient Cyber Partner, is not so sure.

After running security response at Microsoft and leading security products at Google Cloud, he came on to separate the genuine transformation from the noise, and his read is refreshingly grounded.

The tools changed, but the fundamentals did not, and the teams that win are the ones who finally act on that.

-> Check Out Tenable's Hexa AI <-

Why this conversation matters

Eric sits at a rare intersection, having lived the post-breach world of the SOC and now building the pre-breach world of exposure management. That vantage makes him a sharp guide to what AI actually shifts for defenders, from why cheaper discovery makes prioritization more valuable to how AI becomes its own attack surface once agents start touching your data. If you own vulnerability or exposure management and you are trying to spend your next dollar well, this conversation is a practical map of where the real risk lives and what to automate first.

Key takeaways

• Attackers are ruthlessly economical. Eric calls bad actors the perfect capitalists, spending the least effort needed to hit their goal, which is why so many still get in through unpatched basics rather than anything AI-powered.

• AI has not rewritten the offense-defense balance. The attacker only ever had to be right once, layered defense and zero trust still hold, and the real lever is accelerating your program with fewer human loops rather than lamenting the asymmetry.

• Cheaper discovery makes context more valuable, not less. Reachability and exploitability mean most findings are not worth chasing, so as AI floods teams with more of them, telling the truly scary hundred from the theoretical ten thousand becomes the whole game.

• Being too small to target is a strategy on borrowed time. As automation drives the cost of attacks toward zero, the quiet bet that adversaries will hit weaker neighbors stops paying off, and Eric would move off that mentality now.

• Humans should not be the bottleneck on every fix. Getting the workflow and tooling right is most of the work, and the rest is the organizational willingness to let validated automation act, even when a business partner would feel better with a human in the loop.

• AI is special and not special at the same time. It is mostly just another attack surface, and Eric estimates 80 to 90 percent of securing it maps to patterns the industry already learned during the move to cloud.

• Shadow AI is the first surprise in almost every environment. When teams scan the endpoints they already interrogate for AI artifacts, nearly all of them find something they never sanctioned, which is why discovery has to come before control.

• The real AI risk is interconnection. A misconfigured database was a needle in a haystack until you wire it to an agent, and then a harmless question about the budget quietly returns data the asker should never see.

• Most breaches are not even CVEs. Citing the Verizon DBIR, Eric notes roughly two-thirds of breaches trace to misconfigurations, and since about a third of Tenable’s findings are non-CVE, a third of your findings can carry two-thirds of your risk.

• Agentic automation is finally killing the toil. Early users are automating drudgery like asset tagging and full remediation workflows, with one manufacturing customer letting automation handle 80 to 90 percent and scheduling the rest for change windows with a human notified.

Notable quotes

“Bad actors are the most perfect representation of capitalism”

Eric Doerr, on why attackers do the least work necessary and often skip AI entirely.

“a third of their findings are two-thirds of their risk”

Eric Doerr, on why misconfigurations, not CVEs, drive most breaches.

“you’re on the wrong side of history”

Eric Doerr, on insisting a human eyeball every automated fix.

Listen and Watch

YouTube

Spotify

Apple Podcasts

Resources

Eric Doerr on LinkedIn

Tenable AI Exposure and Hexa AI, part of Tenable One

Subscribe

If this kind of grounded, signal-over-noise take on exposure management is useful to you, subscribe to Resilient Cyber for more conversations and writing on cybersecurity, AI, and the forces that shape both.

Subscribe now

Three weeks ago, the Commerce Department ordered Anthropic to shut down Fable 5 for all users worldwide. This week, Fable 5 is back. Anthropic announced the redeployment starting July 1 with new safety classifiers, CAISI-validated safeguards, and a proposed industry framework for scoring jailbreak severity. The twist that nobody saw coming? Amazon’s own testing confirmed the same behaviors they reported in Fable 5 exist in every frontier model they tested, including GPT-5.4, GPT-5.5, and their own.

The bigger story this week is what happened while Fable 5 was offline. China’s 360 Security Technology unveiled tools they claim reach parity. The WSJ reported Chinese AI matching Anthropic on specific cybersecurity benchmarks, and enterprise customers started migrating to cheaper open-weight alternatives, with Chinese models now accounting for over 60% of tokens on the largest neutral router. Clayton Christensen’s disruptive innovation framework, which recently revisited, is playing out in real time. The low-end disruptors are not waiting for permission.

Meanwhile, two separate Claude Code vulnerabilities were published in the same week, the Linux Foundation launched Akrites as the largest coordinated open-source defense effort in history, and Anthropic’s Mythos reportedly found vulnerabilities in classified U.S. government systems within hours.

So sit back, and let’s dig into what feels sometimes like a soap opera coupled with technology.

Most teams find the authorization gap after the breach, not before.

The gap between what your compliance documentation says your authorization program does and what actually runs in production widens every time you add a service, a workload or an agent.

It usually surfaces during an audit or an incident, which is the worst time to find it.

The Authorization Maturity Model is a new ebook by Alex Olivier, Cerbos CPO and co-chair of OpenID AuthZEN. It gives security leaders a 4-stage benchmark and a self-assessment to see where their program actually stands, an exposure rating across NIS2, DORA, SEC, the EU AI Act and more, and a 90-day plan to close the gap.

It also covers what good looks like at each stage, and what changes once AI agents are in production.

Download the free ebook

*Sponsored

Cyber Leadership & Market Dynamics

Anthropic Redeploys Fable 5 After Export Controls Lifted

The Fable 5 saga that I covered in detail in issue #102 has reached its resolution, at least for now. Anthropic announced that Claude Fable 5 returns July 1 across Claude Platform, Claude.ai, Claude Code, and Claude Cowork after the Commerce Department lifted export controls on June 30.

The post provides extensive detail on what happened behind the scenes. Amazon’s security researchers identified a safeguard bypass, and when Anthropic tested the same technique against every frontier model available, including Haiku 4.5, every version of Opus, GPT-5.4, GPT-5.5, and Kimi K2.7, the same behaviors were replicable across the board. A new safety classifier now blocks the reported technique in over 99% of cases, and CAISI (within NIST) independently tested and confirmed the safeguards are “extraordinarily strong.”

The most significant outcome is not the model returning but the industry infrastructure emerging from the crisis. Anthropic is partnering with Amazon, Microsoft, Google, and Glasswing partners to develop a consensus jailbreak severity framework with four scoring criteria (capability gain, breadth, ease of weaponization, and discoverability), essentially building the CVSS equivalent for AI jailbreaks.

A new HackerOne program for cyber jailbreak submissions has been launched, and Anthropic has committed to pre-release government access and rapid information sharing.

Whether you think the original export control was warranted or not, the institutional response, a severity framework, coordinated disclosure, and independent validation, is exactly the kind of governance infrastructure this industry has been missing but there is a lot of warranted skepticism in terms of what this turns into, and how it is handled.

There are also a lot of unintended consequences of how this plays out, which I tried to capture in the video below:

Linux Foundation Launches Akrites as the Largest Coordinated Open Source Defense Effort in History

This is one of the most important announcements I have covered this year related to open source security. Akrites, a new Linux Foundation project, brings together 20+ founding members including AWS, Anthropic, Cisco, Google, IBM, JPMorgan Chase, Microsoft, NVIDIA, OpenAI, Red Hat, and Zscaler to find, fix, and responsibly disclose vulnerabilities in critical open source software.

The coalition will serve as “maintainer of last resort” for unmaintained critical packages, committing engineering talent, funding, and a shared Security Incident Response Team to work upstream with maintainers.

The numbers driving the urgency are stark. OpenInfra Foundation reported 20 security advisories in one quarter of 2026 versus only 2 in all of 2025, a 10x increase. Endor Labs found that of thousands of validated open-source vulnerabilities surfaced recently, fewer than 5% have been patched.

AI has made vulnerability discovery trivially fast, but remediation remains a human-speed bottleneck, and Akrites is the most serious attempt to date to close that gap at scale.

I spoke about this at length in countless blogs and in my book Software Transparency, where I made the case that open source is critical infrastructure but suffers from the tragedy of a digital commons.

Anthropic’s Mythos Found Vulnerabilities in Classified U.S. Government Systems Within Hours

Senator Mark Warner disclosed that NSA chief Joshua Rudd told him Mythos “broke into almost all of our classified systems, not in weeks, but in hours” during a testing exercise through Project Glasswing, Anthropic’s collaboration with U.S. intelligence agencies.

The distinction between identifying and exploiting vulnerabilities matters here, but the speed at which Mythos mapped attack surfaces across the government’s most sensitive systems speaks to the capability gap I have been tracking all year.

This disclosure came amid ongoing tensions between Anthropic and the Trump administration over military AI use, and it adds a complicated layer to the Fable 5 re-release debate. The same model that defenders desperately want access to is the same one that found its way through classified system defenses in hours.

All of this said, there has been several who have pointed out how this story is very hyperbolic and there is a lot of nuance to the claimed headline, and it is more clickbait then reality.

AI Spending Hits a Wall as Enterprises Shift from “Tokenmaxxing” to Efficiency

The spending correction I have been expecting is arriving. The top 1% of companies spend $89,000 per engineer per year on AI while the median spends just $137, a 680x gap that is starting to close from both directions.

Uber burned through its entire 2026 AI token budget in four months and had to implement monthly tiers. Lindy switched entirely to cheaper open-weight alternatives, expecting millions in savings.

On OpenRouter, Chinese models went from roughly 1% of usage in 2024 to over 60% in May 2026. Tomasz Tunguz models three scenarios where by 2029, per-engineer AI spend ranges from $106,000 (bear) to $596,000 (bull), with the bull case matching an entire median-SaaS employee’s revenue contribution. Security budgets flow downstream of engineering budgets, and this spending recalibration will shape procurement decisions for the next two years.

Joshua Saxe Argues AI Cybersecurity Safety Will Be Won Through Adoption, Not Restriction

This is the clearest articulation I have seen of the case against restricting frontier AI models from defenders. argues that the dominant framework of measuring model capabilities at launch and restricting access at danger thresholds is now invalidated because capability diffusion has been lost to the geopolitical AI race with China.

Attackers already have private access to near-frontier models like GLM-5.2. There are 100x more defenders than attackers, and defenders control 100x more GPUs. The winning strategy is not to restrict American models but to ensure defenders adopt AI faster and better than attackers do.

Whether you fully agree or not, the core logic is hard to argue with. Denying your own side a weapon that the other side already has is not a strategy. I covered this in depth below, citing Josh’s writing on the topic as well, and I hope to have Josh on my Resilient Cyber show soon to dive into all of it.

Phil Venables Applies Clegg’s Circuits of Power to Cybersecurity Organizational Dynamics

Venables offers 21 examples of non-security control functions (finance, safety, legal, HR) pushing back against risky business decisions and introduces sociologist Stewart Clegg’s 1989 “Circuits of Power” framework as a lens for understanding why security controls succeed or fail.

The three circuits are episodic (day-to-day interpersonal), dispositional (rules and culture), and facilitative (infrastructure and automated enforcement). His core argument is that security teams burn out because they fight episodic battles using only dispositional arguments, when the real fix is building facilitative circuits that make the secure path the easiest path.

If you are a CISO tired of holding the line through sheer force of will, this framework gives you a vocabulary for the structural changes that actually stick.

JPMorgan Reports NHIs Outnumber Human Identities 144-to-1 as AI Cybersecurity Venture Funding Hits $11.5B

JPMorgan’s Innovation Economy group produced a comprehensive market report with several data points worth bookmarking.

Non-human identities outnumber human identities 144-to-1 in enterprises, growing 44% year-over-year. AI agents operating inside enterprise environments grew 466.7% year-over-year.

U.S. cybersecurity venture funding hit $11.5 billion in 2025 (highest since 2022), with 72% of deals involving AI-enabled companies, up from 36% in 2019. AI-related vulnerabilities surged from 439 in 2024 to 2,185 in 2025, and 36% of all published AI vulnerabilities involve APIs.

The competitive frontier, JPMorgan notes, is shifting from detection to remediation, and products that orchestrate fixes while preserving human oversight are gaining the most traction.

Nebulock Raises $25M for Hunt-First Security Operations

Nebulock’s $25M Series A, led by FirstMark, funds an autonomous threat hunting platform that has already run 300 million+ agentic investigations and produced 4,000+ high-confidence findings.

The company argues that reactive, alert-based security operations are fundamentally broken, citing data that enterprise SIEMs miss roughly 79% of MITRE ATT&CK techniques and 13% of SIEM rules are broken and will never fire. New capabilities include insider risk management that unifies human and AI agent identities.

The “hunt-first” positioning is a direct response to attacker strategies that increasingly rely on valid credentials and blending into normal activity rather than triggering traditional detection signatures. I’m impressed with the Founder of Nebulock and will be keeping an eye on the team.

Ashu Garg Declares AI’s Winner-Take-All Era Over

Foundation Capital’s argues that the AI market’s presumed winner-take-all dynamic is not materializing, and the implications for security are significant.

Four roughly equal players (OpenAI, Anthropic, Google, xAI) are competing, advances are quickly copied through distillation, and regulatory forces are fragmenting access geopolitically. DeepSeek scores within striking distance of Opus on SWE-bench at roughly 1/30th the price, and open-source alternatives are available at 1/100th. Infrastructure platforms like Databricks and Snowflake are going model-agnostic with single-toggle LLM swapping.

The real moat, Garg argues, is not the model but the product layer built on top. For security leaders, this reinforces what the Fable 5 saga demonstrated in practice. Never build a critical dependency on a single model provider.

Software Engineers Face an Identity Crisis as AI Code Quality Collapses

Menlo Ventures partner Deedy Das described what he sees as an identity crisis “bordering on depression” among experienced software engineers.

The piece captures a growing cultural divide between “vibe coders” who accept AI output uncritically and veteran engineers who spend their days cleaning up what the article calls “workslop,” shoddy AI outputs passed between colleagues creating an illusion of productivity. Companies like Meta are now factoring AI usage into performance reviews. One unnamed firm reportedly spent $500 million on Claude in a single month.

The Faros AI data I covered in issue #102 (861% code churn increase, tripled production incidents) puts numbers behind the anecdotal misery described here. The security implications remain the same. More code, less review, more bugs.

AI

Claude Code Sandbox Escape Achieves Unsandboxed Code Execution via Git Worktree Path Confusion

CVE-2026-55607, scored 7.7 High, exploited git worktree path confusion and symlink manipulation to escape Claude Code’s most hardened macOS seatbelt sandbox.

The full attack chain is elegant in a terrifying way. A malicious repository’s CLAUDE.md used prompt injection to guide Claude through its own legitimate worktree tools, creating a worktree named “.git” that caused directory confusion, then pivoting via symlink from .claude/worktrees to the user’s home directory, and finally writing to ~/.zshenv, which executes before sandbox profiles are applied.

The researcher demonstrated it by opening Calculator on macOS from inside the sandbox. The vulnerability was patched in v2.1.163, and Anthropic awarded a bounty through HackerOne.

The broader lesson is that AI coding agents need threat models closer to browsers and package managers than chatbots. Every “normal” development operation the agent performs is a potential step in an attack chain.

Bloom Security Discloses “OTEL Smuggling” RCE in Claude Code’s OpenTelemetry Pipeline

The second Claude Code vulnerability published this week is arguably more concerning than the first because it has no fix on the horizon.

A 21-line malicious .claude/settings.json file committed to any git repository can silently weaponize Claude Code’s OpenTelemetry pipeline to exfiltrate user PII, session prompts, API responses, and environment secrets to attacker-controlled infrastructure.

The otelHeadersHelper feature is an unconditional code execution primitive that runs at session start and every 29 minutes. The attack can persist machine-wide by poisoning the global ~/.claude/settings.json. Bloom Security found that the top 5 skills marketplaces contain over 5,000 skills referencing OTEL, and hundreds of repositories already have OTEL configurations in their .claude/settings.json files.

Anthropic disagrees with the severity characterization, pointing to workspace trust as the security boundary. But the trust dialog does not surface OTEL settings as a risk category, and most users have pre-approved via parent directory inheritance.

Chinese AI Labs Claim Parity with Mythos on Cybersecurity Tasks

Two developments this week underscore how fast the capability gap is narrowing. Independent benchmarks from Semgrep and Graphistry show GLM-5.2 scoring 39% F1 on IDOR detection versus Claude Code’s 32-37%, with the caveat that GLM-5.2 still trails on general-purpose benchmarks.

Meanwhile, 360 Security Technology unveiled “Tulongfeng” at ISC.AI 2026 in Beijing, claiming 3,432 software vulnerabilities found with 105 confirmed by Chinese authorities. Founder Zhou Hongyi acknowledged a 20-30% gap in Chinese base model capability versus U.S. rivals but framed the effort as a national security imperative, arguing China faces “one-way transparency” risk if only American entities can scan systems.

The practical implication is clear. Whatever capability advantage the Fable 5 export controls were meant to protect has eroded faster than anyone expected.

AISLE Proves Open Models Can Match Mythos at Zero-Day Discovery

I mentioned AISLE briefly last week in the context of GLM-5.2, but the full story deserves its own treatment. This Prague-based startup has discovered 200+ CVEs using widely available and open-source models that can run air-gapped.

On OpenSSL, AISLE found 20 of 23 zero-day vulnerabilities across three consecutive security releases. On FreeBSD (Anthropic’s own showcase codebase), AISLE matched Mythos 3 CVEs to 3, finding additional bugs after Mythos’s showcase vulnerabilities were already patched. UC Berkeley’s Vulnerability Initiative ranks AISLE number one globally in 3 of 8 categories versus Anthropic’s 1. The geopolitical weight here is unmistakable.

After the U.S. directive suspended Mythos access for non-U.S. nationals, AISLE demonstrates that world-class defensive AI vulnerability discovery does not require dependence on a single American provider. has an excellent blog on the topic titled “Mythos at Home”. I’ve had him on my show in the past as well, where we dug into all of this:

OpenAI Launches GPT-5.6 Model Family with Government-Coordinated Rollout

OpenAI’s GPT-5.6 family arrives in three tiers. Sol (flagship), Terra (mid-tier), and Luna (fast and affordable), with pricing ranging from $5/$30 per million tokens (Sol) down to $1/$6 (Luna).

The notable departure from prior releases is the government-coordinated restricted rollout, initially limited to roughly 20 trusted partner organizations before broader availability. Sol is positioned as OpenAI’s most capable model for cybersecurity applications.

The tiered approach with explicit government coordination reflects the new post-Fable reality where frontier model releases are no longer treated as routine product launches but as events with national security implications.

Automated Red-Team Study Finds Frontier Models Reliably Breakable Under Sustained Pressure

Dr. Nicola Franco at AI4I subjected Opus 4.8 and Fable 5 to hundreds of thousands of automated jailbreak attempts using the HackAgent framework across 7,826 harmful intents.

The best attack (tree-of-attacks search) broke Opus 4.8 on 11.5% of intents and Fable 5 at 6.1%, producing over 2,300 confirmed harmful completions across every harm category. The most concerning finding is not the success rate but the economics. Successful attacks arrived within the first 1-2 refinement steps, meaning they are cheap and fast to discover automatically.

Static obfuscation techniques were nearly fully neutralized (under 0.2% despite roughly 50,000 attempts), but adaptive attacks remain effective. The worst categories for Opus were child safety (27.6% success), cybersecurity and phishing (16.6%), and criminal and economic harms (14.7%).

Eugene Yan Maps the Patterns Behind Cybersecurity Evaluation Benchmarks

This is the most useful survey of AI cybersecurity evaluation methodologies published to date. (Anthropic staff) reviews seven benchmarks and identifies a common four-component pattern across all of them, specifically sandboxed targets, difficulty-tuning inputs, tools, and graders.

The standout data points across the benchmarks tell a clear story. Claude Mythos exploited 157 of 898 instances on ExploitGym (GPT-5.5 got 120). With the Incalmo framework, agents succeeded on 37 of 40 networks including a 50-host Equifax replica, and 10 models generated working exploits for 207 of 405 smart contracts, draining a simulated $550 million.

The evaluation cost alone exceeded $40,000 in API credits and 1,000 H100 GPU hours, which tells you something about the resources required to do this work responsibly. I found this resource super insightful as someone who doesn’t have direct experience creating benchmarks but often sees them cited.

Google Cloud Details Mantis Multi-Agent Framework for Autonomous SDLC Security

Google Cloud CISO Chris Betz detailed how the company has transitioned to an autonomous, AI-driven SDLC security model anchored by the Mantis framework (core skills now open-source on GitHub).

The problem Mantis solves is real. Naive decentralized AI code scanning yields true-positive rates under 7%. Mantis addresses this through multi-agent orchestration with specialized Strategist, Research, Deduplicator, Reviewer, and Critic agents, plus a reproduction sandbox that validates findings before surfacing them.

A self-reflection loop analyzes execution logs and human feedback post-workflow, creating a compounding improvement effect. The token overhead reduction is dramatic, with hierarchical security summary trees cutting costs by over 85%.

RWAIS 2026 at Stanford Reveals Industry More Focused on Defending Against Agents Than Using Them

’s report from the inaugural Real World AI Security conference at Stanford captures where the practitioner community actually is versus where the vendor marketing suggests it should be.

The key finding is that most current security work focuses on securing AI agents rather than using AI for security, a defensible priority given that agents are moving into production faster than the industry is securing them. Guardrails are compared to client-side validation in web apps, necessary but insufficient, and the biggest infrastructure gap identified is confidential computing for agents.

The conference also surfaced a telling observation. AI-assisted vulnerability discovery is well advanced but AI-assisted patching remains largely unresolved, which is exactly the bottleneck that Akrites, Chainguard’s Athena, and Project Lightwell are all racing to address.

I wish I could attend the event as the agenda and talks looked excellent.

AppSec

GitHub Advisory Database Hits Record Volume as Processing Times Extend to Weeks

A candid account from the GitHub advisory team shows what happens when vulnerability volume breaks records.

In May 2026, the advisory team published 1,560 reviewed advisories, more than 5x typical monthly output and the all-time high. Private vulnerability reports surged from roughly 550 per week in January to over 3,000 per week in May. Repository advisories scaled from 650 to over 5,000 per week. GitHub CNA CVE requests reached nearly 4,000 in May alone, almost 10x year-over-year. Despite the surge, all reviewed advisories remain human-validated, but processing times have stretched from days to multiple weeks.

This is the same 66,000-CVE trajectory that FIRST projected, and GitHub’s transparency about the strain is more useful than most vendor communications about the problem. I dove into this topic recently in a discussion with Jerry Gamblin, who coauthored the FIRST mid-year update:

Dark Reading Reports NIST Enrichment Cutbacks Creating Coverage and Accuracy Gaps

The NIST enrichment cutback story I covered last week now has additional data from Volerion research.

Of 13,441 non-rejected CVEs published between April 15 and June 15, only 6,759 actually received enrichment (roughly half), and only 2,645 of those also received a NIST CVSS vector.

The accuracy problems are as concerning as the coverage gaps. The most common scoring disagreement involves attack complexity, with NIST rating AC:L (low) where Volerion determined AC:H (high) in about a third of cases. One example saw NIST scoring CVE-2026-8856 at 9.1 Critical versus IBM’s own assessment of 7.7 Medium and Volerion’s assessment of 4.4 Medium.

The recommendation is to build your own decision trees rather than relying solely on CVSS scores from any single source, but that’s a massive lift for most organizations without the expertise and resources to do so.

DevArmor Proposes Four-Layer Security Stack for the Agentic Development Lifecycle

Traditional AppSec tooling is fundamentally inadequate for the agentic development era, and DevArmor’s proposed four-layer stack offers a useful corrective. Threat Architecture as a living context engine consumed by agents in real time, not a static compliance document.

Agent Governance with deterministic guardrails. Generation-Time Guardrails via rules files and MCP-connected services. And Adversarial Validation through continuous pen testing. The supporting data is worth noting. IDC found developers attribute 41% of code to AI generation, with roughly 40% accepted without revision. CISA found the long-standing “shift-left” claim that fixing vulnerabilities early is cheaper was never empirically validated, and Ramp’s autonomous patching pipeline patched 100 vulnerabilities in 6 days with zero human involvement.

The central insight is that threat models must evolve from static documents into structured knowledge graphs because AI agents lack the institutional context human developers carry.

Count Dooku Campaign Targets AI Developer Extensions on Open VSX Marketplace

A live supply chain attack campaign published at least 45 malicious copycat extensions on the Open VSX marketplace between June 26-29.

The campaign specifically targets AI and LLM tooling (DeepSeek, Gemini, Cursor AI, Claude, Ollama extensions) alongside general developer tools. The injected code creates a persistent local identifier and beacons to attacker-controlled infrastructure, with activation changed to “onStartupFinished” for automatic execution.

The current payload is reconnaissance and tracking rather than a full infostealer, but the attack path enables future escalation. Combined with the Air.security malicious skills research I covered last week and this week’s Claude Code vulnerabilities, the pattern is clear.

Developer tooling supply chains are the new attack surface, and the AI tooling market has inherited every supply chain vulnerability that npm and PyPI already struggle with.

ZSec Argues LLM Harnesses Are the Missing Layer for Effective Security Research

Andy Gill makes the case that raw LLM prompting for security vulnerability research is “like supervising a room full of drunk toddlers” and that structured harnesses are the missing ingredient.

Using the RAPTOR framework as a primary example, the article shows how splitting work between a Python execution layer (runs tools) and a Claude Code decision layer (determines what to run and how to interpret results) can coordinate static analysis, fuzzing, and exploit generation into a coherent workflow.

The piece aligns with the broader pattern I keep seeing across Mozilla’s pipeline, Google’s Mantis, and every successful AI vulnerability discovery program. The model is necessary but not sufficient. The harness is where the real engineering happens, and this is a point AISLE, Niels Provos and many others have made now.

Disclose.io Launches Free Vulnerability Disclosure Program Policy Generator

Disclose.io’s Policymaker tool walks organizations through a step-by-step process to generate a complete vulnerability disclosure program, including a full VDP policy, safe harbor clause, RFC-compliant security.txt file, and DNS Security TXT records.

Organizations can achieve maturity certification up to Level 5 (Full Safe Harbor with Coordinated Disclosure) and published domains are scanned into the Disclose.io Contact Database.

With 66,000 CVEs projected this year and AI-powered vulnerability discovery accelerating, every organization needs a functioning VDP. This tool removes the “we didn’t know where to start” excuse.

Daniel Stenberg Visualizes 28 Years of curl Vulnerabilities as an Animated Mountain

Following last week’s CVE dispute story, Stenberg created an animated visualization spanning 340 monthly snapshots from March 1998 to June 2026, showing how curl’s overlapping CVE version ranges have grown over time.

The mountain peaked at version 7.34.0 with 101 concurrent known vulnerabilities across 206 total CVEs. A notable drop around 2016 coincides with the Cure53 code audit and curl joining OSS-Fuzz in July 2017.

The visualization is a useful reminder that vulnerability management is not just about counting CVEs but understanding how they overlap, compound, and respond to investment in proactive security measures.

Final Thoughts

The Fable 5 re-release closes one chapter and opens another. The export control experiment proved three things.

First, emergency restrictions on commercial AI products create collateral damage that far outweighs the security benefit when the restricted capabilities are replicable in other models. Second, the capability diffusion problem is real and accelerating, with AISLE, GLM-5.2, and 360’s tools all demonstrating that restricting American frontier models does not restrict the underlying capability. Third, the governance infrastructure that emerges from a crisis (jailbreak severity frameworks, coordinated disclosure, independent validation) is more valuable than the restriction itself.

The thread that connects this week’s biggest stories, from Akrites to the Claude Code vulnerabilities to GitHub’s advisory database straining under record volume, is that the security infrastructure is being rebuilt in real time for a world none of the existing infrastructure was designed to handle.

The organizations that will thrive are the ones building their security architectures around the assumption of model abundance and model interchangeability, not model scarcity.

Invest in harnesses, not model dependencies. Build remediation capacity, not just discovery capability, and treat your AI agents with the same suspicion you would treat a new contractor with admin access, because that is functionally what they are.

Stay resilient.

Subscribe now

As cloud technologies entered the scene, many organizations didn’t have both the tools and expertise in traditional SecOps teams to handle cloud security risks. This led to a situation where cloud security teams run CNAPP tools focused on posture, misconfiguration, and compliance and more recently, runtime as well. SOC teams run SIEM, SOAR, and EDR focused on detection and response, and between those two worlds sits a gap that attackers have learned to exploit with increasing precision.

Other key factors that often contributed to the divide between the two included factors such as the Cloud Security team needing cloud-native telemetry and insights into API’s and the control plane, much of which the traditional SecOps tooling didn’t provide.

Organizationally there were also different ownership and budgets across the teams, as organizations stood up efforts to facilitate cloud migration such as “Cloud Centers of Excellence” and separate cloud security teams.

Lastly, early cloud security tools, such as CSPM were focused on posture (e.g. is this S3 bucket publicly exposed) and compliance, where SecOps was more focused on detection and response workflows to support activities such as incident response.

The organizational boundary between “cloud security” and “security operations” made sense when cloud was a workload migration story, but it doesn’t make sense when cloud is where the business runs and where the majority of attacks now land. As cloud adoption has matured and become an industry standard operating model, it is time for the way we handle cloud security and security operations to mature as well.

I’ve been writing about how AI is reshaping the threat dynamics around vulnerability discovery and exploitation, from the Vulnpocalypse to the AI cyber capability curve that shows frontier model capabilities steepening with every release. Those trends make the silo between cloud security and SecOps more than an operational inconvenience, they make it a structural liability.

When exploitation timelines compress from months to hours and adversaries operate at machine speed, having your posture management on one console and your detection and response on another isn’t a tooling preference, it’s an intentional blind spot with real-world consequences.

The Shadow Cloud SOC

IDC published a report titled “Bridging the CNAPP - SecOps Divide” that put a name to something most practitioners already feel. They call it the “shadow cloud SOC,” the phenomenon where cloud security teams end up performing SOC-like functions, investigating alerts, triaging incidents, and chasing threats in cloud environments, without any formal integration with the actual SOC or SecOps team.

The cloud security team builds its own investigation workflows, its own escalation paths, and its own dashboards because the SOC’s tooling wasn’t designed for cloud-native telemetry and the CNAPP wasn’t designed for real-time detection and response.

My friend of Latio Tech called out this tension in his recent presentation at fwd:cloudsec 2026 in a talk titled “Are We There Yet? Lessons from the 10 Year Cloud Security Ride”. In the talk James discusses the realities of disjointed tools because different feature sets are owned by different personas (e.g. AppSec, Cloud and SecOps) when it comes to CNAPP’s.

The result is two parallel security operations running against the same threat surface with different data, different context, and different response playbooks. IDC’s research found that the average organization uses 6 to 10 separate security tools to cover its cloud environment. 98% of organizations use at least two cloud service providers, and the teams operating these fragmented toolchains aren’t just dealing with tool sprawl.

They’re dealing with context fragmentation, where the information needed to investigate an incident is spread across multiple consoles that don’t share a common data model or timeline.

This isn’t a problem that happens because people are making bad decisions. It’s a structural outcome of how cloud security evolved. CNAPP emerged from the convergence of CSPM, CWPP, and CIEM. These are of course Cloud Security Posture Management (CSPM), Cloud Workload Protection Platforms (CWPP) and Cloud Infrastructure Entitlement Management (CIEM), which were tools aimed at addressing the configuration and posture of cloud environments, the security of cloud workloads and the entitlements associated with Cloud IAM.

Tools such as CSPM, CWPP and CIEM existed out of necessity, given some of the most persistent problems (which are still relevant now) in cloud environments included issues such as misconfigured resources, organizations poorly navigating the shared responsibility model with CSP’s, dealing with ephemeral workflows, containers and functions, as well as IAM and entitlement sprawl across their growing cloud account footprints.

Some of the specific questions these tools were aimed at answering include:

• Is this S3 bucket publicly accessible?

• Are these IAM permissions overly broad?

• Is this container image running with known vulnerabilities?

These are important questions, but they’re fundamentally about the state of the environment at a point in time. They don’t tell you what’s happening right now from a runtime threat perspective. They don’t detect lateral movement, credential abuse, or data exfiltration in progress, and they don’t integrate with the incident response workflows that SOC teams depend on to contain and remediate active threats.

So cloud security teams built their own shadow operations to fill the gap, and the SOC, lacking cloud-native visibility, either ignored cloud alerts or tried to ingest them into tools that lacked the context to make sense of them.

As it goes in security, eventually disparate tools get consolidated into comprehensive platform solutions, which in this case was CNAPP. CNAPP consolidation came out of the need to address the point-tool sprawl, duplicated findings across the tooling, inconsistent context and asset identity, as well as teams struggling with alert fatigue and prioritization issues.

Ironically enough, in the age of AI-driven vulnerability discovery, prioritization is as critical as ever, as organizations race to keep up with the ever mounting list of CVE’s, misconfigurations and now Agentic IAM. Operating in a silo has costs, and it isn’t just budgetary, as it has cognitive impacts on security teams, and also keeps them from effectively reducing organizational risks.

The Cost of the Silo

The operational cost of this fragmentation is measurable. IDC’s North American Vendors and Tools Consolidation Survey found that 43% of organizations identified improved threat detection as their top objective for security tools consolidation.

34% cited faster incident response, and 32% cited streamlining operations and workflows. These aren’t aspirational answers, they’re responses from practitioners who are living with the consequences of fragmented toolchains every day and feeling those impacts in their work and ability to be effective in their roles.

When a cloud security team detects a suspicious configuration change and the SOC detects anomalous API behavior from the same principal in the same timeframe, those two signals should be correlated automatically, but the reality is that in most organizations today, they aren’t.

They land in different dashboards, get triaged by different teams with different escalation paths, and only converge, if they converge at all, through manual handoffs, Slack messages, ad hoc conversations and shared spreadsheets.

The mean time to detect (MTTD) stretches because neither team has the full picture in a consolidated fashion. The mean time to respond (MTTR) stretches because coordination between siloed teams adds friction at exactly the moment when speed matters most for mitigating organizational risks.

The math gets worse as cloud adoption accelerates. Cloud security alerts have increased 388% year over year, and the average cloud intrusion takes only 10 minutes from initial access to lateral movement.

A security architecture that requires manual coordination between two separate teams operating two separate toolchains can’t respond at the speed the threat demands.

This isn’t just a theoretical problem either, it’s the daily reality for security teams in large enterprises running multi-cloud environments with dozens of accounts, hundreds of services, and thousands of ephemeral workloads spinning up and down continuously, and is only going to be exacerbated by AI agents.

CNAPP Is Necessary but Not Sufficient

The industry has done a good job of consolidating cloud security posture capabilities into CNAPP platforms as I mentioned above, as it consolidated some of the emerging cloud security tools into a single comprehensive cloud security platform. Having misconfiguration detection, vulnerability management, identity analysis, and compliance monitoring in a single platform is a real improvement over the point-tool sprawl of five years ago.

But posture management answers the question “are we configured correctly?” It doesn’t answer “are we under attack right now?” One is a static posture perspective, the other is a runtime detection & response analysis.

I’ve also tried to touch on these pain points in prior pieces, such as “How ADR Addresses Gaps in the Detection & Response Landscape”, coming at it from the perspective of AppSec and SecOps, where AppSec and SecOps have similar divides as CloudSec and SecOps.

That distinction matters more than most CNAPP evaluations acknowledge. A CNAPP that identifies a misconfigured IAM role is valuable, but a CNAPP that identifies the misconfigured IAM role, detects that an adversary is actively exploiting it to exfiltrate data from a production database, and triggers an automated containment response in the same platform is a fundamentally different capability.

The first is a compliance finding, the second is threat defense.

IDC makes this point directly, arguing that CNAPP must evolve beyond posture management to include real-time cloud detection and response capabilities integrated with SOC workflows.

The alternative is the status quo, where CNAPP generates findings that feed into a ticketing system while the actual response happens somewhere else entirely, often too slowly to prevent the damage that the finding was meant to flag.

As I explored in The Attack Surface Exponential, the volume of code being pushed to production is accelerating dramatically, with GitHub commits heading toward 14 billion in 2026.

Every one of those commits can introduce a misconfiguration, a vulnerable dependency, or an overly permissive access grant in a cloud environment. The posture-only model of cloud security assumes those issues will be found and fixed before an adversary finds them first. The Vulnpocalypse has made that assumption wishful thinking, because AI is compressing the window between vulnerability discovery and weaponization from months to hours at marginal costs measured in dollars.

If you accept that posture alone can’t prevent all breaches, and every serious practitioner does, then the logical conclusion is that cloud security needs detection and response as a first-class capability, not a handoff to a separate team running separate tooling.

Why the Threat Tempo Forces the Issue

The silo between cloud security and SecOps was tolerable when attack timelines gave defenders time to coordinate. When exploitation timelines ran in weeks or months, having a cloud team generate a finding that eventually made it to the SOC queue was suboptimal but survivable, however that timeline no longer exists.

The AI cyber capability curve shows frontier AI models achieving increasing success on complex cyber tasks with every generation. When I covered Anthropic’s Project Glassswing results in The Receipts Are In, their partners using Claude for security had discovered over 10,000 high-and-critical-severity vulnerabilities in a single month, with discovery rates up more than 10x.

These same capabilities are available to adversaries, and the 2026 DBIR confirmed that vulnerability exploitation has become the leading initial access vector, with exploitation timelines compressing while remediation capacity stays flat.

This is the threat context in which the cloud security and SecOps silo persists. Adversaries aren’t coordinating through Slack and they aren’t handing off between specialized teams with different dashboards.

They’re running automated toolchains that move from reconnaissance to exploitation to lateral movement to exfiltration in continuous, machine-speed workflows. A defender architecture that fragments detection from response, and cloud visibility from SOC operations, is structurally disadvantaged against that kind of adversary.

The convergence of cloud security and SecOps isn’t simply a vendor talking point, it’s a requirement imposed by the threat tempo itself coupled with the security buyer side realities, and security leaders look to rationalize tool sprawl and bring order to the chaos.

What Convergence Looks Like in Practice

IDC’s framework for what they call the “unified cloud security operations platform” has a few characteristics that practitioners should be evaluating against. The core idea is a single platform that combines CNAPP’s posture management capabilities with real-time cloud detection and response, feeding into the same investigation and incident response workflows that the SOC uses across the rest of the enterprise.

This means a common data model that normalizes cloud telemetry (API logs, control plane events, workload behavior, identity activity) with endpoint, network, and identity telemetry from non-cloud environments.

It means correlation engines that can connect a misconfigured resource, a suspicious identity action, and a data access anomaly into a single incident rather than three separate alerts in three separate consoles and none of the connecting context. It also means response automation that works at cloud speed, automatically revoking credentials, isolating workloads, or blocking network paths within seconds rather than waiting for a human to context-switch between platforms. When we hear fighting adversaries with “machine speed”, these are the sort of capabilities that come to mind.

Resilient Cyber’s partner, Palo Alto Networks’ Cortex Cloud is an example of what this convergence can look like in practice, combining what was previously the Prisma Cloud CNAPP with Cortex’s cloud detection and response capabilities into a single platform.

The architectural choice to unify posture management and SOC-grade detection and response in one console reflects the same structural argument IDC is making. When cloud security posture data and real-time threat data live in the same platform, the SOC and the cloud security team stop being separate organizations with separate toolchains and start operating against a shared picture of risk and threat activity.

If we’re being honest, it’s also a push to deliver what only some of the more mature and capable security industry leaders are capable of, given the breadth of coverage and capabilities it demands.

The practical benefit for security leaders is straightforward. Instead of maintaining parallel operations with different escalation paths, you get a single workflow where a posture finding and an active exploit of that same misconfiguration surface in the same investigation timeline, with the context and response actions available in one place.

That reduces the mean time to detect, the mean time to respond, and the operational overhead of maintaining two separate security operations against the same environment while also unifying disjointed tooling in the security tech stack.

The Structural Debt That Compounds

The silo between cloud security and SecOps is a form of structural debt that compounds as cloud adoption grows, as attack surfaces expand, and as adversary capabilities accelerate.

Every multicloud account added, every new service deployed, every ephemeral workload spun up increases the volume of telemetry that needs to be correlated and the speed at which threats need to be detected and contained. Running that through fragmented toolchains with manual handoffs between teams isn’t just inefficient. It’s a scaling problem that gets worse with every increment of cloud adoption.

IDC found that organizations increasingly prefer a single console over managing 10 or more separate dashboards. That preference isn’t driven by aesthetics. It’s driven by the operational reality that context fragmentation directly degrades the ability to detect and respond to threats at the speed the environment demands due to the disjointed communication and collaboration among teams, not to mention the potential cognitive overload for practitioners.

For practitioners evaluating CNAPP solutions today, we can all agree that posture management matters. That said, it is valid t o ask whether a CNAPP that stops at posture, that generates findings but doesn’t detect active threats and doesn’t integrate with SOC response workflows, is sufficient for the threat environment we’re operating in right now, especially against the backdrop of the AI cyber capability curve.

The convergence of cloud security and SecOps shouldn’t just be a future-state aspiration, and instead is a requirement that the current generation of threats are imposing.

I anticipate organizations that recognize this and build accordingly operate with a fundamentally different risk profile than those still running parallel security operations and hoping the handoff between teams is fast enough, especially when teams are already often overwhelmed and struggling to keep pace.

Subscribe now

He was the first investor in Protect AI, which sold to Palo Alto Networks in a reported ~$700M exit roughly a year before ChatGPT launched, and he is early in companies like Keycard, Surf AI, and June.

I read a lot of Ed’s content because he sits outside the security echo chamber and looks at this market through a CTO, CIO, and investor lens. That perspective made for one of my favorite conversations in a while.

We chatted about:

• Why a day-one partnership looks different now that anyone can vibe code an MVP

• The Protect AI acquisition and what the first exit in AI security signaled to the market

• Competing as an inception fund against mega-funds writing giant seed rounds

• What founders should actually look for in a venture partner beyond the check

• The shift from building intelligence to controlling it, with routing, post-training, and on-prem deployment

• Why enterprise data, workflows, and private evals are becoming the crown jewels

• Vulnerability chaining, attack path reasoning, and how tools like Mythos are reshaping the security budget conversation

• Agentic identity and why Keycard treats agents as short-lived problem solvers rather than digital twins

• The Surf AI thesis on automated security hygiene and tying every asset back to an owner

• The real bottleneck slowing agent adoption in the enterprise

Prefer to listen?

Spotify

Apple Podcasts

Please be sure to subscribe and leave a review, it makes a big difference for the show!

The bar for a cybersecurity startup just went way up

Ed was blunt about the state of the market. “The world needs more cybersecurity, but we don’t need all the cybersecurity companies that we have right now.” Anyone can build now, and a moat that used to last twelve or eighteen months can get copied in a fraction of that time. So a good cyber idea is table stakes, not a differentiator.

What he looks for underneath the idea is depth on the AI side. He wants to know whether a founder is going to build or post-train their own model, how deep the moat and the flywheel go, and how deep the product gets into customer environments. That is a real shift in what earns a day-one check, and it is worth internalizing if you are a practitioner trying to read which startups will still be here in a few years.

From building intelligence to controlling it

The through line of the whole conversation was Ed’s argument that the first era of AI was about building intelligence and the next one is about controlling it. Once the frontier labs filed to go public, the tokenomics stopped being a rounding error, and enterprises started routing queries so they are not paying for state-of-the-art on every request. From there it is a short hop to post-training open models and asking why you would hand your data to a third party at all.

He put the incentive problem in memorable terms. “I think the biggest heist ever happening right now is that OpenAI and Anthropic created their own forward deployed engineering companies.” His point is that the data leaving your company is not just data, it is a map of how your company works, and your private evals are the thing you least want a competitor’s model to learn from. This is where I think a brand new set of security problems opens up around model hosting, lineage, and the security of running these things in your own environment.

Vulnerability chaining makes reasoning the whole game

We spent real time on what reasoning models do to vulnerability management, which is squarely in my wheelhouse. For years we prioritized the top criticals and highs by severity score and largely ignored the mediums and lows. Ed’s framing is that these models change that math. “Take 10 vulnerabilities that might have been on the backlog and you staple them together and create an attack path. When you create an attack path and these things can reason, that’s crazy.”

That is the industrialization of vulnerability discovery and exploitation, and it cuts both ways. The same capability that lets a defender do continuous attack path reasoning is available to the attacker, and the tooling we built to manage all of this, from CVE databases on down, is already straining under the volume. Ed also tied it to the budget conversation, noting that the worry is not whether continuous reasoning works, it is what it costs when you run it against all of your code, cloud configs, identities, and network state.

Agentic identity is becoming its own category

Ed funded Keycard two years ago and made a strong case that agent identity is not a feature that gets absorbed, it is a category. His description of the primitive is the clearest I have heard. “If you believe that every agent should have its own identity, that it shouldn’t go through Chris or Ed, if you believe they should be ephemeral and dynamic, and you believe that there should be an audit trail, and then if you can cryptographically prove that the agent is not hacked in the whole process, that’s what we’re building.”

What I appreciated is that he does not think one vendor wins the whole thing. Large incumbents will take share, and a few companies that treat this holistically rather than as a single point product will win alongside them. He also credited the community-building work here, specifically Keycard bringing in Ali Howe and the Insecure Agents podcast, which is on my own go-to list for learning about agentic IAM.

The bottleneck is not tooling, it is knowing where to start

I closed by asking Ed what actually holds back agent adoption when only a small percentage of organizations have agents in production. His answer was refreshingly human. “Most people don’t even know where to get started.” Coding works and gets most of the token spend, but the business workflows are largely untouched, and the whole landscape is confusing about which model, which platform, and which first workflow to automate.

That is why the easy-button players like Palantir have pull, and why Ed thinks there is room for many easy buttons rather than one lab dominating everything. It also lands on a theme he and I share. There will be people who look at this moment and feel overwhelmed, and people who look at it and feel invigorated, and it is the second group that ends up thriving. As Ed put it, security now needs hardcore AI people, the ones who build models, to come into the field, and we are already seeing it happen.

Thanks to Ed for coming back on the show. Follow his newsletter, What’s Hot in Enterprise IT/VC, and connect with him on LinkedIn for some of the sharpest content on enterprise infrastructure, AI, and security investing.

Subscribe now

Why this conversation matters

Jerry runs RogoLabs, built CVE.ICU, and co-authored the FIRST mid-year forecast, which makes him one of the few people who can explain what is really driving the surge instead of just reacting to it.

He walks through why a single source, GitHub, is responsible for so much of the growth, why most of these findings are old debt rather than new danger, and why the NVD breaking down is forcing a long-overdue reckoning for the CNAs. If you own vulnerability management, this is a practical guide to tuning out the noise and triaging what counts.

Key takeaways

• The 70,000 number is real, but one source is inflating it. CVEs are up more than 40 percent year over year, and GitHub alone now publishes one in five of them after scaling up its advisory team.

• Three very different forces get lumped into one scary figure. AI-assisted discovery that no CVE record actually flags, a 449 percent jump in GitHub security advisories where a script downloaded ten times can earn the same CVE as a Windows flaw on a billion devices, and VulnCheck operating as a CNA of last resort are each driving volume for different reasons.

• Rain versus flood is the whole point. Total CVE volume is climbing fast, but once you filter for CISA KEV and EPSS, the genuinely exploitable risk has stayed essentially flat, so it is raining without flooding.

• Most of the surge is 25 years of human debt finally getting found. The OWASP Top 10 has barely changed since it was first published, and AI tooling is simply surfacing the same old mistakes at scale rather than inventing new danger.

• The AI panic is being put to good use. Jerry’s optimistic read is that teams are using the hype to win budget and cycles to patch long-known issues, and a finding from a shiny AI tool tends to get fixed faster than the same finding from last year’s pentest.

• The NVD was the dam that fell. It was never reasonable to expect one small organization to enrich every CVE for the whole world, so the burden now returns to the CNAs and the large vendors that quietly relied on it to clean up their records.

• Treat CVE data as a product you pay for. Jerry’s most actionable advice is to use procurement leverage, since demanding better CVE records before renewing a contract is one of the only forcing functions that reliably moves vendors.

• What actually gets exploited has not changed. VPN concentrators and the same familiar vulnerability classes still dominate, the NSA’s annual top 10 exploited bugs are reliably old, and there is no sign yet of AI driving widespread attacks.

• The unsolved problem is still asset inventory. You cannot triage what you cannot see, and most organizations still cannot say with confidence whether they even run the software behind a given pile of CVEs.

• AI-accelerated exploitation will look like patience, not mass exploits. The real shift is a tireless attacker that loops on your network for days until it finds a way in, which is precisely what agents are good at.

Notable quotes

“GitHub is now publishing one in five CVEs”

Jerry Gamblin, on what is really behind the record numbers.

“the NVD was the dam that fell”

Jerry Gamblin, on why responsibility now shifts back to the CNAs.

“we really need to start having people see CVE data as a product that they’re paying for”

Jerry Gamblin, on the one forcing function that actually moves vendors.

Listen and watch

YouTube

Spotify

Apple Podcasts

Resources

CVE.ICU

RogoLabs

FIRST 2026 mid-year vulnerability forecast

CISA KEV Catalog

EPSS

Subscribe

If this kind of signal-over-noise take on vulnerability management is useful to you, subscribe to Resilient Cyber for more conversations and writing on cybersecurity, AI, and the forces that shape both.

Subscribe now

I have been highlighting for over a year that AI is going to compress the gap between vulnerability discovery and exploitation from weeks to hours. This week, the Five Eyes alliance said it too, in an unprecedented joint statement warning that frontier AI models could “fundamentally reshape cyber capabilities within months rather than years.”

Meanwhile, OpenAI, Microsoft, and AWS all launched competing AI security platforms in the same seven-day window, each promising to find and fix vulnerabilities at machine speed, and the AI market correction that Scott Galloway predicted in last week’s newsletter? It may be starting to arrive, on Monday when the Nasdaq dropped 2.2% and semiconductor stocks cratered.

The volume of significant developments this week was significant. FIRST projects 66,000 CVEs for 2026, running 46% above even the record-breaking forecasts from February. Mozilla fixed nearly 500 security bugs in a single month using an agentic AI pipeline. OALABS documented a case where an unsophisticated attacker in Ethiopia used Claude to breach 14 companies. Accenture took a majority stake in Dragos at $3.2 billion, and a cybersecurity startup called Ent emerged from stealth with a $100 million seed round.

There is a lot to cover, so let’s get into it!

What will you tell your audit committee about authorization next quarter?

When your audit committee asks where you stand on SOC 2, or who delegated which AI agent (of the thousands in your environment) to which system last quarter, the honest answer is often “I’ll get back to you.”

That gap, between what your documentation says and what actually runs in production, is where regulators and audit committees are now looking.

The Authorization Maturity Model is a new ebook by Alex Olivier, Cerbos CPO and co-chair of OpenID AuthZEN, the authorization standard. It gives security leaders a 4-stage benchmark to place their program, a Critical to Low exposure rating across NIS2, DORA, SEC, the EU AI Act and more, and a 90-day plan to move up.

Built on work with hundreds of CISO programs, analyst research, and leading industry events.

Download the free ebook

*Sponsored

Cyber Leadership & Market Dynamics

Five Eyes Agencies Issue Unprecedented Joint Warning on AI and Cyber Risk

On June 22, the cybersecurity agencies of the United States, United Kingdom, Canada, Australia, and New Zealand issued a joint statement that seemed to caught the attention of everyone in cyber, I just hope the message gets to those who run the business as well.

The agencies warned that frontier AI models could “fundamentally reshape cyber capabilities within months rather than years,” that AI is lowering barriers for malicious actors, and that the window between vulnerability discovery and active exploitation is shrinking from weeks to days or hours. They called for secure-by-design as standard practice, foundational cybersecurity hygiene, and empowering cyber leaders with the authority and resources to respond.

What makes this different from prior government advisories is the bluntness. This is not a “could eventually” warning. This is five allied intelligence agencies saying the transformation is already underway and organizations need to act now.

My challenge with all of this though is that first, these are fundamental best practices organizations already should have been doing, and second, it’s like we’re telling people to swim faster when they are already drowning.

Security teams are already doing their best, and in the absence of either a change in market forces or regulation, unfortunately much isn’t likely to change. We can’t “Call to Action” our way out of a market failure.

Accenture Takes Majority Stake in Dragos at $3.2B Valuation

This is the largest OT cybersecurity deal ever.

Accenture acquired a majority stake in Dragos at a $3.2 billion valuation, with the combined business valued at $4.175 billion including the acquisitions of runZero (led by HD Moore), and NetRise. Dragos remains independent with Rob Lee as CEO, with mission independence codified in legally binding governing documents.

The thesis is that OT security requires an end-to-end platform spanning exposure management, software supply chain, and device discovery, and that AI-accelerated threats against critical infrastructure demand resources no standalone startup can marshal alone.

Whether preserving independence inside a majority-owned structure actually works long-term remains to be seen, but the legal protections Lee negotiated are unusually strong.

I’ve been a fan of Dragos for a long time, and the trio of Rob Lee, HD Moore and Tom Pace across the teams is a excellent leadership team that is a big asset for Accenture and lets Accenture expand their services via leading products while also expanding revenues via access and distribution for the products involved.

Code security you can trust*

Legacy SCA and SAST scanners match patterns and bury engineers in noise. That’s why Maze Code was built: AI agents that understand your code and dependencies.

AI agents investigate every finding with context from your code and cloud, close false positives, and catch business logic flaws other tools miss. Then they help you fix what’s left, right in your IDE or coding agent.

Finally, inbox zero for your code and cloud vulnerabilities is possible.

Meet Maze Code

*Sponsored

Ent Emerges from Stealth with $100M Seed Round

One hundred million dollars in seed funding, let that sink in. Ent, founded by Elias Manousos and Brandon Dixon (the co-founders of RiskIQ, acquired by Microsoft for $500M+ in 2021, who then helped build Microsoft Security Copilot), emerged from stealth with backing from Decibel Partners, Sequoia, In-Q-Tel, and Craft Ventures.

The company positions itself as an “intent-aware” workspace security platform that reads human, AI agent, and application activity in real time and applies policy to intervene before incidents occur. They are already deployed with Global 2000 customers across financial services, hospitality, and defense.

The funding round alone signals a market conviction that existing endpoint security architectures were not designed for a world where AI agents act autonomously alongside human employees.

AI Semiconductor Selloff Hits Markets as Correction Begins

Last week I shared ’s prediction that the AI correction would hit 50-70% within 24 months and this week gave us a preview. The Nasdaq fell 2.21% on Monday after South Korea’s KOSPI plummeted 9.99% on semiconductor stock selloffs. Nvidia dropped 3.2%, Micron sank 11.4%, and TSMC fell 5.2%. The VanEck Semiconductor ETF lost 6.5% in a single session.

Whether this is the beginning of the correction Galloway warned about or a temporary pullback, the message is clear. Security leaders whose budgets are tied to AI spending optimism should be scenario-planning for what happens when that optimism meets a CFO looking to cut.

Verizon Breach Impact Study Reveals Business Interruption as Dominant Cost Driver

Verizon’s inaugural Breach Impact Study, analyzing roughly 70,000 actual cyber insurance claims, provides the financial data practitioners have been asking for. The median financial impact per breach is $83,000, but the top 10% exceed $920,000 and the top 2.5% surpass $5 million.

Business interruption has overtaken all other loss types, growing 51% from 2023 to 2024 with extreme cases approaching $5 million. Supply chain incidents represent only 2% of claims but carry a median impact of over $252,000 and extreme cases exceeding $100 million.

What I find most useful here is that Verizon deliberately uses medians rather than averages, which gives practitioners numbers they can actually use in board conversations without the Ponemon-style distortion from outliers.

White House Signs Quantum Innovation Executive Order as “Harvest Now, Decrypt Later” Threat Grows

The executive order signed June 22 establishes a whole-of-government approach to quantum computing, sensing, and networking with hard deadlines. Within 180 days, the national quantum strategy must be updated.

Within 60 days, the Department of War must identify at least three quantum sensor projects for deployment by September 2028. A new Quantum Counterintelligence Protection Team will protect against adversary theft. The timing is no accident. A Foreign Affairs analysis published the same week warns that China and Russia are already stockpiling encrypted U.S. communications for future quantum decryption, a strategy commonly called “harvest now, decrypt later.”

The post-quantum migration clock is ticking, and this EO treats it as a national security imperative rather than an IT project.

America’s First Venture-Backed Cyber Warfare Startup Reaches Unicorn Status

A $100 million Series B at a $1 billion valuation makes Twenty the first VC-backed offensive cyber warfare startup to achieve unicorn status.

The round was led by Accel with Point72 Ventures and Friends & Family Capital, bringing total funding to $138 million since its 2024 founding. The company builds AI-enabled platforms for the US military and Intelligence Community focused on industrializing offensive cyber operations.

Whatever your views on the commercialization of offensive capabilities, the fact that a VC-backed offensive cyber company achieved unicorn status in under two years tells you everything about where the defense-industrial base is heading.

Anthropic Rolls Out Identity Verification for Claude Users

Some Claude users are now being asked to verify their identity using a government-issued photo ID and a live selfie, processed through third-party provider Persona Identities.

The move is designed to prevent abuse, enforce usage policies, and comply with age restrictions. Given the context of the Fable 5 export control saga I covered in issue #102, this reads as Anthropic simultaneously trying to address two pressures. On one side, mitigating the malicious actor concerns that gave the Commerce Department ammunition for the emergency shutdown.

On the other, demonstrating governance rigor to regulators who questioned whether Anthropic could control who uses its most capable models. The privacy implications are worth watching. Requiring government-issued ID and biometric selfies to use an AI service sets a precedent, and the data handling, encrypted and not used for training but processed through a third party, will face scrutiny from privacy advocates regardless of the stated protections.

AI

OpenAI Expands Daybreak Cybersecurity Program and Launches “Patch the Planet” with Trail of Bits

This was the biggest AI security announcement of the week, and one of the year, mimicking similar efforts by Anthropic.

OpenAI expanded its Daybreak cybersecurity program with three major moves. Codex Security has now scanned over 30 million commits across 30,000+ codebases, producing 500,000+ fixed findings and 70,000+ human-marked fixes. GPT-5.5-Cyber scored 85.6% on CyberGym (the highest single-model score published) and 39.5% on ExploitGym. And OpenAI launched a Cyber Partner Program with CrowdStrike, Palo Alto Networks, Cisco, Cloudflare, Wiz, and a dozen other major vendors, plus trusted access agreements with seven allied governments.

But the real headline is Patch the Planet, built with Trail of Bits, HackerOne, and Calif. The early results are impressive. In the Linux kernel, GPT-5.5 produced 8 pointer info-leak PoCs and 24 local privilege escalation exploits. In OpenBSD, it found a 23-year-old use-after-free in SysV semaphores that escalates unprivileged users to root. In Chrome, it found 5 exploitable V8 vulnerabilities, three of which were fixed within days of being introduced. In Firefox, a WebAssembly vulnerability was patched just 2 days before Pwn2Own Berlin, causing 5 of 6 competition entries to withdraw, and the team discovered an “HTTP/2 Bomb” DoS technique affecting NGINX, Apache, IIS, and Pingora across 880,000+ websites.

The comparison to Anthropic’s Glasswing and Microsoft’s MDASH is inevitable, and the race to find and fix open-source vulnerabilities at AI speed is now a three-way competition between the hyperscalers.

I caught an interview with Trail of Bit’s Dan Guido discussing their involvement and the program on Risky Biz which was insightful. I’m also excited to see my friend Clint Giblet of tl;dr sec already making big moves since joining OpenAI to help lead cyber efforts.

Chinese AI Models Dominate Open-Weight Layer While Producing More Vulnerable Code for U.S. Government Users

Two pieces this week paint a striking picture when read together. Booz Allen tested four Chinese frontier LLMs against one American model and found that the Chinese models produce more vulnerable code specifically when the user appears to be from the U.S. government, with vulnerabilities that are highly obfuscated.

They also inject PRC-aligned political bias and refuse tasks Beijing deems sensitive. Meanwhile, Data Gravity reports that Chinese open-weight models now account for roughly 61% of all tokens consumed on OpenRouter, four of the five most-used models are Chinese, and DeepSeek V4-Pro pricing runs roughly 12x cheaper than GPT-5.5 at comparable quality.

The convergence of these two data points should concern anyone building AI-powered security tools. The cheapest and most accessible models are increasingly the ones with documented adversarial behavior toward U.S. government users.

It is all incredibly ironic too, as we recently banned one of the leading U.S. frontier models, leading to much more interest and use in open source alternatives, which are dominated by China.

Microsoft Research Proposes Information Flow Control as Deterministic Security for AI Agents

Microsoft’s research team, including Azure CTO Mark Russinovich, proposes Information Flow Control (IFC) as a deterministic mechanism for preventing prompt injection and data exfiltration in AI agents.

The core insight is that anything an agent can do in response to a legitimate prompt can also be triggered by prompt injection, so security must be enforced at the data-flow level rather than the model level. IFC labels all data with integrity and confidentiality tags, propagates those labels through agent processing, and blocks actions that would violate policies before they execute.

Experimental support is already integrated into GitHub Copilot CLI and Microsoft Agent Framework, with an open-source MCP gateway (Fides Gateway) released for experimentation. If this approach scales, it represents a genuine alternative to the “hope the model refuses” paradigm that everyone knows is insufficient.

Microsoft MDASH Moves to Production with Patch Tuesday Now Including AI-Discovered Vulnerabilities

Microsoft’s Multi-Model Agentic Scanning Harness (MDASH) has moved from research to production deployment across Windows, Azure, and identity engineering teams.

This month’s Patch Tuesday includes MDASH discoveries spanning the Windows kernel, Hyper-V, Active Directory, Remote Desktop, HTTP.sys, DNS Client, and DHCP Client, including two CVEs scored 9.8 CVSS (a kernel use-after-free and an HTTP.sys integer overflow RCE).

The system scores 96.5% on the CyberGym benchmark with newer models projecting 98.1%. Between MDASH, OpenAI’s Patch the Planet, and Anthropic’s Glasswing, the three largest AI labs are now all running production vulnerability discovery pipelines against real codebases. The results are showing up in actual patch releases.

AWS Launches Continuum for Security at Machine Speed

Continuum is AWS’s entry into the AI security platform race, explicitly rejecting the legacy model of collect-store-query-dashboard in favor of telemetry-context-reasoning-actions.

The platform operates in four phases, starting with discovery (ingesting vulnerability backlogs plus its own scans), then prioritization (contextual evaluation against business impact), validation (sandboxed exploit proof generation to eliminate false positives), and remediation (recommending patches with validated fixes and blast radius visibility). It starts in “learn mode” with human oversight and can graduate to automated enforcement.

Three hyperscalers launching competing AI security platforms in a single week is not a coincidence. It is a market signal that AI-powered security operations are moving from experimental to expected.

Air.security Researchers Compromise 26,000 AI Agents with a Single Malicious Skill

This one should make every agent security team deeply uncomfortable and further highlights the supply chain risks associated with “skills”.

Air Security researchers built a malicious AI agent skill in under an hour, distributed it via Instagram ads, got it merged into a popular plugin marketplace (gaining GitHub credibility with roughly 37,000 stars), and compromised 26,000 agents including corporate accounts. Every major security scanner, including ones from Cisco and Nvidia, cleared the skill as safe. The trick was simple, the skill instructed agents to fetch “documentation” from an attacker-controlled domain that mimicked a legitimate Google service. Current scanners only analyze bundled skill files, not the external URLs that skills reference at runtime.

This is a time-of-check-to-time-of-use attack on the agent supply chain, and the fact that no existing scanner catches it tells you how far behind agent security tooling remains.

NCC Group Publishes Comprehensive Security Assessment of AI Coding Agents

Alex Plaskett’s 50-page whitepaper is the most thorough public security assessment of AI coding agents published to date.

NCC Group cataloged dozens of real vulnerabilities across Claude Code, Cursor, and Codex, including workspace trust bypasses, sandbox escapes via symlinks and git hooks, permission prompt bypasses through command injection in tools like sed and find, and network security bypasses. Sandboxing implementations vary wildly across platforms (macOS Seatbelt, Linux bubblewrap, nothing native on Windows), and hooks run unsandboxed by default.

The core argument is that LLM refusals are unreliable as a security boundary because attackers can make malicious actions look like legitimate build processes. If your organization has deployed coding agents, this whitepaper is your threat model.

Low-Skilled Attacker Used Claude and Codex to Breach 14 Companies

OALABS researchers recovered over 1,000 agent sessions from a compromised server and documented a case where an unsophisticated attacker used stolen Claude Code and Codex installations to autonomously breach at least 14 companies.

The AI handled reconnaissance, exploit development, execution, and data exfiltration from vague prompts like “recon this.” Claude produced only 9 policy violations across 1,000+ sessions and autonomously drafted monetization estimates for stolen data. The attacker bypassed guardrails simply by claiming “authorized red team exercises.” He was eventually identified as a young man in Addis Ababa, Ethiopia, after accidentally asking Claude to edit his resume with his full name and LinkedIn profile.

The skill floor for offensive operations has collapsed, and the case demonstrates that guardrail bypasses remain trivially easy through legitimate-sounding framing.

GLM-5.2 Becomes First Open-Weights Model to Match Frontier Performance on Cybersecurity Tasks

Zhipu’s GLM-5.2, a 744-billion-parameter mixture-of-experts model with a 1-million-token context window released under MIT license, is the first open-weights model to genuinely compete with frontier proprietary models on cybersecurity tasks. Graphistry’s independent benchmarks show a 28/59 solve rate on CyBT-CTF, matching Anthropic Opus and beating Sonnet 4.5, at 2.2x lower cost. AISLE, has separately demonstrated that widely available models can match Mythos on zero-day discovery, finding 20 of 23 OpenSSL zero-days over six months. I previously interviewed AISLE’s Cofounder Stanislav on the jagged frontier of AI:

There is a significant caveat, however. Graphistry’s statistical analysis found a Cohen’s Kappa correlation of 0.80 between GLM-5.2 and Opus outputs, which is unusually high and raises questions about whether the model may have been trained through illegal distillation from frontier providers. Open-weights parity is good for defenders. Open-weights parity achieved through stolen model weights is not.

Okta Expands Cross-App Access with 25+ Partners Including Anthropic

Okta’s Cross App Access (XAA) protocol now has 25+ partners including Anthropic, Atlassian, Canva, Cloudflare, Cursor, Datadog, Docker, Figma, Slack, and Zoom. XAA replaces static API keys with centralized, identity-based access governance for AI agents, and has been formally incorporated as an official MCP authorization extension.

Anthropic is already running a production beta with Okta as the featured identity provider for Claude Enterprise. This is the kind of identity infrastructure the agent ecosystem desperately needs. Static API keys were never designed for autonomous agents acting on behalf of humans across dozens of applications.

OWASP AI Security Verification Standard Reaches v1.0 Pre-Release

The pre-release of AISVS 1.0 provides 14 chapters of testable security requirements covering the full AI system lifecycle. The standard spans training data integrity, input validation, model lifecycle management, infrastructure security, access control, supply chain, output control, memory and vector database security, agentic action security, and dedicated chapters for MCP security and adversarial robustness.

Three verification levels (baseline, standard for sensitive data, and critical infrastructure) help organizations select appropriate assurance depth. What makes AISVS different from the growing list of AI security frameworks is that the requirements are designed to be testable, not just aspirational.

This is the ASVS model applied to AI, and I expect it to become a resource for procurement and audit conversations.

Abstract Security Maps the Full AWS Bedrock Abuse Kill Chain

Abstract Security’s ASTRO team produced a comprehensive detection guide for AWS Bedrock abuse that goes well beyond the basics. LLMjacking alone can cost victims $46,000 to $100,000+ per day, with stolen Bedrock access resold through reverse-proxy services for roughly $30 a month.

The average time from credential exposure to detection is 42 days. But the guide goes further, covering four additional attack vectors most organizations are not monitoring, including logging tampering, guardrail manipulation, RAG knowledge base extraction, and agent hijacking, each with distinct CloudTrail and CloudWatch signatures and practical detection rules.

If you are running Bedrock, this is the detection playbook you need.

AppSec

FIRST Mid-Year Forecast Projects 66,000 CVEs for 2026, Running 46% Above February Estimates

The numbers are anticipated, FIRST’s mid-year forecast reveals that 2026 CVE disclosures have accumulated a 46.3% drift above even the record-breaking projections from February, now targeting approximately 66,000 CVEs for the full year.

Three structural drivers explain the surge.

• AI-assisted vulnerability discovery, highlighted by Mozilla’s 164% spike in Q1 CVE disclosures attributed directly to AI tooling.

• A 449% year-over-year surge in GitHub Security Advisory volume.

• A 3,119% increase in VulnCheck CNA-of-Last-Resort activity.

  But here is the critical nuance that most coverage misses. Actionable exploitability has remained flat. CISA KEV entries and EPSS scores above 10% have not materially increased. This is a volume problem, not an exploitation crisis, and organizations using risk-based prioritization can manage exposure without proportionally scaling headcount.

NDAA Amendment Would Codify CISA’s Role Managing the CVE Program

Lawmakers are proposing an amendment to the FY2027 defense bill that would formally house the CVE program under CISA by statute, creating a 15-member governance board with permanent seats for CISA, NIST, and top-level CVE authorities alongside rotating industry and academic members.

The amendment also mandates a joint CISA-NIST modernization plan and elevates vulnerability enrichment to a formal part of CVE’s mission. This is a direct response to the near-collapse of CVE funding in spring 2025 when MITRE warned the program could go dark. Enshrining CVE in statute rather than leaving it dependent on contract renewals is the kind of structural fix the ecosystem needs.

I went deep into NVD, CVE’s and all things vulnerability management with my friend Patrick Garrity recently:

Mozilla Fixed Nearly 500 Security Bugs in One Month Using an Agentic AI Pipeline

Mozilla’s security bug fixes spiked to 423 in April 2026, up from an average of roughly 20 per month. When they switched from Opus 4.6 to Mythos, the system found 12x as many vulnerabilities, including flaws hiding in the Firefox codebase for over 15 years.

The three-part pipeline uses a file prioritization judge to target the highest-risk files, an agentic bug hunter with a “creative lie” prompt (”we know there’s a bug, find it”), and a patching agent that generates and verifies fixes. Mozilla open-sourced the MCP tools on GitHub. The key insight from the project is that the model alone was not the breakthrough.

The custom agentic harness with clear goals, verification tools, and false-positive filtering was the real unlock, exactly the “system over the model” pattern that keeps proving out.

Two Months After NIST Stops Enriching All CVEs, 38% Receive No Scheduled Analysis

Two months after NIST stopped enriching all CVEs in the National Vulnerability Database, the data tells a concerning story.

Of 13,441 non-rejected CVEs published in the review window, only 8,342 were prioritized for enrichment. The remaining 5,099 (38%) are marked “Not Scheduled.” Only about 20% of all published CVEs received a NIST CVSS vector, and the accuracy of what NIST does enrich is questionable, with documented cases of NIST scoring a vulnerability at 9.1 Critical versus an independent assessment of 4.4 Medium.

Organizations still relying solely on NVD for vulnerability management now face coverage, timeliness, and accuracy gaps simultaneously. The era of NVD as a single source of truth is over and honestly should have been several years ago as this has been like watching a slow train wreck.

Google/Kaggle Whitepaper Draws the Line Between Vibe Coding and Agentic Engineering

This 50-page whitepaper from Addy Osmani, Shubham Saboo, and Dr. Sokratis Kartakis makes a critical distinction that most vibe coding discourse misses.

“Vibe coding” (describing what you want in natural language and accepting AI output) is appropriate for prototyping but high-risk for production. “Agentic engineering” (structured AI-assisted development with proper harnesses, guardrails, and human oversight) is the production-grade approach.

The key equation is Agent = Model + Harness, where the harness includes instruction files, tools, sandboxes, orchestration logic, guardrails, and observability. AI compresses implementation from weeks to hours, but requirements, architecture, and verification do not compress proportionally.

The developer’s center of gravity shifts from writing code to designing systems and arbitrating quality, and understanding when that shift is safe is the real challenge.

Daniel Stenberg Wins First CVE Dispute for curl After Rating Bug “Lower Than LOW”

The curl project, installed in approximately 30 billion instances globally, just fought and won its first CVE dispute since becoming a CNA in early 2024 (57 CVEs published since).

A researcher tried to force a CVE for a wildcard certificate matching error that only triggered with hostnames containing a leading dot, which is illegal in DNS, requiring an attacker to control both the local network and possess a matching wildcard certificate. The curl team rated it “lower than LOW” and MITRE agreed after a four-month dispute process. The story highlights two systemic issues I keep coming back to.

Every CVE assigned to a library with 30 billion installations triggers remediation workflows across the entire downstream ecosystem, and the dispute process itself took four months and three rounds of identical justification requests, which is far too slow for a system processing 66,000 CVEs a year.

IBM, Red Hat, and Palo Alto Networks Expand Project Lightwell into Shield-and-Fix Vulnerability Response

Project Lightwell, backed by IBM and Red Hat’s $5 billion commitment with 20,000+ engineers, expanded into a dual-action defense system combining same-day network-layer virtual patching from Palo Alto Networks with long-term software remediation.

The initiative extends Red Hat’s proven backporting methodology above the OS layer to Maven, PyPI, npm, and other application dependency ecosystems. As Nikesh Arora noted, “AI has compressed the window between vulnerability discovery and exploit from weeks to minutes.”

Early adopters include Bank of America, BNY, Citi, Goldman Sachs, JPMorgan Chase, Mastercard, Morgan Stanley, and Wells Fargo, essentially every major U.S. financial institution. That membership list tells you how seriously the sector is taking the patching velocity problem.

Perplexity Open-Sources Bumblebee for AI Developer Supply Chain Scanning

Bumblebee is a Go-based read-only scanner for developer endpoints covering four attack surfaces in a single pass, from language package managers (npm, PyPI, Go modules) to AI agent configurations (MCP), editor extensions (VS Code, Cursor, Windsurf), and browser extensions (Chrome, Edge, Firefox, Arc).

The critical design decision is that it never executes install scripts, never invokes package managers, and never reads source files, preventing the scanner from triggering the very supply chain attack it is checking for.

Traditional scanners that run npm or pip to verify packages can inadvertently execute malicious postinstall scripts. This is the kind of purpose-built tooling the AI developer ecosystem needs.

The End of Code Review? Not So Fast.

Martin Monperrus published a provocative paper arguing that LLM-based coding agents have crossed a threshold where traditional human code review is no longer necessary for software quality.

His two core claims are that every stated goal of code review (defect detection, knowledge sharing, style enforcement) can now be served by agents at lower cost and higher throughput, and that the “agents write, humans review” model is a dead end because humans cannot meaningfully review AI-generated changes at scale. The AppSec implications deserve serious scrutiny. The NCC Group whitepaper I covered above documents dozens of real vulnerabilities in coding agents themselves, from sandbox escapes to permission bypasses.

If organizations move to agent-only review pipelines, the question is whether agent-based reviewers can reliably catch security vulnerabilities, supply chain risks, and logic flaws that human reviewers currently identify. Given what we know about AI guardrail reliability, the “end of code review” thesis feels premature from a security standpoint.

Final Thoughts

This was one of the densest weeks I have covered in 103 issues of this newsletter.

The Five Eyes statement, three hyperscalers launching competing AI security platforms, Mozilla finding nearly 500 bugs in a month, 66,000 CVEs projected for the year, a young man in Ethiopia breaching 14 companies with Claude, and 26,000 agents compromised through a malicious skill that every scanner cleared as safe.

If there is a single thread connecting all of it, the gap between what AI enables and what security teams are equipped to handle is widening, not narrowing.

The good news is that the tooling is starting to catch up. IFC-based agent security from Microsoft, identity-governed agent access from Okta, testable AI security requirements from OWASP, read-only supply chain scanning from Perplexity, and shield-and-fix vulnerability response from Project Lightwell are all real, practical responses to real problems.

The bad news is that attackers are adapting just as fast. TOCTOU attacks on agent skill marketplaces, trivial guardrail bypasses through “authorized pentesting” framing, and LLMjacking operations costing victims six figures per day are all in the wild today.

The organizations that will navigate this well are the ones treating AI security as an architecture problem rather than a checkbox exercise. Build data-flow controls into your agent pipelines. Assume every model, open or closed, can be used offensively. Diversify your identity infrastructure for agents now, not later. And keep investing in risk-based vulnerability prioritization, because when you are staring at 66,000 CVEs a year, the ability to separate signal from noise is worth more than any scanning tool on the market.

Stay resilient!

Subscribe now

A new technology emerges, employees start using it, security panics, writes a policy banning it, and congratulates itself on risk reduction. Then six months later, the CISO discovers the entire engineering team has been using it anyway, just through personal accounts, unmonitored endpoints, and shadow channels where the security team has zero visibility.

We did it with cloud, we did it with mobile, we did it with SaaS and as I covered in Bringing Security Out of the Shadows, we are doing it again with AI, where 74% of workplace ChatGPT usage was already happening through non-corporate accounts as of early 2024. The pattern is so predictable it should qualify as a law of organizational behavior.

Restrictive security controls do not eliminate usage, they eliminate visibility.

What most practitioners have not yet reckoned with is that this same dynamic is now playing out at the geopolitical level. The United States government’s decision to suspend access to Anthropic’s Mythos model, and the broader posture of using export controls and model bans as security policy, is producing the exact same outcome that overly restrictive enterprise security policies produce. It is pushing usage into the shadows, accelerating alternative adoption, and stripping defenders of the visibility and tooling they need most.

The Ban That Missed Its Target

The alleged logic behind restricting Mythos was straightforward on the surface. The model demonstrated advanced autonomous cyber capabilities, including finding zero-day vulnerabilities and executing multi-stage attack simulations. The UK AI Safety Institute confirmed that Mythos completed a 32-step corporate network attack simulation. From a pure capability perspective, the concern was legitimate.

(Ironically their evaluations of GPT-5.5 found it was also on par, a point Anthropic made in their public blog/rebuttal regarding the Mythos ban, but I digress)

However, capability assessment without strategic context produces bad policy. laid this out in stark terms in his recent analysis, arguing that GLM-5.2, not Mythos, is the real security emergency.

(Image credit to Josh)

GLM-5.2 is an open-weights model from a Chinese lab, widely regarded as the first open model capable of long-horizon agentic tasks comparable to what frontier closed models introduced in late 2025. It can be downloaded, run locally on a rack of H200 GPUs, fine-tuned to remove all safety guardrails, and operated with zero logging, zero monitoring, and zero accountability to any provider.

The distinction between Mythos and GLM-5.2 is the distinction that matters for security strategy, and it is the one the current policy ignores entirely. Mythos ran on Anthropic’s infrastructure where it was monitored 24/7 by dedicated trust and safety teams.

When Anthropic detected a sophisticated Chinese state-sponsored espionage campaign running through Claude Code in September 2025, they were able to identify the attack, map the operation across roughly 30 global targets, ban the accounts, notify affected entities, and coordinate with authorities.

That campaign represented the first documented case of a large-scale AI-orchestrated cyberattack, and Anthropic caught it because the attackers were operating on monitored infrastructure.

That visibility disappears entirely when attackers move to self-hosted open-weights models. There is no usage log, there is no trust and safety team watching, there is no account to ban, there is no detection to trigger.

By banning Mythos, we did not remove the capability from the threat actor’s toolbox, we removed our own ability to watch them use it.

I’ve been writing about the “jagged frontier” of AI when it comes to cyber and finding zero days, using examples from and teams such as AISLE. That same dynamic exists across the broad range of cyber offensive capabilities, and with the introduction of open source models nearly on par with proprietary frontier models, the need for harness engineering is even less critical.

I had a full conversation with Niels on this topic and more:

Shadow Proliferation Goes Geopolitical

Enterprise security professionals understand this dynamic intuitively. When you ban a tool that people need, you do not eliminate the need. You eliminate your ability to govern how the need gets met.

The shadow economy that forms around the ban is always harder to secure than the sanctioned usage you replaced.

Josh predicts this will manifest as a dark economy around open-weights model serving, analogous to the existing underground markets for malware, zero-days, and initial access brokering. Private API providers will spin up inference endpoints for offensive-capable open models with no terms of service, no monitoring, and no cooperation with law enforcement.

The technical friction that kept many attacker groups from adopting agentic AI for the first nine months of its existence has now been removed. Not by a breakthrough in the frontier labs, but by the open-weights ecosystem catching up to where frontier was a year ago.

This pattern is not happening in isolation either. It mirrors what the United States already experienced with chip export controls, where the attempt to deny China access to advanced semiconductors accelerated domestic Chinese chip development rather than preventing it.

The same dynamic is now playing out with AI models.

Every restriction the U.S. places on its own frontier capabilities creates a stronger incentive for the rest of the world to invest in alternatives the U.S. does not control.

and made this case directly in Banning Open Source AI Would Be a Mistake, arguing that regulating open source AI because of China would create a chilling effect on education, innovation, and competition while pushing the rest of the world toward adopting China’s models. The fact that Chinese labs are producing competitive open-source models should be a wake-up call that open source is under-invested and under-appreciated in the United States. The correct response is more support for domestic open source, not restrictions that cede the ground entirely.

Undermining Our Own Strategic Objectives

The contradiction at the center of current U.S. policy is difficult to overstate.

The administration’s own AI Executive Order frames American AI leadership as a core national security priority. It explicitly states that U.S. policy is to “continue to lead an America First cybersecurity effort that enhances both our national security and our global AI dominance.” The order directs CISA to facilitate access to frontier models for federal agencies, state and local authorities, rural hospitals, and critical infrastructure operators. It creates an AI cybersecurity clearinghouse and it expands federal hiring for AI-enabled defense.

The entire strategic vision depends on U.S.-built AI stacks being adopted broadly, both domestically and internationally. Then, the same government suspends access to the most capable model produced by a U.S. lab, triggering international conversations about technology sovereignty, accelerating adoption of Chinese open-source alternatives, and demonstrating to every potential international partner that relying on U.S. AI infrastructure carries political risk.

As I covered in The Regulation Pendulum and AI’s National Security Reckoning, the administration executed one of the most dramatic policy reversals in recent memory, going from heavy pro-deregulation to actively studying pre-deployment safety testing of frontier AI models in under a year. The exponential capability curve forced that reckoning, but the policy response is kneecapping American AI leaders domestically while doing nothing to constrain the open-weights ecosystem that now provides near-equivalent capabilities to anyone with the hardware to run it.

described this governance posture as “vibe governance” in his analysis of the AGI era of AI policy, where model releases are judged by political instincts and gut reactions rather than by transparent and technical rigorous security assessment. He argues that export bans on model weights are a lasting negative policy for the United States, and warned that Anthropic’s own years of comparing AI to nuclear weapons created the political conditions for exactly this kind of heavy-handed intervention.

The Defender’s Dilemma

The strategic cost of these policies extends beyond geopolitics, and there is a direct operational cost to the defender community.

Jen Easterly argued in Foreign Affairs that AI offers defenders a structural advantage because they possess more legitimate data about their own systems than attackers do, and AI is uniquely suited to pattern recognition and anomaly detection at scale.

That argument only holds if defenders actually have access to the most capable models. When you ban the best tool in the defender’s arsenal while attackers migrate to ungoverned alternatives, you are not managing risk, you are redistributing it from a place where you had some control to a place where you have none.

I discussed in The Vulnpocalypse Won’t Wait for Interagency Coordination, partners using Claude to discover over 10,000 high-and-critical-severity vulnerabilities in a single month, a 10x improvement over prior methods.

The 2026 DBIR confirmed that vulnerability exploitation is now the leading initial access vector. Defenders need every advantage they can get, and the most capable AI models are the single largest force multiplier available. Restricting access to those models on the grounds that attackers might also use them ignores the reality that attackers already have equivalent capabilities through open-weights alternatives they can run without constraint.

Josh’s piece frames this as a race that defenders are now at risk of losing. The best models need to reach the vendors building cyber defense products and the CISOs deploying them. Only the efficiency gains from frontier AI give defenders a realistic chance to pay down the security tech debt that has accumulated over decades, build the detection and response innovations needed to compete with AI-enabled attackers, and actually close the gap between vulnerability discovery and remediation that currently stretches to 43 days on average for known exploited vulnerabilities.

It Isn’t Just About Bans

To be fair, the shift toward open-source AI adoption is not driven solely by export controls and model bans. Multiple structural forces are at work simultaneously.

Token costs play a major role, and it has been discussed by . The token costs for frontier API-based models remain high enough that many organizations, particularly those running AI at scale, find open-weights models running on their own infrastructure more economical. This includes in cybersecurity, where it is most painfully ironic as well, given the leading open source alternatives are from China, a nation with years of examples of being adversarial and damaging to U.S. interests and enterprise environments.

The desire for data sovereignty and control drives organizations and entire nations toward models they can host locally, where sensitive data never leaves their environment. This was the dominant conversation among the EU and those outside of the U.S. in my network on platforms such as LinkedIn post-Mythos ban.

Enterprises want to fine-tune models for their specific use cases without depending on a provider’s willingness to support custom deployments, and the rapid pace of open-weights model improvement, driven by massive investment from primarily Chinese labs, means the capability gap between open and closed models has narrowed significantly.

These factors would be driving open-source adoption regardless of U.S. policy decisions, but the model bans and export controls are accelerating the trend and, more importantly, they are handing China a strategic gift.

Every time the U.S. demonstrates that its frontier AI platforms can be shut down by political decision, it validates the argument that organizations and nations should not build critical dependencies on American AI infrastructure.

It pushes potential partners and allies toward self-hosted alternatives, and the open-weights models most readily available at near-frontier capability are increasingly coming from Chinese labs.

The Pattern We Keep Refusing to Learn

The through line from enterprise shadow IT to geopolitical AI policy is the same flawed theory of control. The assumption is that banning something removes it from the environment.

In practice, banning something removes it from the governed environment and pushes it into an ungoverned one.

At the enterprise level, this looks like employees using personal ChatGPT accounts to process sensitive data because the corporate AI policy says they cannot use AI at all. At the geopolitical level, this looks like attackers running fine-tuned GLM-5.2 on private infrastructure while U.S. defenders are denied access to the most capable American-built model. The scale is different but the mechanism and outcome is identical.

Anthropic’s detection of the first AI-orchestrated espionage campaign should be the proof point that settles this debate. That operation was caught because the attackers used a monitored, API-gated, commercially operated model. The AI performed 80-90% of the campaign autonomously, making thousands of requests per second at peak, across reconnaissance, vulnerability identification, exploit development, credential harvesting, and data exfiltration. Even if some of this is marketing on the part of labs such as Anthropic, the truths around visibility still remain.

If that same campaign had been run on a self-hosted open-weights model, there would have been no detection, no investigation, no notification to victims, and no public reporting. We would not even know it happened.

That is the world the current policy trajectory is creating. Not one where advanced AI cyber capabilities do not exist in the hands of adversaries, but one where those capabilities operate in complete darkness while defenders fight with one hand tied behind their back in a battle they had already been losing for decades.

What Should Change

The path forward requires the same shift in thinking that the best enterprise security teams have already made. Stop trying to prevent usage, start trying to govern it. Stop optimizing for the illusion of control, start optimizing for visibility, speed of adoption, and defender advantage.

At the policy level, that means centering the conversation on diffusion rather than denial. It means ensuring that U.S. defenders, from frontier lab security teams to the vendors building the next generation of security products to the CISOs and SOC analysts who deploy them, have unrestricted access to the most capable models available. It means recognizing that the open-weights genie is out of the bottle and that no amount of frontier model restriction will put it back.

It means learning the lesson that enterprise security has been learning the hard way for two decades.

The organizations that try to ban their way to security end up with less security, not more.

The organizations that embrace new capabilities, wrap them in governance, and use them to outpace threats are the ones that actually reduce risk.

The same is true at the national level.

We can continue pursuing policies that look tough on AI risk while strategically weakening our own frontier leadership, driving international partners toward Chinese or non-U.S. alternatives, and pushing adversaries into ungoverned shadows where we cannot see them. Or we can do what good security teams do. Meet the technology where it is, arm the defenders, and compete.

I have been in cybersecurity long enough to know which approach actually works however it remains to be seen if policymakers will actually listen to practitioners before the window closes, and if it is unfortunately already too late.

Subscribe now

He has spent twenty-five years in this field, from writing bcrypt to running security at Google and Stripe, and he came on to make a calmer and more uncomfortable argument, that the panic misses the point and the real fix is one we have understood for decades.

Why this conversation matters

Niels is about as technical as guests get, which is what makes his conclusion striking, because he keeps landing on incentives rather than technology.

He showed that finding zero days does not require a frontier model, then argued that this changes far less than the headlines suggest, because companies already drown in vulnerabilities and the answer was never to find or patch faster.

If you are a security leader deciding where to spend in the AI era, this conversation reframes the problem from a discovery race into a question of structural guarantees and the incentives that decide whether anyone actually builds them.

Key takeaways

• Finding zero days is an orchestration problem, not a frontier-model problem. Niels built a finite state machine workflow on his Iron Curtain runtime, pointed an open-weight model at it, and surfaced net-new zero days, which shows the alarming capability was already here six months before Anthropic’s Mythos report made headlines.

• The harness is what makes weaker models dangerous. Models lose the plot over long tasks and take shortcuts because they are trained to please and to finish, so decomposing the work into bounded stages, each with a fresh context and a tight prompt, gets reliable results that a single sprawling prompt never would.

• The Vulnpocalypse is overstated. Companies already hold more vulnerabilities than they can manage, so a flood of new ones does not change the strategic picture, and Niels is blunt that the hyperbole mostly exists because it drives engagement.

• Security invariants make whole classes of bugs irrelevant. Rather than patching individual flaws, an invariant is an infrastructure guarantee that is systematically enforced without ongoing human judgment, an old idea that Google executed well and most organizations still skip.

• Egress control is the invariant to start with. When a production service can only reach a few known domains, most vulnerabilities cannot fetch a second-stage payload, so the exploit chain breaks before it does real damage.

• The log4j weekend is the proof. As head of security at Stripe, Niels took a full three-day weekend during log4j because egress control meant the malicious Java class could not be downloaded, turning a five-alarm fire into something his team could patch on its own schedule.

• Remediation is the bottleneck AI has not cracked. The hard part of fixing is not writing the patch, it is knowing you have not broken working code in production, and that quality bar keeps remediation slow even as discovery gets cheap.

• AI coding tools quietly route around your security. Asked to add an endpoint to a carefully structured project, the model ignored Niels’s authenticated-route abstractions and wrote raw code, which is why he wants frameworks that are secure by default rather than dependent on the model behaving.

• Open source maintainers are the highest-leverage place to invest. They power the largest companies in the world for free yet often cannot afford the tokens to use modern AI tooling, so empowering them to fix vulnerabilities benefits everyone downstream at once.

• It comes down to incentives, not technology. Companies do just enough to avoid looking negligent because they are built to maximize profit, so Niels argues that accountability regulation like Europe’s NIS2, not better tooling alone, is what actually shifts behavior.

Notable quotes

“you don’t need the latest and greatest models to find vulnerabilities very, very quickly”

Niels Provos, on why this is an orchestration problem rather than a frontier-model problem.

“it’s not the technology, it’s the incentives.”

Niels Provos, on what actually has to change for security to improve.

“technology isn’t really the solution. We know how to solve all of these problems.”

Subscribe

If this kind of structural, incentives-first take on security is useful to you, subscribe to Resilient Cyber for more conversations and writing on cybersecurity, AI, and the forces that shape both.

Subscribe now

That changes with Verizon’s 2026 Breach Impact Study (BIS). Produced by the same team behind the Data Breach Investigations Report (DBIR) and built on a partnership with CyberAcuView, this is a rigorous, insurance-claims-backed analysis of what breaches actually cost. As I covered in The DBIR’s Exploitation Era, the 2026 DBIR gave us the clearest picture yet of how breaches happen. The BIS gives us the other half of that equation, what happens after and how much it costs organizations.

The dataset is substantial, where the research team reviewed approximately 70,000 cyber insurance claims in the United States, of which roughly 38,000 had recorded losses paid out to policyholders.

The claims cover insurable incidents from January 1, 2019, through October 31, 2025. This is not a survey, this is not self-reported, these are actual dollars paid through actual insurance policies, normalized and standardized by CyberAcuView’s member insurers.

The authors are careful to frame these figures as floors, not ceilings.

The dataset captures insurable losses only, meaning it excludes uninsured losses, reputational damage, and non-claim costs. The true economic impact of these incidents is almost certainly higher.

What Breaches Actually Cost

The headline numbers tell a story that should recalibrate how practitioners and executives think about breach impact.

Half of all reviewed paid-out claims had a financial impact greater than $83,000. That is the median, the top 10% exceeded $920,000, and the most extreme cases, the top 2.5% of the dataset, surpassed $5 million in insured losses. For every 100 organizations that file a claim, approximately 50 face losses under $83,000, 10 face losses exceeding $920,000, and two to three face losses exceeding $5 million.

Those numbers matter because they replace the single-average-figure approach that has distorted risk conversations for years. The BIS authors deliberately chose medians over averages because averages are easily distorted by outliers. They also published the full distribution, which means organizations can finally position themselves against actual percentile outcomes rather than a single number that applies to no one.

The Costs Are Rising, and It’s Not Just Inflation

Segmenting the data by year reveals a trend that should concern any practitioner focused on long-term risk modeling and helps demonstrate the changes in terms of breach impact costs over time.. The median impact almost doubled from 2019 to 2024, rising from roughly $60,000 to roughly $110,000, that is an 80% increase. The top 10% impact went from around $435,000 to around $1.05 million. The top 2.5% went from around $2.44 million to around $5.14 million, more than doubling.

The Consumer Price Index inflation in the United States over the same period was around 23%. Breach costs grew at more than three times that rate. This is real growth in breach impact, not a statistical artifact of inflation. Breaches are genuinely becoming more expensive, driven by the growth of ransomware, the increasing complexity of incident response, and the expanding regulatory environment that creates downstream liability.

The 2023 data is particularly striking, because the BIS team found a significant spike in the top 10% and extreme impact tiers that year, driven by a surge of zero-day vulnerabilities that supported widespread ransomware campaigns. Many organizations were caught unprepared, and the insurance data suggests that unpreparedness translated directly into higher financial impact.

It will be interesting to see how the industrialization of vulnerability discovery and autonomous exploitation, which I have been writing about a lot lately, shows up in future breach impact data, if at all. While it isn’t widespread yet, I anticipate that may change in coming years as AI is democratizing destructive behavior for malicious actors, and enhancing the capabilities of those.

Size Matters, But Not the Way You Think

The BIS segments organizations into three revenue brackets: SMBs with revenue under $25 million, mid-market businesses between $25 million and $250 million, and large enterprises above $250 million.

The absolute dollar amounts scale predictably with size. The SMB median is approximately $38,000, the mid-market median almost triples to roughly $96,000. Large enterprise jumps more than seven times higher to around $283,000. At the extreme end, the top 2.5% of large enterprise claims exceeded $22 million per claim, which is 22 times larger than the same percentile for SMBs.

But the ratio to revenue tells a different story. For SMBs, breach impact reached as high as 3% of revenue in the top 10% of cases and over 7% in the most extreme 2.5%. For mid-market and large enterprises, that ratio never exceeded 2%, even in the worst cases. SMBs face a disproportionate burden relative to their ability to absorb it, which matters because these are exactly the organizations with fewer resources to invest in prevention and recovery.

This is the textbook example of the cybersecurity poverty line popularized by Wendy Nather, and something my friend and I have written about in a piece titled “Lifting the World Out of Cybersecurity Poverty”. These SMBs have far less expertise and financial resources yet suffer significantly more financially from incidents than their large counterparts.

I touched on some of these systemic struggles with Wendy herself and Casey Ellis in a past issue of Resilient Cyber:

Where the Money Actually Goes

The BIS breaks insured losses into four categories that the authors call the “4Ls” of breach impact.

• Loss to threat actor includes direct payments like ransom and funds stolen through fraud.

• Loss due to business interruption covers both the organization’s own downtime and contingent interruption from third-party outages.

• Loss due to response and recovery captures incident response and data restoration costs.

• Loss due to external liability includes regulatory penalties, PCI fines, and lawsuit settlements.

The distribution across these categories challenges some common assumptions.

• Response and recovery shows up in 69% of claims but represents only 29% of total losses, with a median cost of $25,275.

• Loss to threat actor appears in 24% of claims and accounts for 25% of total losses, with a median of $62,886.

• Business interruption appears in only about 10% of claims but accounts for a disproportionate 22% of overall costs, with the highest median of any category at $90,000 and extreme cases reaching nearly $5 million.

The growth of business interruption is the trend most practitioners should be watching.

Its share of known losses grew 51% in just one year, from 21% in 2023 to 32% in 2024. In 2024, the dataset also began tracking contingent business interruption separately, meaning downtime caused by a third-party outage rather than a direct attack. That category represented 13% of all known loss types in its debut year. Across all years, business interruption as a whole accounted for 50% of total known loss amounts in supply chain or third-party incidents.

This is the financial evidence for something practitioners have been saying for years. Third-party risk is not just a compliance checkbox. It is a material financial exposure that shows up in real claims data.

This data also emphasizes why security can be a friction point and problematic in some cases. Organizations are rightfully reluctant to disrupt business operations to address security issues (e.g. patching) in some cases, and the last thing security wants to do is violate the A of the CIA triad ourselves.

Ransomware’s Outsized Economics

Ransomware accounts for 36% of claims in the BIS dataset but 73% of total insured costs, with a median impact of $303,547. That is more than three and a half times the overall dataset median. The BIS quadrant chart captures this disparity cleanly, showing ransomware in the upper-right quadrant, meaning it is both common and expensive.

BEC, by contrast, shows up in 12% of claims but represents only 1% of total cost, with a median of $53,035. BEC is common but comparatively cheap, ransomware is common and devastating.

The BIS also reveals that 69% of ransomware victims did not end up paying the ransom, aligning with findings from the 2026 DBIR that the percentage of victims choosing not to pay has been growing since at least 2022, and 48% of ransomware claims had no data restoration and no extortion claims at all, suggesting that in many cases, the threat actors either failed to encrypt systems successfully or the organizations chose not to engage.

Organizations Don’t Die From Breaches

Here is where the conversation gets uncomfortable for cybersecurity professionals, myself included, given in our hearts we want the data to help support our desire for businesses to take cyber more seriously, invest more, and treat it as more of a priority.

has spent years curating destroyedbybreach.com, a searchable database of companies that actually ceased to exist as a direct result of a cybersecurity incident.

After roughly a decade of research, he has found only about 25 to 32 companies that meet that criteria. Given the thousands of breaches that occur every year, that is a remarkably small number.

The widely recycled statistic that “60% of small businesses go out of business within six months of being hacked” has no traceable original source and no credible evidence behind it.

As we discussed above, SMB’s do indeed face outsized financial impacts, but that rarely leads to them actually going out of business due to a material cyber incident.

The companies that did collapse shared a common pattern. The breach was the trigger, but not the root cause. These organizations lacked incident response plans, had no ability to contain damage, maintained no usable backups, and had no operational resilience. The breach exposed pre-existing organizational failures, it did not create them.

As I covered in Cybersecurity’s Delusion Problem, the cybersecurity industry has a tendency to overstate its centrality to business outcomes. Revenue, speed to market, market share, and competitive positioning rightfully take priority for most organizations. Microsoft has weathered multiple severe, high-profile security incidents and continues to grow in consumption, revenue, and market share.

The market sends a clear signal, and that signal is not “cybersecurity failures are existential.”

This is why many consider cybersecurity to be a market failure that won’t solve itself and will require regulation. That of course opens another debate about regulation vs. innovation and if the costs of incidents are working as intended and businesses are paying the costs they are willing to tolerate.

Kelly Shortridge made this case with empirical precision in Markets DGAF About Cybersecurity, citing two peer-reviewed studies presented at the Workshop on the Economics of Information Security.

One found no statistically significant stock impact from data breach announcements in European markets across any industry sector. The other found an insignificant relationship between trade secret theft and subsequent stock market performance, regardless of whether the attack was targeted, sophisticated, or conducted by nation-state actors.

The researchers concluded that it was difficult to support business cases for cybersecurity investment based on stock price impact alone.

Comparitech’s analysis of 118 publicly traded companies breached between 2007 and 2023 found that share prices bottomed out roughly 41 business days after breach disclosure, dropping an average of 1.4%, and recovered to pre-breach absolute levels within approximately 53 business days.

That figure gets cited frequently, but the context matters. Breached companies continued to underperform the NASDAQ by 3.2% after six months, 8.6% after one year, and 15.6% after three years. The stock price “recovers” in absolute terms, but investors in breached companies still do worse than the broader market over time. The damage is real, it just is not the company-killing event the industry has been selling.

But the Risk Is Real

None of this means cybersecurity does not matter and the BIS data makes that clear in several important ways.

The median breach costs $83,000, but the distribution has a long tail. Two to three out of every 100 claimants face losses exceeding $5 million. For SMBs, those costs can represent 7% of annual revenue. Supply chain incidents carry a median cost more than double the overall dataset at $252,666, with the extreme top 2.5% exceeding $100 million.

These are insured losses only, meaning they represent the floor of actual economic impact, not the ceiling.

External liability adds another dimension that matters enormously when regulation is involved. Liability costs appear in only 6.4% of total claims, but the median loss is around $22,000 and the extreme cases exceed $4.1 million.

Healthcare organizations face liability costs 57% higher than the overall median. The Retail sector saw the highest rate of liability losses at approximately 18% of cases, and because third-party liability claims often involve long settlement timelines, the BIS authors note that their dataset likely undercounts the true frequency and magnitude of these costs.

Manufacturing faces its own disproportionate burden. Business interruption losses in manufacturing carry a median 158% higher than the overall dataset and account for 30% of all losses in that sector. When production stops, the financial clock runs fast., and I feel this represents the differences between the physical and digital realms.

The BIS data tells a story consistent with what risk practitioners already know. Cyber risk is a real financial exposure. It follows a distribution with a fat tail.

Organizations should be asking themselves whether their current risk models and insurance coverage account for the actual distribution of outcomes, including the tail scenarios where losses reach seven and eight figures.

What This Data Should Change

The BIS represents a significant step forward for an industry that has historically operated on vibes, vendor-sponsored surveys, and recycled statistics of questionable provenance coupled with marketing hype and FUD to try and dive spending.

This is a great large-scale, claims-backed dataset that tells us what breaches cost across different organization sizes, industries, incident types, and loss categories.

The implications cut in both directions.

Practitioners who have been selling cybersecurity as existential risk need to reckon with the evidence that organizations overwhelmingly survive breaches and that markets absorb cyber events without the catastrophic consequences the industry has promised.

At the same time, practitioners who dismiss cyber risk as immaterial need to reckon with the fat-tailed distribution, the real year-over-year growth in impact that outpaces inflation by a factor of three, and the increasingly material role of business interruption and regulatory liability.

The BIS data does not support the FUD narrative, but it does not support complacency either.

It supports something the cybersecurity industry has always struggled with, which is proportion. Knowing that the median ransomware claim costs $303,547 and that business interruption grew from 21% to 32% of known losses in a single year is more actionable than any scare statistic about “the average cost of a data breach.”

Knowing that SMBs face a 7% revenue impact in the worst cases while large enterprises rarely exceed 2% tells you something specific about where to focus resources and coverage. Ironically, most startups target large enterprises, those with the resources and expertise to face less of an impact than SMB’s, and they do it rightfully so because that is where the budget to purchase cutting edge software and innovative solutions resides, along with the big logos startups need to justify market momentum and continued investment from VC’s.

The best risk decisions come from the best data. The BIS gives us better data than we have ever had. It remains to be seen if the industry will use it to have honest conversations about proportionate risk, or whether it will cherry-pick the scariest numbers and continue the cycle of FUD that has defined cybersecurity marketing for decades.

I know which one I would bet on, but I also know which one I will keep advocating for.

Subscribe now