Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: Google API keys that were once treated as public identifiers can become high-risk credentials when Gemini is enabled in the same project, because unrestricted keys may now authorize costly AI requests and expose organisations to denial-of-wallet, abuse, and privacy risks, according to Equixly. The key issue is credential scope drift: older keys inherit new capabilities when AI services are added, so restriction and project isolation now matter as much as key visibility.
NHIMG editorial — based on content published by Equixly: Blog API Security How Gemini turned public Google API keys into secrets
By the numbers:
- A leaked Google API key can trigger a 457-times spike above a typical monthly bill within 48 hours when Gemini usage is abused.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase.
Questions worth separating out
Q: What breaks when a public API key can also reach Gemini endpoints?
A: The main failure is that a credential once treated as a low-risk application identifier can suddenly authorize expensive AI requests.
Q: Why do long-lived API keys create more risk for AI agents?
A: Long-lived API keys increase risk because they persist across tasks, deployments, and runtime changes.
Q: How can security teams tell whether an API key is actually safe to leave visible?
A: They need to check more than visibility.
Practitioner guidance
- Implement API allowlists for every public key Bind each Google API key to a minimal set of approved services and verify that Gemini or Generative Language APIs are excluded unless explicitly required.
- Separate AI workloads into dedicated projects Keep Maps, Firebase, and other legacy front-end services in projects that do not share unrestricted keys with Gemini-enabled workloads.
- Rebuild the key inventory with effective scope Track each key, its restrictions, and the enabled services in the project so you can detect when a credential gains new authority after the fact.
What's in the full article
Equixly's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how to test whether a project key can call Gemini endpoints.
- Operational guidance on using API restrictions and project segmentation to separate Maps, Firebase, and AI workloads.
- Practical detection and validation methods for finding scope drift in existing Google Cloud projects.
- Examples of how offensive security testing can uncover abuse paths in AI-enabled API workflows.
👉 Read Equixly's analysis of how Gemini turns public Google API keys into risk →
Gemini-enabled API keys: are your controls keeping up?
Explore further
19/08/2026 4:17 pm
Credential scope drift is the real failure mode here: the key did not become more powerful on its own, the project did. That distinction matters because traditional secret handling treats exposure as the main issue, while this pattern shows that service enablement can silently widen privilege after issuance. For identity and access programmes, the governance question is whether a credential’s effective authority is revalidated whenever the underlying service set changes. Practitioners should treat scope drift as a lifecycle control failure, not a one-time leakage event.
A question worth separating out:
Q: Who should own the risk when a project key can access AI services?
A: Ownership should sit across IAM, application security, and the teams enabling the AI service. The key issue is not just secret management, because the service itself changes the credential’s authority. Governance should require review before service enablement, plus logging, budget controls, and fast revocation paths after exposure.
👉 Read our full editorial: Gemini-enabled API key scope drift turns legacy keys into risk
