Google Cloud has added a new top bug bounty: $250,000 for a "Root-in-Cloud" finding. That means a flaw that gives a researcher full control over any Google Cloud organization or project, starting from no access at all. The announcement came on October 29 in the Cloud CISO Perspectives newsletter. Google ties the change directly to AI. Automated tools now send in far more reports, and Google says it wants to pay more for the deep, human-led work that those tools still miss.
What the new tier pays for
The Root-in-Cloud reward is part of the Google Cloud Vulnerability Reward Program (VRP). To earn it, a researcher must show "full administrative control, the equivalent of 'roles/owner' or complete IAM control, over arbitrary Google Cloud organizations or projects with no prior access or special project setup."
Google lists three things the exploit path cannot depend on:
- Pre-existing access or footholds in the victim project.
- Leaked, phished, or stolen credentials.
- User interaction or social engineering.
The kinds of bugs Google names are tenant-isolation bypasses and complex cross-service logic flaws. Google Cloud CISO Chris Betz writes that finding them "requires human creativity, intuition, and rigorous systems analysis combined with the power of agentic systems."
Reports that show remote code execution in Borg, Google's underlying production infrastructure, or that achieve root-in-prod, will be checked by the VRP panel for Root-in-Cloud eligibility automatically. There is a hard stop. Researchers must halt all probing as soon as they get any execution in Borg. Escalation, pulling production credentials and lateral movement are banned and lead to disqualification. The panel then decides whether a full tenant or project takeover was possible from that entry point.
To keep tests away from real customers, Google built what it calls a deterministic proof-of-root mechanism. VRP lead Michael Cote explains that it uses "a designated service account. Researchers can cryptographically prove unauthorized access against that identity." The technical criteria are on the VRP rules page.
Why AI changed the math
The most useful part of the post is the Q&A with Cote. He says AI tools have changed the program's intake, "though not in the way many people assume." In his words: "While the number of valid vulnerability reports submitted to the Google Cloud VRP has remained stable over the last 18 months, the total number of reports has grown tremendously."
So the extra volume has not produced more real bugs. Cote also says "automated scanners generate a high volume of low-impact noise." At the same time, he says, "first-time researchers who pair human intuition with agentic tools are finding, on average, more interesting bugs than novices did two years ago." The new tier is Google's way to point that energy at the hardest targets.
Betz frames the problem the same way. "In an era when automated research has made it more challenging to verify authentic vulnerabilities, we have a critical need to boost high-level, human-led research that can transcend automated-only discovery," he writes.
The data behind the worry
Betz points to research from the Google Threat Intelligence Group (GTIG). In a September 30 report, GTIG found that disclosed vulnerabilities per month rose from 5,045 in January 2026 to 10,477 in July and 10,740 in August.
GTIG adds context that matters. Raw counts can mislead: the report says CVEs with "Linux Kernel" in the description alone made up about 5,000 disclosures from January to August 2026, with no observed in-the-wild zero-days. Exploitation grew too, from an average of 10.5 vulnerabilities a month in 2025 to 18 a month from January to August 2026. Zero-day exploitation rose only a little, from 8 to 11 a month. GTIG suggests that most of the growth came from fast weaponization of n-days, which are flaws that are already public.
That is the link Cote draws. He notes that "open source accounts have suggested that threat actors are using LLMs to rapidly turn newly-public vulnerability details into working exploits."
A warning about rushed disclosure
Cote also uses the post to push back on a pattern he says is starting to show. "Because LLMs lower the barrier to finding bugs in source-available software, researchers worry that waiting to verify risks will allow someone else to be first to publish," he says. He adds that the same pressure "can tempt even established security companies to disclose unmitigated vulnerabilities without coordination, and that rush puts our users directly at risk."
He points back to the 90-plus-30-day disclosure policy that Google's Project Zero helped establish. He says that "autonomous detection and exploitation capabilities make following coordinated disclosure more important than ever."
His advice for other security teams has three parts:
- Prepare triage for agent-generated reports, so teams can separate "plausible-sounding hallucinations from real security risks."
- Patch faster once a flaw is public, since automation shortens the time from disclosure to a working exploit.
- Hold vendors and partners to high standards of coordinated disclosure.
Why it matters
The new tier shows how Google now values bug reports. In its view, AI tools make routine reports common, and the scarce work is in architecture-level flaws. It also comes in a busy week for AI security. Google is giving its new Gemini 4 Carbon model to cyber defenders first, and Anthropic described a model that builds exploit chains for Chrome, Safari and Linux. As models find more bugs, bounty programs have to decide what still deserves a premium. Google's answer, for now, is full cloud takeover found with human insight plus agentic tools.
The post does not say when the first Root-in-Cloud award could be paid, or how many reports Google expects to qualify.
