There are no "leaked" keys if google hasn't been calling them a secret.
They should ideally prevent all keys created before Gemini from accessing Gemini. It would be funny(though not surprising) if their leaked key "discovery" has false positives and starts blocking keys from Gemini.
This is going to break so many applications. No wonder they don't want to admit this is a problem. This is, like, whole-number percentage of Gemini traffic, level of fuck-up.
Jesus, and the keys leak cached context and Gemini uploads. This might be the worst security vulnerability Google has ever pushed to prod.
The problem here is that people create an API key for use X, then enable Gemini on the same project to do something else, not realizing that the old key now allows access to Gemini as well.
Takeaway: GCP projects are free and provide strong security boundaries, so use them liberally and never reuse them for anything public-facing.
Also, for APIs with quotas you have to be careful not to use multiple GCP projects for a single logical application, since those quotas are tracked per application, not per account. It is definitely not Google's intent that you should have one GCP project per service within a single logical application.
You can do what you're describing but it's not the model Google is expecting you to use, and you shouldn't have to do that.
It seems what happened here is that some extremely overzealous PM, probably fueled by Google's insane push to maximize Gemini's usage, decided that the Gemini API on GCP should be default enabled to make it easier for people to deploy, either being unaware or intentionally overlooking the obvious security implications of doing so. It's a huge mistake.
Like deciding ATM cabinets should be default open to make it easier for people to withdraw cash.
No, there must be more behind this than overzealotry.
Gemini should have had it's own API key separate from their traditionally public facing API IDs (which they call keys) and API keys should default to being tightly scoped to their use case rather than being unrestricted.
Who cares if you have three API keys for three services.
Quite frankly putting any API information in things like url params or client side code just doesn't sit right with me. It breaks the norm in a way that could be, and is now security concern.
Artifical Intelligence service design and lack of human intelligence are highly correlated. Who'd have guessed??
I can somewhat follow this line of thinking, it’s pretty intentional and clear what you’re doing when you flip on APIs in the Google cloud site.
But I can’t wrap my mind around what is an API key. All the Google cloud stuff I’ve done the last couple years involves a lot of security stuff and permissions (namely, using Gemini, of all things. The irony…).
Somewhat infamously, there’s a separate Gemini API specifically to get the easy API key based experience. I don’t understand how the concept of an easy API key leaked into Google Cloud, especially if it is coupled to Gemini access. Why not use that to make the easy dev experience? This must be some sort of overlooked fuckup. You’d either ship this and API keys for Gemini, or neither. Doing it and not using it for an easier dev experience is a head scratcher.
app-scripts creates projects as well but maps just generates api keys in the current project
--- Get Started on Google Maps Platform You're all set to develop! Here's the API key you would need for your implementation. API key can be referenced in the Credentials section.
To this day I am unable to access the models they say I should be able to.
I still get 2.5 only, despite enabling previews in the google cloud config etc etc.
The access seems to randomly turn on and off and swaps depending on the auth used (Oauth, api-key, etc)
The entire gemini-cli repo looks like it is full of slop with 1000 devs trying to be the first to pump every issue into claude and claim some sort of clout.
It is an absolute shit show and not a good a look.
At $DAYJOB, we had a (not very special) special arrangement with GCP, and I never heard of anyone who was unable to create a project in our company's orgs [0].
Given how Google never, ever wants to have a human do customer support, I expect a robot will quickly auto-approve requests for "number of projects" quota increases. I know that's how it worked at work.
[0] ...with the exception of errors caused by GCP flakiness and other malfunction, of course.
So many organizations have the IAM "Project creator" role assigned to everyone at the org level. I think it's even a default.
It sent me to a url: https://console.cloud.google.com/google/maps-apis/onboard;fl...
which auto-generated an API key for me to paste into things ASAP.
---
Get Started on Google Maps Platform You're all set to develop! Here's the API key you would need for your implementation. API key can be referenced in the Credentials section.
Of course, I bring this up because they could just version their API keys, completely solving this problem and preventing future ones like it.
Versioning data formats is wrongthink over there, so I’m guessing they just… won’t.
export type FooRpcV1 : { version: 1, ... } export type FooRpcV2 : { version: 2, ... }
in zod syntax, and it'll do the right thing statically and at runtime (ask an LLM for help with the syntax).
With protobufs (specifically protoc), you get some type like:
export type FooRpc : { version : 1 | 2, v1fieldA? : string, v1fieldB? : int, v2fieldB? : string, v2fieldB? string };
which is 2^5 message types, even if all fields of both versions were mandatory. Then application logic needs to validate it.
How did this get past any kind of security review at all? It’s like using usernames as passwords.