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.
Editorial analysis by NHI Mgmt Group, based on content published by Equixly: “How Gemini turned public Google API keys into secrets”.
By the numbers:
- In just 48 hours, a charge rose 457 times above the typical monthly bill.
Key questions
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 unrestricted project keys become dangerous after Gemini is enabled?
A: Because the security boundary moves from the key alone to the combination of the key, the project, and the enabled API set.
Q: How do security teams know whether API key scope has drifted?
A: They should compare each key’s original intended use with the current services enabled in its project and check whether the key still has an API allowlist that matches that intent.
Practitioner guidance
- Inventory all project API keys Identify every key linked to projects where Gemini or other generative APIs are enabled, then check whether each key still has the API allowlist and origin restrictions it was created with.
- Separate legacy and AI workloads Move Maps, Firebase, testing, and browser-facing keys into projects that do not host generative AI services, so a leaked legacy key cannot inherit access to Gemini endpoints.
- Enforce API allowlists on every exposed key Make API restrictions mandatory, not optional, and deny any key that can call a service outside its intended function even if network restrictions still pass.
Bottom line: A Google API key can be low risk in one project and high risk in another when service enablement changes its effective scope.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:17 pm
Credential scope drift is the core governance failure here. A key that was acceptable when it only reached Maps or another narrow API becomes a materially different credential once Gemini is enabled in the same project. That means the control problem is not secret visibility alone, but the mismatch between credential lifecycle and project capability lifecycle. Practitioners should govern project expansion as an authorization event.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
A question worth separating out:
Q: What should teams do when AI agents depend on API keys and service accounts?
A: Treat those credentials as governed NHIs and put them through lifecycle controls for ownership, scope review, and offboarding. The key question is not only who created the credential, but whether it still matches the agent's current use case and whether its permissions are still justified.
👉 Read our full editorial: Gemini-enabled API key scope drift turns legacy keys into risk