Gemini key flaw widens Android app risk

Google’s handling of API keys has come under fresh scrutiny after security researchers said Android applications are exposing credentials that can now unlock parts of the Gemini AI platform, potentially allowing unauthorised access to files, cached data and billable AI services. The latest warning, published by CloudSEK on April 7, says 32 hardcoded Google API keys were found across 22 popular Android apps and that the issue stems from how older Google Cloud keys can gain Gemini permissions when the Generative Language API is enabled on the same project.

The finding builds on a separate disclosure made in February by Truffle Security, which said Google API keys had long been treated by many developers as identifiers suitable for use in public-facing code for services such as Maps or Firebase, but could now authenticate requests to Gemini. Truffle said it identified 2,863 live keys on the public internet that were vulnerable to this form of privilege expansion, while CloudSEK’s mobile-focused research suggests the same architectural weakness also affects Android apps where keys are commonly embedded in client code.

At the heart of the problem is a shift in risk rather than a conventional leak alone. Google’s documentation has long described API keys as credentials that can be created, managed and restricted, and it recommends adding both client and API restrictions to all keys. Security researchers argue that many legacy deployments were created in an era when these keys were widely used in lower-risk scenarios and were not treated as secrets in the same way as private tokens. Once Gemini services were enabled on the same cloud project, however, those exposed keys could inherit access that developers did not anticipate.

That matters because Gemini access is not limited to simple text prompts. According to the research, a valid key may be used to query AI endpoints, consume project quotas and, in some cases, interact with uploaded files or cached content associated with the project. For mobile developers, the exposure is acute because Android packages can often be decompiled, making hardcoded keys easier for attackers to extract. CloudSEK said the affected apps ranged across categories and that the hardcoded credentials could give outsiders a foothold into Gemini-backed resources without the app publisher realising the scope of the exposure.

The episode also raises a broader question about cloud defaults and developer expectations. Truffle said newly created keys in Google Cloud were, at the time of its research, often left “unrestricted” unless a developer manually narrowed their use, expanding the blast radius when additional services were turned on. Google’s own documentation stresses that restrictions should be applied, but researchers contend that guidance alone is not enough when millions of older keys may already be deployed in apps and websites under assumptions that no longer hold.

The Android angle may prove especially important for the software supply chain because mobile apps routinely bundle third-party SDKs, analytics tools and cloud connections that developers do not always audit closely once they are working. Quokka, another security firm, said in February that it found more than 35,000 unique Google API keys embedded in a scan of 250,000 Android apps, underscoring how widespread the practice remains. CloudSEK’s narrower sample does not suggest all of those keys are exposed to Gemini, but it indicates that mobile ecosystems are carrying a sizeable legacy of insecure-by-design assumptions around key exposure.

For Google, the controversy lands at an awkward moment as it pushes Gemini deeper into consumer and enterprise products while encouraging developers to experiment quickly. Google documentation for Vertex AI says API keys can be used with Gemini, while recommending stronger authentication methods such as application default credentials for production environments. That creates a tension familiar in modern software development: tools designed for speed and prototyping often make adoption easier, but can produce costly security debt when they are carried into production systems without tighter controls.