What Happened
In late 2024, Truffle Security discovered 2,863 live Google Cloud API keys exposed in public repositories. These weren't stolen credentials or phishing victims—they were legitimate billing keys that organizations had been using for years to track Google Cloud Platform usage.
The problem: Google silently repurposed these keys. When the company launched its Gemini AI API, these billing-only identifiers became full authentication tokens capable of accessing AI services and the data processed through them. Organizations that had treated these keys as low-risk billing identifiers suddenly held authentication credentials with access to sensitive data.
Google initially dismissed the report. After Truffle Security provided proof of concept, Google admitted the issue was "a bona fide bug" and began remediation.
Timeline
Pre-2024: Organizations generate and store Google Cloud API keys for billing and usage tracking. These keys are treated as low-sensitivity identifiers, often committed to repositories or shared across teams.
Gemini API Launch: Google introduces the Gemini AI API and enables it to accept existing Google Cloud API keys for authentication—without notifying key holders or requiring explicit opt-in.
Discovery: Truffle Security's automated scanning identifies 2,863 exposed keys in public repositories and realizes they now grant access to Gemini API services.
Initial Report: Google's security team dismisses the vulnerability report.
Proof of Concept: Truffle Security demonstrates actual access to Gemini services using exposed keys.
Acknowledgment: Google confirms the bug and begins working on a fix.
Which Controls Failed or Were Missing
No Change Management Process for Key Scope
Google modified the authorization scope of existing API keys without triggering any change management workflow. Organizations had no visibility into this transformation. Your keys went from "tracks billing" to "authenticates AI requests" with zero notification.
Missing Key Rotation Policy
The affected organizations lacked automated key rotation. Keys that were years old remained valid and functional. When their scope expanded, there was no mechanism to detect or respond to the change.
Inadequate Secret Classification
Teams treated these keys as billing identifiers, not authentication secrets. They appeared in:
- Public GitHub repositories
- Documentation examples
- Shared configuration files
- Developer onboarding materials
No one applied the same protection controls they would use for database credentials or API tokens because the original purpose didn't warrant it.
Absent Least-Privilege Enforcement
Google's architecture allowed a single key type to authenticate multiple services. There was no principle of least privilege at the key level—no way to say "this key is for billing queries only, never for data access."
What the Relevant Standards Require
ISO/IEC 27001:2022 Control 5.17 (Authentication Information) requires organizations to manage authentication information through its lifecycle, including "removal or blocking of access rights upon termination or change of employment." The control extends to service accounts and API keys. When Google changed what these keys could access, affected organizations should have been forced to revalidate their continued use.
NIST 800-53 Rev 5 IA-5 (Authenticator Management) specifies that organizations must "change authenticators prior to initial use, when there is evidence of compromise, and at organization-defined time periods." The control doesn't contemplate a scenario where the provider changes what an authenticator unlocks, but the principle applies: a material change in scope should trigger rotation.
PCI DSS v4.0.1 Requirement 8.3.2 mandates that authentication credentials be protected during transmission and storage. While this requirement targets payment environments specifically, it establishes the principle that authentication secrets require stronger controls than billing identifiers. Organizations subject to PCI DSS who used these keys in cardholder data environments would have violated this requirement by treating authentication tokens as low-sensitivity data.
SOC 2 Type II CC6.1 (Logical and Physical Access Controls) requires that "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events." If you're pursuing SOC 2 certification, your auditor will ask how you classify and protect API keys. "We didn't know it was an authentication token" won't satisfy the control.
Lessons and Action Items for Your Team
Audit Every API Key in Your Environment
Run a complete inventory this week:
- Which services have you generated API keys for?
- What did you think each key authorized when you created it?
- Where is each key stored?
- Who has access to each key?
Don't trust provider documentation from when you created the key. Check current API documentation for each service to confirm what your keys can actually do today.
Implement Mandatory Key Rotation
Set a maximum lifetime for every API key: 90 days for production, 30 days for development. Build rotation into your deployment pipeline. When a key approaches expiration, your CI/CD system should fail builds until you rotate it.
Treat All API Keys as High-Sensitivity Secrets
Store every API key in a secrets management system—HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or equivalent. No exceptions for "billing keys" or "read-only access." If it authenticates a request, it's a secret.
Use secret scanning tools in your CI/CD pipeline. GitHub, GitLab, and Bitbucket all offer native secret scanning. Truffle Security (who discovered this issue) offers TruffleHog as an open-source option. Configure these tools to block commits containing any API key pattern.
Demand Scope Transparency from Providers
When you evaluate a new cloud service, ask:
- Can existing keys authenticate to this service?
- Will you notify me if a key's authorization scope changes?
- Can I restrict keys to specific services or operations?
If the provider can't answer these questions, consider it a red flag for your risk assessment.
Document Your Key Classification
Create a classification matrix for every type of credential your team uses. For each type, document:
- What it authenticates to
- What data it can access
- Required storage controls
- Rotation frequency
- Incident response procedure if exposed
When a provider changes a service, you'll have a clear decision tree for whether existing keys need immediate rotation.
Build Detection for Scope Creep
Monitor your API key usage patterns. If a key that typically makes 100 requests per day suddenly makes 10,000, or if a key starts accessing services it never touched before, your monitoring should alert. This won't prevent a provider from expanding key scope, but it will help you detect when exposed keys are being exploited.
The Google Cloud incident demonstrates that your security posture depends on controls you don't directly manage. You can't prevent providers from changing their authorization models, but you can build resilience through comprehensive key management, aggressive rotation policies, and continuous monitoring. Treat every API key as if its scope could expand tomorrow—because it might.
