The 3-5 Month Window Is a Comforting Lie: What Palo Alto's AI-Cyberattack Warning Actually Says
Written by the Rafter Team
On May 13, CNBC ran a piece quoting Palo Alto Networks CTO Lee Klarich on what he called a "narrow three-to-five-month window for organizations to outpace the adversary before AI-driven exploits start to become the new norm." The article catalogued the supporting events: Anthropic seeding its new Mythos model to a closed group of defenders (Palo Alto Networks, CrowdStrike, Amazon, Apple, and JPMorgan) to find and fix vulnerabilities ahead of broader release; Google's threat intelligence group disclosing it stopped an attempt to use AI for a "mass exploitation event"; OpenAI shipping a cyber-tuned model called GPT-5.5-Cyber and a defender program called Daybreak in the same week; the White House convening banks and hyperscalers about the same problem.
Treat the 3-5 month timeline as a marketing artifact. The load-bearing sentence in the same article is Klarich's admission: "these models are likely even better at finding vulnerabilities than we initially realized." That is a vendor CTO conceding the security industry's calibration of model capability was wrong, in the direction that favors attackers. The window has already moved more than the headline claims.
The line that does the work
Klarich's quote in full, from the CNBC piece:
The big question just a few weeks ago was: 'Are we overstating the model capabilities?' With more testing, I can confidently say we weren't. In fact, these models are likely even better at finding vulnerabilities than we initially realized.
That is not a timeline statement. It is a calibration statement. The security industry's working estimate of how good frontier models are at vulnerability discovery was wrong a few weeks ago. The error was in the direction that favors attackers, and the correction came from a vendor whose business model depends on accurate threat modeling.
The "3-5 month window" framing in the same article is the comfort blanket the audience needs to hear after that admission. It implies a runway, a planning horizon, a stretch of time when the existing budget cycle still works. The calibration admission says that runway already shrank, and the rest of the industry doesn't know by how much.
What the window framing assumes
The 3-5 month framing only makes sense if you accept two assumptions:
- Attackers start their clock today. They run an AI-augmented scanner against your codebase tomorrow, find a vulnerability in month two, weaponize it in month three, and by month five it is mainstream. You have until then to patch.
- Your existing code is in a holding pattern. Whatever you shipped last sprint, last quarter, or last year, is safe until the attacker's tooling becomes capable enough to scan it.
Both assumptions fail on the same axis. Every line of code you have already published — to a public repo, a customer's binary, a marketplace, an SDK, a container registry — is already inside the attacker's inference window. The model does not need to wait for some future capability. It needs to run. By Klarich's own quote, the capability arrived sooner than the industry's calibration assumed.
The window for shipped code is zero. The only window you actually own is the gap between writing a line of code and an attacker reading it. That gap is your patch cycle, and most teams' patch cycles are measured in quarters, not weeks.
Why the early-access list is the real story
The list of companies Anthropic seeded Mythos to is the most operationally important detail in the article: Palo Alto Networks, CrowdStrike, Amazon, Apple, JPMorgan. Five companies. Two security vendors, three of the largest enterprises in the world by code surface and security budget.
All five have:
- Dedicated red teams with hundreds of full-time engineers.
- Internal application-security organizations with formal pre-disclosure remediation programs.
- The legal infrastructure to absorb a private capability that finds undisclosed bugs in their products without triggering public disclosure timelines.
- Direct executive-level relationships with frontier model labs.
None of them ship most of the software running in your environment. Your auth provider, your observability vendor, your container base images, your CI runners, your AI agent frameworks, your open-source utility libraries — those are shipped by companies and maintainers that are not on the early-access list and will not be.
The structural consequence: the third-party stack in your environment runs on a slower defender curve than the in-house code at named hyperscalers. If you want a predictive model for where the next AI-discovered vulnerability surfaces, weight your estimate heavily toward third-party packages and SDKs, especially in the AI tooling layer where the rate of new code shipped has outrun the rate of code review.
Virtual patching, honestly assessed
Klarich mentions virtual patching as part of Palo Alto's response. Virtual patching is inline mitigation at the WAF or EDR layer: you do not fix the bug in the code, you block the exploit pattern in transit. It is a real and useful tool, and it is the right tool for the window between disclosure and a real patch shipping.
Virtual patching has a structural limit, though. It only helps for vulnerabilities someone has already disclosed and turned into a detection signature. The threat model the article is actually warning about — an AI-augmented attacker finding a previously unknown vulnerability and exploiting it before public disclosure — does not produce a detection signature until after the first wave of exploitation. The signature is downstream of the discovery. Virtual patching covers the bridge between disclosure and patch. It does not address the discovery problem itself.
The defender-side equivalent of what the five named companies are doing with Mythos right now is "run an AI-class code-security review on your own code before anyone else does." That is the only move that runs at attacker speed.
What this means for everyone not on the early-access list
Most engineering organizations are not on the early-access list and will not be. The realistic version of the defensive posture, given the capability gap, is:
Treat every PR as the disclosure event
A vulnerability introduced in a PR and merged into main is, from the attacker's perspective, a public disclosure of the bug. You do not get a private patch cycle on public code. The discipline that worked when vulnerabilities were expensive to find — "we'll do a security review at the end of the quarter" — does not work when the cost of finding the bug has collapsed. Block the bug at PR time, or accept that the disclosure clock is already running.
Stop relying on annual audits and quarterly pen tests as your code-security control
Annual audits and quarterly pen tests are valuable for adversary simulation, threat modeling, and exposure analysis. They are the wrong control for the bug class the article is talking about, because their cadence does not match attacker cadence. Use them for what they are good at. Use a continuous in-pipeline control for the discovery-speed problem.
Audit your third-party surface harder than your own code
The third-party stack is on the slower defender curve. Open-source dependencies, base images, SDKs, and especially AI agent frameworks are where the discovery deltas will land first. The same calibration error that Klarich admitted to applies double to your dependency tree, because the maintainers of those packages do not have the same red-team coverage your in-house code does.
Have a real virtual-patching capability for the disclosure-to-patch gap
Not as the primary control, but as the bridge between "exploit is public" and "real fix is deployed." If you do not have a WAF, EDR, or runtime layer that can absorb a hotfix signature for a vulnerability you discovered yesterday, you have a hard dependency on shipping a code patch faster than your normal release cycle, which most teams cannot do.
Stop pretending the timeline is 3-5 months
Treat the shipped-code window as already closed and the in-progress-code window as the only one you control. Run the controls that operate inside that in-progress window.
Where Rafter fits
Rafter (rafter.so) was built for the PR-time gate. It runs a remote SAST and SCA pass over a diff, plus a secrets check, against the bug classes that scale when attackers have AI. rafter run --mode plus adds agentic deep-dives for code paths where pattern matching is not enough — the cases where the bug is in the interaction between two well-written components rather than in either one alone. rafter secrets . is a local-only secrets check that needs no signup and no API key.
Rafter does not replace the rest of your security program. It does not replace a real adversary-simulation pen test, a threat-modeling exercise, an SDL, or a runtime telemetry investment. What it does is run the one control that has to run at attacker speed: a security review of every change to your code, before that change ships, in the place where the attacker's discovery clock starts.
The reason that matters now and did not matter as much three years ago is the line Klarich slipped into the CNBC piece. The models are likely even better at finding vulnerabilities than the industry realized. If the discovery side of the problem just got cheaper by an order of magnitude, the defensive side has to move from periodic to continuous. That is not a 3-5 month problem. That is a "next PR" problem.
The summary
The 3-5 month framing in the Palo Alto warning is a planning convenience. The real signal in the same article is the calibration admission three paragraphs down. Read that admission as: the industry's threat model for AI-discovered vulnerabilities was wrong on the timeline that matters, and the correction is to assume attacker-side discovery is already cheap.
The consequences flow from that one premise. Shipped code is already in scope. Third-party code is on a slower defender curve. Virtual patching is a bridge, not a solution. The only durable control is reading your own code before someone else reads it, on every change, at the speed the attacker's tools now run.
Pick the controls that match that speed. Stop measuring your patch cycle in quarters. Stop waiting for the window to close — it already did, on most of the code in your environment, on the day the models got better than the industry thought.
Further reading
- Rafter is Glasswing for the rest of us — What frontier-model vulnerability discovery means when you are not on the early-access list.
- The AI agent attack surface in practice — Five disclosed incidents that show where AI-tooling discovery deltas have already landed.
- Shift left security guide — How to move security controls earlier in the development cycle.
- Vulnerability scanning guide — Tools, types, and how to choose scanners given the capability shift.
- A year of AI developer-tool supply-chain attacks
- AI security beyond prompt injection
- Vibe-coding security audit, Q2 2026