Google Root-in-Cloud Bounty: What $250,000 Now Rewards

Security programs are starting to pay most for the work automation can't easily do. Google Cloud has added a $250,000 Root-in-Cloud reward to its Vulnerability Reward Program, a new top tier aimed at research that shows full administrative takeover of a cloud tenant. It is a clear signal about what defenders value now: deep architectural thinking, helped by AI agents but led by people.

• Top payout: $250,000 for demonstrating owner-level or complete IAM control over arbitrary Google Cloud organizations or projects.
• Excluded paths: anything relying on existing access, stolen credentials or social engineering.
• Also considered: remote code execution in Borg, Google's production infrastructure, and root-in-production reports.
• Safe testing: a proof-of-root check using a designated service account, so researchers avoid real customer projects.

What Qualifies for the Root-in-Cloud Bounty?

Let's break the bar down simply. To earn this reward, a researcher has to reach the equivalent of the "roles/owner" permission, meaning full control, over a Google Cloud organization or project they had no prior access to.

Google's rules remove the shortcuts. The exploit path can't depend on a foothold in the victim project, leaked or phished credentials, or tricking someone into clicking. That leaves the hard stuff: tenant-isolation bypasses, where one customer's boundary fails, and logic flaws that appear only when multiple cloud services interact.

Reports showing code execution in Borg automatically go to the program's panel for review. The rule there is strict. Researchers must stop probing as soon as they achieve execution, with no escalation, credential extraction or lateral movement. Anyone who keeps going is disqualified, because the point is to find the door, not walk through it.

How Does Google's Proof-of-Root Keep Testing Safe?

This is the smartest part of the design. A big reward can tempt people to poke at live systems, so Google built a validation path around that risk. Cloud VRP lead Michael Cote explains that researchers prove access cryptographically against a designated service account rather than testing exploits on customer projects.

Think of it like a capture-the-flag challenge with a flag planted on purpose. You show you reached it, and nobody's actual data has to be touched.

How Are AI Agents Changing Bug Bounty Programs?

The Q&A between Cote and Google Cloud CISO Chris Betz offers an honest view from inside a large program. Total submissions have grown tremendously, yet the number of valid reports has stayed roughly stable over the past 18 months. Automated scanners generate plenty of low-impact noise.

There is a positive side, too. Cote says first-time researchers who pair their own intuition with agentic tools are finding more interesting bugs, on average, than newcomers did two years ago. Google is betting that combination beats either people or tools alone, a theme that also runs through recent work like Claude's OpenSSH attack surface reduction.

Cote also asks the community to hold the line on coordinated disclosure, the practice of giving vendors time to fix a flaw before publishing it. With AI tools helping to turn public bug details into exploits faster, he says following the 90-plus-30-day policy matters more than ever.

What Should Security Teams Take From This?

You don't need to run a bounty program to borrow these lessons:

• Pay for impact, not volume. Reward findings by real-world consequence, since report counts are easy to inflate.
• Build safe proof into your rules. Give testers a sanctioned way to demonstrate access without touching production data.
• Triage for AI-assisted reports. Expect more submissions and plan how to separate signal from noise.
• Keep disclosure disciplined. Speed in finding bugs should not shrink the time defenders get to fix them.

Rules and validation details are on Google's Cloud VRP rules page. For more on defensive tools and practices, follow our AI security coverage.

Sources: Google Cloud Blog — October 29, 2026; SecurityWeek — November 2, 2026.