Exploit Windows Hit 10 Hours in 2026, AI Red Teaming Races to Keep Up

Exploit windows for newly discovered vulnerabilities dropped to a median of 10 hours in 2026, The Hacker News reported in April, citing data from security automation firm Picus. That number is not a rounding error or a particularly bad quarter. It is roughly the length of a business day in London, and it means that an organization running a traditional quarterly penetration test is, by the time the report lands, defending against a threat landscape that has already turned over more than 200 times. The number also explains why the conversation around AI red teaming, adversarial robustness, and model evaluation has lurched from 'we should do more of it' to 'we need it continuous, automated, and capable of keeping pace with deployment cycles measured in hours' in the span of roughly eighteen months.

The shift is visible across the security vendor landscape. In late April, AI security platform DeepKeep rolled out Vibe AI Red Teaming, a capability the company describes as human-steered but dynamically executed, designed to simulate attacks against AI applications and agents rather than just the infrastructure underneath them. The same week, Suzu Labs announced its acquisition of Emulated Criminals, a boutique adversary emulation shop, explicitly to fold continuous validation into its AI-driven cybersecurity offerings. These are not isolated announcements. They sit inside a broader recalibration of what red teaming is supposed to accomplish when the target is not a network but a model, and when the attack surface includes prompt interfaces, retrieval pipelines, and multi-agent coordination paths that did not exist in the threat models most security teams wrote even two years ago.

The term 'AI red teaming' now carries two overlapping but distinct meanings, and the tension between them is productive but real. The first, inherited from cybersecurity, treats the exercise as an operational stress test: find the vulnerabilities, document the failures, patch, repeat. The second, born inside the alignment research community, treats red teaming as a window into model behavior, a way of surfacing what a system can do that its developers did not intend and may not have known how to specify against. The two traditions share tools and personnel, but they ask different questions, and they produce different kinds of failure reports. A security red team asks whether a model can be made to leak training data. An alignment red team asks whether a model can be made to strategically conceal its reasoning. Both are valid. Neither is sufficient alone.

This dual lineage is visible in the way the major labs describe their red-teaming work. VentureBeat reported in December 2025 that Anthropic and OpenAI have diverged in how they structure and disclose adversarial evaluations, with Anthropic emphasizing structured capability elicitation and detailed system cards while OpenAI has leaned toward broader, more automated red-teaming pipelines integrated into its deployment tooling. Neither approach is obviously superior in the abstract. But the divergence matters because thousands of enterprises now consume these models through APIs and fine-tuning endpoints, and they inherit whatever testing philosophy, and whatever gaps, the provider baked in upstream. An enterprise that assumes the model has been adversarially hardened may not realize that the hardening covered a specific set of attack classes and left others unexamined.

The automation wave is both inevitable and uneasy. F5 made headlines in January with a platform update that automates AI red teaming and guardrail enforcement, promising to cut enterprise risk at scale by running continuous, programmatic probes against deployed models and their surrounding application logic. DeepKeep's Vibe AI Red Teaming, despite the 'vibe' branding borrowed from the vibe-coding phenomenon, is fundamentally an automation play: a platform that generates attack templates, executes them against AI applications, and surfaces results through a governance dashboard that compliance teams can actually read. The pitch to the enterprise is straightforward: you cannot hire enough red-team operators to test every model version, every fine-tuning checkpoint, every agent decision path manually, so the alternative is tooling that runs while you sleep.

But 'runs while you sleep' is also where the hard methodological questions begin, because an automated red team is only as adversarial as its attack library, and attack libraries have a tendency to fossilize on known failure modes. A red-team platform that tests for prompt injection, jailbreaking, and data exfiltration but does not test for multi-turn persuasion, tool misuse across agent boundaries, or reward hacking in reinforcement-learning loops is a compliance checkbox, not an adversarial evaluation. And the gap between those two things is where the safety claim ends and the marketing claim begins, a distinction that the industry has been slow to make legible to buyers.

The purple-teaming debate sharpens this further. The Hacker News piece that opened with the 10-hour exploit window made a more provocative argument: that most 'purple teams' in enterprise security are not genuinely collaborative red-and-blue exercises but merely co-located teams sharing a Slack channel. True purple teaming, the article argued, requires the blue team's detection logic to be updated in real time based on red-team findings, and that feedback loop needs to be automated to close inside a single shift. Applied to AI, the analogy is instructive. If a red team discovers that a model can be jailbroken by a specific syntactic pattern, how fast does that finding propagate into the guard model, the content filter, the prompt sanitizer, and the training data for the next fine-tuning run? If the answer is 'next quarter's model update,' the red team is producing research, not defense.

Steve Riley, a Field CTO at Netskope, made a related point in a Forbes Technology Council column in March, arguing that AI jailbreaking is structurally inevitable because 'language models are pattern matchers, not policy engines' and that security resources are better spent protecting the data layer than trying to guarantee model behavior at the output boundary. It is an argument with genuine force, partly because it is falsifiable: every major model release in the past two years has shipped with jailbreaks discovered within days or hours of public availability, and the pattern has not meaningfully changed despite substantially increased red-teaming investment by the labs. If the goal is zero jailbreaks, red teaming is losing. If the goal is making jailbreaks expensive and noisy enough that they do not scale into economically viable attack vectors, the scorecard is more mixed.

Language models are pattern matchers, not policy engines. Red teaming them for jailbreaks is necessary but insufficient; the real security investment should be in the data layer.Steve Riley, VP and Field CTO at Netskope, in Forbes Technology Council, March 2026

This framing exposes a tension that runs through the entire red-teaming discourse of 2026: the difference between interventions that are cheap to ship and those that require actually slowing down. Automated red-teaming platforms, guardrail APIs, and continuous adversary emulation are all software products. They can be bought, integrated, and demonstrated to auditors without changing the fundamental velocity at which models are trained and deployed. The Suzu Labs acquisition of Emulated Criminals, for example, is explicitly pitched as a way to add continuous adversarial validation 'without slowing down innovation cycles.' It is a line that sells well. But it also raises the question of whether the validation is genuinely adversarial or merely adversarial-themed, a distinction that the market currently lacks a vocabulary for.

The interventions that require actually slowing down look different. They include mandatory human-in-the-loop review for high-stakes agent actions, red-teaming gates that must be cleared before a model version can be deployed rather than after, and adversarial training budgets that are proportionate to the model's capabilities rather than to the security team's headcount. These are not products. They are process changes, and they are harder to announce in a press release. The Cloud Security Alliance announced in early May that it is expanding its agentic AI governance work to include a catastrophic risk initiative and a CVE-style taxonomy for AI vulnerabilities, which suggests that the standards bodies are beginning to converge on a framework that could make these process-level interventions auditable. But standards move slowly, and models do not.

What the eval actually measures

Every red-teaming methodology embeds assumptions about what is worth measuring, and those assumptions are rarely surfaced in the results. A platform like DeepKeep's Vibe AI Red Teaming ships with a library of attack templates: prompt injection, role-playing boundary violations, PII extraction, toxicity elicitation, agent tool misuse. Testing against that library tells you whether the model fails on those specific axes under the specific conditions the templates encode. It does not tell you whether the model fails on an axis nobody thought to template, whether two benign queries chained together produce a harmful result, or whether the model is capable of something the red-team operators did not know to look for because the capability is emergent and poorly documented. This is the fundamental asymmetry: red teams can only test for what they can specify, and specification requires imagination, which automation can accelerate but not replace.

The Anthropic approach, as characterized in the VentureBeat analysis, leans into this limitation explicitly, structuring red-teaming exercises around capability elicitation, which asks what the model can do under optimal conditions, rather than passing a fixed set of test cases. OpenAI's approach, by contrast, emphasizes coverage: running more tests across more scenarios, including automated fuzzing of input spaces. The approaches are complementary in theory but in practice they produce different kinds of system cards, different kinds of residual risk, and different downstream expectations. An enterprise that reads an Anthropic system card and an OpenAI system card side by side may not realize they are reading answers to different questions.

This is where the 'cheap to ship' versus 'actually slowing down' distinction becomes concrete. Automated red-teaming coverage is cheap to ship. It runs in CI/CD, it produces dashboards, it integrates with existing governance workflows. Capability elicitation is not cheap to ship. It requires researchers who understand the model's architecture deeply enough to hypothesize about what it might be able to do, then design protocols to surface those capabilities, then iterate when the first protocol fails. It requires time, expertise, and a willingness to sometimes conclude that a model is not ready, which is an expensive conclusion for a product organization to accept. The pressure to treat automated coverage as a substitute for depth is immense, and the industry does not have a good answer for it.

The NIST draft Cyber AI Profile, published in December 2025, gestures toward solving this by proposing a framework that maps AI-specific risks to existing cybersecurity governance structures, effectively asking organizations to treat model-level vulnerabilities with the same institutional seriousness as network-level vulnerabilities. But the profile is a draft, and drafts do not create compliance obligations. In the meantime, the market is doing what markets do: filling the gap with products that promise to make red teaming fast, continuous, and integrated, while leaving the question of depth to individual buyers who are, in many cases, not equipped to evaluate it.

The adversary emulation frontier

The Suzu Labs acquisition of Emulated Criminals points toward a different model, one borrowed from military red-teaming doctrine, where the adversary is not a library of attack templates but a continuously evolving threat actor whose behavior is modeled, updated, and redeployed against the target system in near-real-time. In traditional cybersecurity, adversary emulation means replaying the tactics, techniques, and procedures of known threat groups, using frameworks like MITRE ATT&CK to structure the exercise. Applied to AI systems, the same logic would mean modeling specific adversarial personas: the financially motivated prompt engineer trying to extract proprietary training data, the state-affiliated actor probing for strategic reasoning capabilities that could be exploited, the insider threat with API access attempting to poison a fine-tuning dataset. Continuous adversary emulation against AI systems is a genuinely hard problem, because the attack surface is not a network topology but a probability distribution over token sequences, and the 'exploit' is often a linguistic pattern that worked last week but does not work this week because the model has been silently updated.

This is where the automation story gets genuinely interesting, because it suggests that the most valuable red-teaming tooling may not be the platform that runs the tests but the platform that models the adversary. A red-team platform that can generate new attack strategies based on observed model behavior, rather than replaying a static library, is closer to what the exploit-window reality demands. The 10-hour median reported by The Hacker News is not a ceiling; for some vulnerability classes it is closer to 90 minutes. If the red team's attack library is updated on a quarterly basis, it is defending against a threat landscape that is 2,000 generations out of date. That math is brutal, and it explains why the acquisitions, the automation plays, and the governance frameworks are all converging on the same conclusion: red teaming has to become continuous, or it stops being red teaming and becomes historical research.

It also explains the renewed interest in purple-teaming architectures for AI. If the blue team, meaning the guard model, the content filter, and the deployment policy engine, can ingest red-team findings within the same operational window that the exploit is active, then the red-to-blue feedback loop becomes a real-time defense mechanism rather than a post-mortem. This requires technical infrastructure that most organizations do not yet have: real-time telemetry on model inputs and outputs, automated triage that can distinguish a novel jailbreak from a false positive, and deployment pipelines that can push a guard-model update without taking the application offline. None of this is science fiction. All of it is hard. And all of it is downstream of a single decision: whether the organization treats AI red teaming as an audit function or an operational function. The product announcements of 2026 are overwhelmingly betting on the latter.

A May 2026 report aggregated by MSN identified AI red teaming as one of the top strategic priorities for organizations this year, alongside workforce resilience, framing both as responses to a threat environment that has accelerated past the capacity of manual processes. The report is one data point among many, but it captures the ambient mood: red teaming has moved from a specialized research practice to a board-level concern in roughly the time it takes to train a single large model generation. The question that remains unanswered, and that no product announcement has yet resolved, is whether 'red teaming' at board-level scale means the same thing as it does in the research lab, or whether the term is expanding to encompass so many different activities that it risks losing the adversarial edge that made it valuable in the first place.

The checkpoint to watch is not the next product launch or acquisition. It is whether the system cards published alongside the next generation of frontier models begin to distinguish between automated coverage metrics and adversarial depth, between tests that the model passed because it is robust and tests that the model passed because the attack library was stale. If that distinction becomes legible to downstream consumers, the market for red-teaming tooling will bifurcate into genuine adversary emulation on one side and compliance reporting on the other. If it does not, the term 'red teaming' will continue its drift toward meaning whatever the vendor selling it needs it to mean, and the 10-hour exploit window will keep shrinking regardless.