Even Google Can't Keep Up: Security in the AI Era Has Become a "Second-by-Second" Battle

Even Google Has Entered the Era of "Protecting While Running"

AI is a tool that boosts corporate productivity, but for security personnel, it has become a new attack surface. Generative AI, internal agents, training data, prompts, external SaaS, and multi-cloud environments—what was once a defense focus on network boundaries, endpoints, servers, and identity management has now expanded to encompass "everything AI touches."

The statement by Google Cloud COO, Francis de Souza, reported by TechCrunch, symbolizes this change. He emphasized that if companies are to adopt AI, security should not be an afterthought but integrated into the platform design from the start. Shadow AI, where employees independently use external AI tools, data management across multiple clouds, auditability, and governance are no longer just issues for the IT department but risks that management and boards should address.

What is particularly important is that AI adoption cannot be merely a "convenient new feature addition." As AI agents begin to operate across internal systems, they may unearth forgotten old data repositories, outdated access rights, abandoned SharePoint sites, and old business files. Data that was previously "not a problem because no one found it" can suddenly become visible due to AI. In other words, AI can quickly discover not only external attackers but also "past management oversights" within the company.

Attacks Progress in "Seconds," Not "Hours"

De Souza explains that the average time from breach to the next attack stage has shrunk from hours to seconds. This holds significant implications for security personnel. While humans check alerts, verify situations, gather stakeholders, make decisions, and manually block threats, the attack has already moved to the next stage.

In this context, Google Cloud's proposed solution is "AI-native defense." Instead of humans directly handling everything, AI agents monitor, defend, and respond initially, while humans supervise. If attacks progress at machine speed, defense must also operate at machine speed.

This approach is rational, but it also contains a significant contradiction. To use AI for protection, the AI itself must be secure. If there are vulnerabilities in the data AI references, the APIs it calls, the authentication information it uses, or the billing systems managing its usage, AI defense becomes a new risk rather than a safeguard.

The Collapse of "Old Assumptions" Highlighted by the Gemini API Key Issue

What makes the TechCrunch article intriguing is that it not only introduces Google Cloud's security recommendations but also touches on the issues Google itself faces. The focus was particularly on the series of high billing problems related to the Gemini API.

At the heart of the issue is the handling of Google Cloud's API keys. For years, it was not uncommon for API keys to be embedded in client-side code for services like Google Maps and Firebase. Developers did not necessarily perceive this as "exposing passwords." They were often treated as publicly shareable keys for service identification and billing.

However, when expensive AI inference services like the Gemini API are enabled within the same project, existing API keys can potentially be used for AI requests. If those keys remain in old website JavaScript, public repositories, or past configurations, attackers can find them and send a large number of requests to Gemini or image/video generation models, incurring massive costs on the developer's billing account.

This is not simply a matter of "developers neglecting key management." Some developers used keys according to the documentation and common practices of the time. Identifiers thought to be safe for public exposure later became akin to authentication for expensive AI services. This highlights the difficulty of security in the AI era. Designs that were safe yesterday can become dangerous with today's new feature additions.

The Distrust of "Limits" That Aren't Actually Limits

Further exacerbating developers' distrust were issues related to usage limits and billing caps. The Register reported cases where Google Cloud developers received bills ranging from thousands to tens of thousands of dollars due to unauthorized API usage. In some cases, usage that typically cost tens of dollars per month suddenly surged to over $10,000, or a supposed $250 cap was automatically raised to a higher limit based on account history.

Google's rationale is to avoid service interruptions and allow growing customers to seamlessly expand their usage. Indeed, for legitimate services experiencing sudden traffic growth, rigid limits can be obstacles. In an era where AI apps are rapidly growing, automatic expansion of usage limits can enhance the developer experience.

However, the moment unauthorized use occurs, this design works in the opposite direction. For attackers, the stolen key allows for more extensive use. For users, it feels like "it won't stop even though a limit was set." The strongest reactions on social media focused on this point. Developers are calling for "a real cap that stops, not just an alert."

The Anger and Fear Spreading on Reddit

On Reddit's r/googlecloud, posts about the Gemini API and high Google Cloud bills are pouring in. One poster, running a B2B SaaS, explained that their usual $50 monthly Google Cloud bill skyrocketed to over $10,000 due to Veo 3 and Gemini image output tokens. They claimed not to use those services in their product and reported the unauthorized use to Google support, initially being told "no evidence of fraud could be confirmed."

Another post mentioned that an old Google Maps API key was misused after enabling the Gemini API, resulting in a bill of about €36,800. The comments section included voices of surprise, such as "Wasn't this issue already reported? Why hasn't the behavior changed?" and "I'm scared of the Google Cloud Console. I can't trust holding a key that can incur tens of thousands of dollars."

A poster claiming to be from a small Japanese company faced a billing risk of about $128,000 due to unauthorized use of the Gemini API, even mentioning the possibility of bankruptcy. Comments highlighted the need for Google to provide an optional hard stop, a mechanism that ensures projects or APIs are stopped once a certain amount is exceeded. As more developers interact with Google Cloud due to the spread of AI coding tools, the assumption that "everyone can perfectly protect keys" becomes unrealistic.

Responses on Reddit included not only anger but also practical avoidance strategies. Suggestions included moving away from using API keys to service accounts or more restricted authentication methods, disabling the Gemini API at the organizational level, separating public services and AI usage into different projects, and always setting API restrictions. In other words, the community served as a place to share self-defense measures while criticizing Google's response.

Criticism of "Design Philosophy" on Hacker News

On Hacker News, discussions delved more into design philosophy. In a thread about Truffle Security's investigation, the issue was raised that Google API keys, which had long been treated as "identifiers that could be public," became effectively keys to expensive AI usage and data access with the introduction of Gemini.

One comment compared the need for clear spending caps per API key, such as $10 or $100. There was also a view that OpenAI and OpenRouter make it easier to manage spending per key or account, and dissatisfaction was expressed that Google Cloud's billing alerts have delays, making them ineffective as a real barrier.

Furthermore, criticism spread likening it to "using a username as a password." Of course, it's an oversimplification to place all the blame on Google. The Gemini API is not enabled by default for all projects; the project owner must enable it. Therefore, opinions persist that projects should be separated, keys restricted, and the principle of least privilege maintained.

However, the overall discussion leaned towards the view that AI has made "old cloud practices" dangerous. Publicly assumed keys, expensive AI inference, delayed billing data, and automatically expanded usage limits—while individually explainable, these specifications combined pose a fatal risk to small developers.

The "23-Minute" Issue That Doesn't End Even After Deleting Keys

Further investigation by Aikido Security raised another concern. According to their verification, even after deleting a Google API key, some requests may continue to be authenticated for up to about 23 minutes. In large distributed systems, it is not uncommon for configuration changes to take time to propagate to all servers. However, regarding the invalidation of authentication information, such delays translate directly into attack time.

If an attacker has a leaked key and the user hastily deletes the key, there is still a possibility that a large number of requests can continue to be sent for a while. If the Gemini API is enabled, this not only incurs charges but also poses a risk of access to uploaded files and cached conversation content.

This point is close to the core of AI security. In traditional cloud resources, a few minutes of delay might have been acceptable in some situations. However, requests to AI models are expensive, and the data is highly confidential. In a few minutes, an attacker can run a vast amount of inference. In the AI era, the concept of "eventual consistency" in authentication is precarious both in terms of cost and data protection.

Google's Recommendations Are Correct, and That's Why They're Questioned

What is important here is that the recommendation from Google Cloud's COO is not wrong. AI strategies require data and security strategies, and shadow AI should not be left unchecked. A consistent security posture should be maintained across multi-cloud, SaaS, external partners, and internal agents. As attacks have become machine-speed, AI must be utilized in defense as well.

The issue is how safely the platform provider itself can offer the foundation to implement these correct recommendations. If companies are told "don't retrofit security," the cloud side must also avoid situations where "adding AI features retroactively makes existing authentication and billing designs dangerous."

This uproar is not just a problem for Google. It is a warning common to all cloud providers, AI platforms, and SaaS companies. When incorporating AI features into existing services, past design assumptions must always be reviewed. Publicly shareable keys, internal-only keys, billing caps, data access ranges, invalidation processes, audit logs, and support systems—if the pre-AI common sense is applied as is, it will break down somewhere.

What Companies and Developers Should Review Immediately

The practical lessons from this issue are clear. First, separate projects that enable AI from those used for public frontends, Maps, Firebase, etc. Second, set API restrictions and application restrictions on all API keys and disable unnecessary APIs. Third, confirm spending caps or quotas that actually stop usage, not just billing alerts. Fourth, inventory keys remaining in old websites, repositories, and mobile apps. Fifth, prioritize service accounts, OAuth, and least privilege authentication design over API keys for AI usage.

Moreover, management should treat AI adoption not as a "convenient tool for the field" but as an infrastructure change involving financial and data breach risks. If a single key leak can lead to millions in charges or confidential data leaks, it is a topic for not only the CISO and development teams but also the CFO, legal, and executive meetings.

The Real Challenge of AI Security Is Not "Speed Difference" but "Responsibility Design"

AI-era security is indeed becoming real-time. Attacks are fast, and defense must be fast too. However, the real challenge is not just speed. Who bears the risk, who has the authority to stop it, what is safe by default, and which design should be prioritized—avoiding obstacles or stopping misuse? In other words, "responsibility design" is being questioned.

Even Google is navigating this transition period with uncertainty. That's why it's dangerous for other companies to proceed with AI adoption without defenses. Before expecting that AI can protect, detect, or automate, the authentication, billing, data, permissions, and audit mechanisms surrounding AI must be checked.

AI security is not a future issue. It has already reached a stage where a single API key, an old project, or a delayed alert can determine a company's survival.

Source URL

TechCrunch "Everyone is navigating AI security in real time — even Google"
Refer to statements by Google Cloud COO Francis de Souza on AI security, shadow AI, multi-cloud, agent-based defense, and Gemini API-related issues.
https://techcrunch.com/2026/05/24/everyone-is-navigating-ai-security-in-real-time-even-google/

The Register "Google users fight for refunds as unauthorized API usage bills soar"
Refer to high billing due to misuse of Google Cloud/Gemini API keys, cases of Rod Danan and Isuru Fonseka, and Google's explanation.
https://www.theregister.com/ai-ml/2026/05/13/google-users-fight-for-refunds-as-unauthorized-api-usage-bills-soar/5239160

The Register "Google reimburses Register sources who were victims of API fraud"
Refer to Google's reimbursement to some developers, though maintaining the policy of automatic usage limit expansion.
https://www.theregister.com/devops/2026/05/15/google-reimburses-register-sources-who-were-victims-of-api-fraud/5241429

The Register "Threat hunters find Google API keys still usable 23 minutes after deletion"
Refer to Aikido's investigation that API keys could be used for up to about 23 minutes after deletion and its impact.
https://www.theregister.com/devops/2026/05/21/threat-hunters-find-google-api-keys-still-usable-23-minutes-after-deletion/5244504

Aikido Security "Google API keys keep working after you delete them"
Refer to the delay in invalidation after deleting Google API keys, verification methods, and data/billing risks when Gemini is enabled.
https://www.aikido.dev/blog/google-api-keys-deletion

Truffle Security "Google API Keys Weren't Secrets. But then Gemini Changed the Rules."
Refer to the structure where API keys used in Google Maps and Firebase became risky with the activation of the Gemini API and public key investigation.
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules

Google Official Blog "Giving you more transparency and control over your Gemini API costs"
Refer to Google's explanation of Project Spend Caps, Usage Tiers, automatic upgrades, and spending management features for the Gemini API.
https://blog.google/innovation-and-ai/technology/developers-tools/more-control-over-gemini-api-costs/

Reddit r/googlecloud "Charged $10,138 in March 2026 due to Google's documented Gemini API key vulnerability"
Refer to the developer post and community response regarding a bill exceeding $10,000 related to Gemini/Veo.
https://www.reddit.com/r/googlecloud/comments/1t4xkmf/charged_10138_in_march_2026_due_to_googles/

Reddit r/googlecloud "Unexpected €36.8k Google Cloud Gemini API bill