Google’s Project Zero will publish the bugs it finds a fixed number of days after reporting them, whether or not the vendor has shipped a fix, and it will shorten that window in two steps to 30 days by January 2028. The team’s 13 November post says AI is the reason: “LLMs have increased the speed at which attackers can find and exploit vulnerabilities”.
The new policy is “Full 90” from 13 November, “Full 60” from 2 February 2027 and “Full 30” from 3 January 2028. It replaces the “90 + 30” policy in place since 2021, which gave vendors up to 90 days to fix a bug plus 30 days of soak time, or 120 days in all. Full 30 is 75% shorter than that maximum, by our arithmetic.
Business Pill · Least Privilege
A short Business Engineer explainer on giving software and AI agents only the access a task needs. It teaches the general security idea only and does not discuss Project Zero’s policy.
The key insight: As we read the post, Project Zero is turning disclosure from a negotiation into a fixed clock: details go public 90, then 60, then 30 days after a report, whether or not a fix has shipped, a 75% cut from the old 120-day maximum, by our arithmetic.
Under the new rule, “Vulnerabilities will be disclosed X days after they are reported to the vendor”. Whether a bug is fixed is no longer part of the decision. The team says it will “track whether bugs are fixed and communicate if they are not”, but “this will not be a decision point in our policy”.
The post also removes “most ‘special cases’” from the policy, including the grace period and the variant policy. Three exceptions remain: bugs actively exploited in the wild, which follow Google’s application security disclosure policy; bugs already made public by others; and cases where the vendor asks for disclosure. Project Zero says it has granted rare exceptions before, including Spectre and Meltdown, and “will continue to do so in the future”.
The post says severity does not change the clock: “A vulnerability’s severity does not affect the likelihood that it will be discovered by attackers, only its impact on users”. Project Zero says it reports only bugs “with substantial severity and demonstrated security impact”.
Maximum days from a bug report to public details under Google Project Zero’s policies: 90 + 30 since 2021, Full 90 from 13 November 2026, Full 60 from 2 February 2027 and Full 30 from 3 January 2028. The 120-day total and the 75% cut are our arithmetic.
The AI Rationale, in Project Zero’s Words
The post makes three claims about AI. On speed, LLMs raise “the risk that multiple parties, including malicious ones, discover the same bug”. On patches, the team writes that “zero patch-to-exploitation time is a reasonable, though imperfect, model of attacker behavior”, so “Patch soak time is no longer meaningful”.
On volume, Project Zero says: “We are finding several vulnerabilities a week in targets where we once found a few vulnerabilities a year”. It adds that the parts of the old policy that needed negotiation with vendors, such as agreeing whether a bug was fixed, “are quickly becoming unmanageable”. The new rule is meant to be automated by both sides.
Our earlier coverage reports related figures from other organisations. Our piece on Claude Mythos listed 10,000 critical vulnerabilities found in its first month. The Zero Day Initiative published 47 zero-day advisories on Meta’s open-source AI research libraries on 11 November, as our Meta piece reports. And OpenAI put up pages for AI penetration-testing and patch-preparation agents on 12 November, per our Daybreak piece.
Days from 14 November 2026 until each Project Zero disclosure window takes effect: Full 90 from 13 November 2026, Full 60 from 2 February 2027, Full 30 from 3 January 2028. Day counts are our arithmetic on the dates in Project Zero’s post.
Why the Steps Are Gradual
Project Zero says it asked the vendors it reports the most bugs to for feedback. Their main concern was that an immediate change “could harm users by making unfixed vulnerabilities available to attackers while vendors are in the process of improving their remediation processes and technology”.
Vendors raised two other points, the post says: a strict deadline could push teams to fix newly reported bugs ahead of more severe ones, and some might “accept that they cannot fix bugs within the deadline and don’t attempt to”. Project Zero calls its schedule “challenging but realistic”. By our arithmetic, vendors have 80 days at Full 90 before Full 60 starts, and Full 60 then runs for 335 days.
For vendors, the cut is 60 days off the 90-day fix deadline, or 67%, by our arithmetic, with no soak time after a patch. Project Zero also asks vendors to shrink the “patch gap”, the time between a fix being released and the user installing it, “either by reducing patch rollout time or using other strategies to protect users while remediation is in progress”.
The Structural Read
As we read it, the cost moves to vendors’ patch pipelines: Project Zero says “Patch soak time is no longer meaningful” and asks vendors to reduce the “patch gap” as well as fix faster.
As we read the volume claim, the team expects more reports, not fewer: it says it is finding “several vulnerabilities a week in targets where we once found a few vulnerabilities a year”, and that case-by-case negotiation is “quickly becoming unmanageable”.
Google Project Zero, Policy and Disclosure: 2026 Edition, 13 November 2026
“A vulnerability reported today presents a much higher immediate risk to users than one reported last year.”
Three Implications
FOR SOFTWARE VENDORS Project Zero’s fix window for its reports drops to 60 days on 2 February 2027 and 30 days on 3 January 2028, with no soak time after a patch.
FOR SECURITY BUDGETS The post asks vendors to cut patch rollout time or use “other strategies to protect users while remediation is in progress”, which is work on deployment, not only on finding fixes.
FOR READERS TRACKING AI IN SECURITY Project Zero links the change to LLMs finding and exploiting bugs faster; our Daybreak piece covers AI agents sold for testing and patch preparation.
The framework says of what a technology can do and what users can actually do with it: “They are not the same curve, and the gap between them — what the platform makes possible versus what the product surfaces — has a name.”
As we read it, Project Zero describes a similar gap in security: AI raises how fast bugs are found, while vendors’ fixing and rollout processes set how fast users are protected. The framework does not discuss Project Zero or disclosure policy.
What Is Not Established
The post gives no count of how many bugs Project Zero reports a year, how many vendors it consulted, or how often vendors missed the old 90-day deadline. It does not say whether other Google security teams will adopt the same windows. Hardware bugs may still get exceptions, at Project Zero’s discretion.
The 10,000, 47 and Daybreak figures come from our own earlier pieces on other organisations and are not Project Zero data. We did not contact Google or any vendor for this piece.
This Week In The AI Supercycle
The Great Convergence of Capital, Power, and Geopolitics
This week’s issue: for two years the AI build-out was priced as a supply story, and last week as a credit story. This week it was priced as a permission story, and the answer arrived as a cost, not a ban.
Project Zero is moving from a deadline vendors could negotiate to a fixed clock: 90 days now, 60 from 2 February 2027, 30 from 3 January 2028, fixed or not. Its stated reason is that LLMs have made finding and exploiting bugs faster, and its own finds have gone from “a few vulnerabilities a year” to several a week in some targets. The next date to watch is 2 February 2027.
A note on sourcing. Google Project Zero’s policy post of 13 November 2026 was read in full on 14 November; all quotations are from it. The Claude Mythos, Zero Day Initiative and OpenAI Daybreak figures come from our own earlier pieces, each linked, which cite their primaries. Day counts and percentage cuts are our arithmetic. We did not contact Google or any vendor for this piece.
Gennaro Cuofano is a CRO and tech executive who has worked in AI since late 2015, starting with bringing NLP, natural-language generation, voice and chatbot products to the marketing industry. His background is in law and finance: he holds a Master's degree in Law and an International MBA with an emphasis on corporate finance (LUISS Business School and the University of San Diego, 2012), and worked as a financial analyst at a real-estate investment firm in San Diego and as an assistant controller. His work focuses on business model strategy, business engineering and, more broadly, structural analysis: how companies make money, read from their own filings. He created FourWeekMBA and leads research there and at The Business Engineer, his newsletter on AI and business strategy, with over 95,000 subscribers and more than 1,000 published analyses. His writing has also appeared on Entrepreneur (for example, How to Digitize a Family Business in Europe) and HackerNoon. Find him on LinkedIn and Substack. See how we source.
