OopsKey: Tom Pohl’s New Open-Source Tool Helps Security Teams Find Risky Google API Key Exposure
Google API keys long considered low-risk may now expose far more than expected if Gemini is enabled in a project. The open-source tool OopsKey, created by Tom Pohl at LMG Security, helps security teams quickly identify exposed keys and determine whether they can access AI services or trigger unexpected costs. The takeaway: platform changes can quietly expand the risk of old credentials, so defenders need to reassess API key restrictions and visibility in the AI era.
Link to the tool: https://github.com/LMGsec/OopsKey
Some security problems do not arrive with a loud bang. They arrive when an old assumption quietly stops being true.
That is what happened with certain Google API keys. For years, many developers treated some of these keys as relatively low-risk, especially when they were used in public-facing web apps for services like Maps. But recent research from Truffle Security showed that once Gemini is enabled in a Google project, keys that were once treated as “okay to expose” can become far more sensitive. In some cases, they may be abused to access AI-related services or drive up usage costs in ways defenders did not anticipate.
That is the problem behind OopsKey, a new open-source tool created by Tom Pohl, Director of Penetration Testing at LMG Security. OopsKey helps security teams find exposed Google API keys, test what those keys can actually access, and quickly distinguish between a noisy finding and a real risk.
“Google API keys are not secrets, until they are secrets,” said Tom, describing how the risk model changed once Gemini entered the picture.
Why this matters now
The issue is not simply that exposed API keys exist. Security teams have known for a long time that keys end up in JavaScript, mobile apps, repositories, and build artifacts. The bigger problem is that platform behavior changed underneath developers.
As Tom explained, the default behavior for some Google API keys was effectively to “let it work for all services,” which means new services added later could inherit access if teams accepted the defaults and never tightened restrictions. That is what makes this issue operationally important: a key created with one benign use case in mind may now be usable against a very different service than the one the developer intended.
“In the case of Gemini,” Tom said, “this API key that you may have generated just with Maps in mind is now available for this new endpoint, and actually costs you real money.”
What OopsKey does
OopsKey was built to answer a practical question: if you find a Google API key during a security assessment, what is it actually good for?
That question came directly from Tom’s penetration testing work. “This could be useful information for us on penetration tests,” Tom said. If his team encounters a Google API key during an engagement, they want to know whether it is enabled for Gemini or other services so they can tell the customer, in concrete terms, that there is “an exposure and a risk here that you may or may not be aware of.”
OopsKey is a Python-based tool that can take either a website or a key directly as input. If you give it a website, it scans the target, looks through same-host JavaScript resources, identifies unique Google API keys, and then tests those keys across Google API endpoints. It reports which endpoints work, which do not, which ones may incur cost, and whether the finding appears low, medium, or high risk.
That last part is important. Plenty of tools can help you spot exposed material. Fewer can help you quickly determine whether the thing you found is actually dangerous. OopsKey is built to close that gap between discovery and usable assessment.
Tom also built it because he saw a hole in the existing tooling. “There is another tool out there,” Tom said, “that will just look at, like, all the Google Maps API endpoints and test for it, but nothing that’s, like, comprehensive against all the Google APIs that use key-based only authentication.”
That makes OopsKey more than a niche utility. It is a response to a specific blind spot in modern application and cloud testing.
Why defenders should care
For defenders, OopsKey is useful because it helps separate cosmetic exposure from meaningful risk.
A security team may already know that some Google API keys are visible in frontend code. That by itself is not always a crisis. The more important questions are whether those keys are restricted properly, whether new services have expanded their privileges, and whether attackers could turn them into data access or billing abuse.
That is where this gets interesting from a defensive standpoint. The same key that once looked like a low-priority issue can become a foothold for unexpected behavior. Recent reporting from BleepingComputer underscored that this is not a theoretical edge case: researchers found thousands of exposed keys that could authenticate to Gemini-related services after API enablement changed what those keys could do.
It is also a good example of why mature security programs need more than static best practices. They need continuous reassessment. AI services, cloud APIs, and developer defaults are moving targets. What mattered last year may not be enough this year.
The bigger lesson for security leaders
OopsKey is a tool release, but it also points to a broader leadership issue: risk models need to evolve as platforms evolve.
Security leaders should not treat this as just another credential hygiene story. It is really a story about inherited trust, insecure defaults, and the unintended consequences of new AI capabilities landing in old environments. If a team enables a new service without revisiting existing keys, scopes, and billing controls, the blast radius may expand without anyone noticing.
That is why this topic fits naturally alongside broader penetration testing and web application penetration testing work. These assessments are valuable not just because they find bugs, but because they surface the assumptions, chaining opportunities, and configuration gaps that automated tooling or checklist reviews often miss. LMG Security has also written about this bigger picture in The Critical Role of API Penetration Testing in Your Web App Security Strategy and, more recently, Google Gemini Changed the Rules: Are Your API Keys Exposed?
For teams reviewing their own environments, the immediate steps are straightforward: inventory API keys, restrict them to only the services and referrers they truly need, segment AI workloads where possible, and monitor for unusual usage or billing spikes. Google’s Gemini API documentation and cloud guidance are useful references, but the real work is validating how those recommendations map to your actual deployments.
Final thought
Security drift is easy to miss because it often looks like business as usual.
OopsKey gives defenders a practical way to test whether an exposed Google API key is merely visible or genuinely risky. And if your team wants help finding the kinds of web application and cloud exposures that attackers actually chain together, LMG Security’s penetration testing services can help uncover those gaps before they become someone else’s opportunity.
