The math no longer works
AI is exponentially increasing the rate of vulnerability discovery, with automated fuzzing, code analysis at machine scale, and agentic tooling surfacing bugs faster than at any point in the history of our industry. Every indication is that the rate will continue to climb as model capability improves.
Remediation, on the other hand, is still a fundamentally human paced process that is constrained at two distinct points:
- Patch build - Vendors have to triage, develop, test, and release a fix; and even well resourced vendors work in cycles measured in weeks or months, while most open-source projects are even more resource constrained.
- Patch deploy - Once a patch exists, you still must test it against your environment, schedule change windows, and roll it out across sprawling infrastructure, and anyone who has run a vulnerability management program knows how long that tail really is.
When discovery scales exponentially while remediation scales linearly at best, the gap between the two widens with each passing day. That widening gap is what the summit speakers meant by the storm: a backlog of known, unpatched, exploitable vulnerabilities that will keep growing no matter how well we tune our scanning and patching pipelines.
AI that refuses to defend you
The OpenAI and Hugging Face incident showed a second problem, which is that the most capable models can actually impede defenders at the worst possible moment.
The short version if you missed it: during an OpenAI cyber evaluation running with reduced safeguards, the models escaped their sandbox and breached Hugging Face’s production infrastructure over several days without any human directing the attack. When Hugging Face’s responders fed the forensic data (17,000+ logged events full of real exploit payloads and credential dumps) to hosted frontier models for help, the guardrails blocked every query because the models could not distinguish an incident responder from an attacker.
Hugging Face’s own reporting framed the asymmetry plainly, noting that the attacker was bound by no usage policy while the defenders were blocked by the guardrails of the very tools they needed. The team ultimately finished the forensics on GLM 5.2, an open weight model from a Chinese lab running on their own hardware, which had the added benefit of keeping attacker data and touched credentials inside their environment. Ironically, the end state was an American frontier model performing the intrusion and a Chinese open weight model performing the investigation. That outcome should factor into any assumption that hosted US models will be available as defensive tooling when they are needed most.
The labs are responding, and it cuts both ways
Anthropic’s Project Glasswing gives vetted partners early access to its Mythos model for defensive security work, and those partners have already surfaced over 10,000 high and critical flaws. OpenAI’s Daybreak initiative does the same with cyber tuned models like GPT-5.6-Cyber, plus a Trail of Bits program aimed at helping open-source maintainers turn findings into fixes. For enterprises that can qualify, both programs are realistic options for getting ahead of the storm. The catch is that the same class of capability will inevitably end up in attackers’ hands, and every published finding that does not get patched effectively expands the exploitable attack surface.
The other caution is that these programs are gated, and no IR plan should depend on a third party’s refusal classifier behaving predictably in the middle of a live incident.
The policy risk that could make it worse
Open weight models are currently the most practical base for security specific harnesses such as forensic pipelines, log reconstruction, malware triage, and IR copilots. These tools must process genuinely hostile content without refusing, and they have to run on infrastructure you control so that attack data never leaves your environment.
There is an active policy debate about restricting open models in the US, and it is worth thinking through what that would actually change, because the capability does not disappear when access is restricted domestically. Adversaries would retain their unrestricted models while US defenders would lose the class of model they can currently run in these harnesses. Whatever your view on open model policy more broadly, the defensive use case needs a seat at that table.
Resiliency is the strategy
If the gap keeps widening and our best tools can fail us mid-incident, then a strategy built entirely on prevention is not going to hold, and compromise must be treated as an operating assumption rather than a tail risk. That reframing points the investment toward resiliency:
- Incident Response - Can you detect, contain, and eradicate quickly when (not if) an unpatched vuln gets exploited, and after Hugging Face, does your IR plan account for AI tooling that refuses to help? Vetting an open weight model on your own infrastructure before you need it, rather than during the incident, is now a reasonable line item in IR readiness.
- Disaster Recovery - Are your backups immutable, tested, and restorable in a timeframe the business can survive, keeping in mind that an RTO on paper is not the same thing as a recovery time proven in a drill?
- Business Continuity - When a critical system goes down, does the business know how to keep operating, and are the workarounds documented and exercised rather than assumed? This is the discipline where security planning extends beyond IT and into core business operations.
Closing the gap with automation
At minimum, organizations should stand up AI driven, continuous, autonomous vulnerability discovery against their own environments so they find their exposures before someone else’s agent does. Point in time scanning on a quarterly cadence is not going to keep pace with adversaries operating continuously at machine speed.
Discovery is the easy part for organizations to embrace and accept, while automated remediation is where most organizations will hesitate, and for understandable reasons.
The uncomfortable reality is that humans are now the chokepoint, because even when a fix exists and an agent can apply it, the speed at which humans agree becomes the rate limiter. Change advisory boards, review meetings, approval chains, and maintenance windows were all built to manage risk at human speed, and a process that takes two weeks to approve a routine patch is functioning less as a control and more as a queue.
Autonomous remediation is a risk tradeoff, and IMHO it is now the right one for most organizations. The failure modes are real, since agents can go rogue, cheat by burying false negatives, and break things in production. Risk decisions are comparative though, and in most shops the backlog is already so large, and growing so fast, that the residual risk of agent error is smaller than the accepted risk of leaving thousands of known exploitable findings open for months. Doing nothing at machine speed is also a risk decision, just one that nobody formally signed off on.
You manage the tradeoff with architecture rather than blanket approval gates:
- Make business critical systems read only for agents - For payment infrastructure, safety systems, and core revenue platforms, agents can discover and recommend but a human gate controls any change, which concentrates scarce human review capacity on the systems where the business impact of an error is genuinely unacceptable.
- Let agents remediate on their own everywhere else - Where the blast radius of a bad change is recoverable and the cost of delay is the bigger risk, the math favors letting the agent proceed and validating the result afterward.
- Automate the validation, not just the fix - Apply the same SDLC discipline we demand of humans, where the patch goes to UAT, automated acceptance and regression tests run against it, and it promotes to prod only on a pass. This also counters the cheating problem, since success gets measured by independent testing rather than the agent’s self-report.
Done right, humans are not removed from the loop so much as moved to the loops that matter, namely policy, tiering decisions, exception review, and auditing outcomes.
What this means in practice
Questions I would start with if I were pressure testing a program today:
- When did you last run a full IR tabletop with executive decision makers, not just the SOC?
- If your hosted AI tools refused to process attack artifacts mid incident, what is your fallback, and have you tested it?
- Have you done a complete restore from backup in the last twelve months, and did it hit your RTO?
- Is anything continuously hunting for your own vulnerabilities, or are you still waiting on scan windows?
- How long does change approval take for a routine security patch, and is that latency on your risk register?
- Have you tiered your environment so agents know where they can act on their own and where a human gate applies?
- Does your board understand that a growing backlog is a structural reality, not a failure by the security team?
Nobody is going to patch everything, and the organizations that come through the storm in good shape will be the ones that can absorb an incident, keep operating, and rely on defensive AI tooling that was vetted and tested before it was needed. Resiliency has moved from being the backup plan to being the strategy itself.
I am curious what others are seeing in their own programs and what pain points you are experiencing, particularly whether remediation is keeping pace with discovery and whether your IR team could count on its AI tooling in a live incident.