Google Cloud has created a $250,000 “Root-in-Cloud” vulnerability reward for researchers who can demonstrate a path to full administrative control of an arbitrary customer organization or project. The new top tier, announced October 29 and highlighted in security coverage Monday, is not a general bonus for a severe cloud bug. It is reserved for attack chains that cross the platform’s strongest tenant and identity boundaries.
To qualify, a report must show control equivalent to the roles/owner role or complete Identity and Access Management control. The path cannot rely on an existing foothold in the target, stolen or phished credentials, social engineering, user interaction, or a specially prepared victim project. In other words, a convincing report has to expose a weakness in Google Cloud’s architecture rather than a customer configuration mistake.
The unusually narrow criteria make the reward more useful than its headline number suggests. Google is directing its largest cloud payout toward cross-service logic flaws, tenant-isolation failures and trust relationships that ordinary scanners are poorly equipped to understand. At the same time, the company is dealing with a much larger volume of automated vulnerability submissions without a corresponding rise in valid reports.
What counts as “root” in a cloud platform
Root access traditionally describes total control of one operating system. In a public cloud, the more consequential boundary is the control plane: the identities, policies and service relationships that decide who can create resources, read data, change billing, assign roles and delegate access across an organization.
Google’s test therefore focuses on arbitrary project or organization takeover. A vulnerability that gives an attacker powerful access only after a victim clicks a link, exposes a credential or misconfigures a service would not meet this tier’s requirements. A flaw that lets an outsider reach complete IAM control through a platform-level trust failure could.
The company has defined a deterministic proof mechanism so researchers do not need to touch a real customer environment. A designated service account provides a target identity, and a researcher can use cryptographic validation to prove unauthorized control. Google Cloud VRP lead Michael Cote described that approach as a way to make a high-impact result reproducible without putting customer projects or service availability at risk.
Reports involving remote code execution in Google’s underlying Borg production infrastructure, or what Google calls “root-in-prod,” will also be reviewed for the $250,000 tier. The rules become stricter at that point: researchers must stop as soon as they obtain code execution. Escalating privileges, extracting production credentials or moving laterally can disqualify the submission.
That stop condition matters because code execution on shared production infrastructure may create a plausible route to customer data or service disruption even when the researcher has not safely completed the chain. Google’s review panel will assess the entry point, execution context and exposed attack surface to decide whether arbitrary takeover is achievable.
Google is paying for signal while automation creates noise
The new tier arrives during a sharp change in vulnerability research. According to Google Cloud, the number of valid reports submitted to its cloud reward program has stayed stable over the past 18 months, while the total number of reports has grown dramatically. Automated tools make it cheaper to find suspicious code and generate polished submissions, but they also produce large volumes of plausible-looking false positives.
Google is not rejecting AI-assisted research. Cote said first-time researchers who combine human judgment with agentic tools are, on average, finding more interesting bugs than novices did two years ago. The distinction is between automation that helps a researcher build and validate an attack path and automation that merely produces a claim for someone else to investigate.
The company’s other bounty decision makes that contrast clearer. On October 1, Google paused product-vulnerability submissions to its Open Source Software VRP after what it called a significant increase in automated reports, most of which were invalid. Existing reports and open-source supply-chain submissions were not affected, and Google said it may still accept some issues in cloud-related repositories through the Cloud VRP. It plans to provide an update on the paused program in the first quarter of 2027.
Those two moves are not contradictory. Google is reducing intake where low-cost submissions overwhelm maintainers while raising the reward for a result that requires architectural knowledge, reproducible evidence and a controlled demonstration of impact.
What the bounty changes for security researchers
A researcher pursuing the top tier will need more than a scanner finding. The likely work sits in the seams between products: service-to-service authentication, delegated credentials, organization policies, cross-project resource references, control-plane APIs and assumptions about which Google-managed identity is trusted by another system.
A strong report also has to separate platform behavior from customer error. Cloud security findings often begin with an overbroad role or exposed credential, but those starting points are explicitly excluded from the $250,000 reward. The qualifying path must work against an arbitrary target without pre-existing access or a special setup.
Researchers who reach underlying production infrastructure face an additional evidence problem: they must prove enough to establish impact while stopping before risky post-exploitation. Google recommends contacting the program when a researcher is close to the boundary and is uncertain whether another test would violate the rules.
The lesson for enterprise vulnerability programs
The announcement is also a useful model for companies receiving their own surge of AI-assisted reports. Intake forms need evidence requirements that machines cannot satisfy with fluent prose alone: a reproducible test case, affected version, observed authorization boundary, expected versus actual behavior and a minimal proof of impact.
Triage systems should route architecture-level claims to engineers who understand identity and service dependencies instead of grading every report by the same severity template. Clear stop rules are equally important. Researchers need to know when demonstrating another step would create unacceptable exposure, and the program needs a way to evaluate plausible impact without demanding unsafe escalation.
Google also warned that automation is compressing the time between public disclosure and working exploitation, particularly for already-published vulnerabilities. More efficient report filtering cannot become an excuse for slower remediation. The practical target is a pipeline that rejects unsupported claims quickly, preserves credible reports and moves confirmed issues into mitigation before technical details become an attacker’s shortcut.
The $250,000 figure will attract attention, but the more important change is what Google is asking researchers to prove. In an era of cheap vulnerability claims, the premium is moving toward evidence of a real trust-boundary failure, gathered without turning the validation process into an incident.
