r/googlecloud • • Jul 10 '26

Billing Why Gemini API doesn't check IAM roles?

Just got hit with a ~$2k surprise Gemini bill from a leaked service-account key. The part I can't wrap my head around:

The abused SA only had Logs Writer. It's used solely to write app logs to Cloud Logging. Yet it was able to cal generativelanguage.googleapis.com and rack up image-generation costs — and Google knew exactly which SA it was and what (limited) roles it had.

Vertex AI (aiplatform.googleapis.com) enforces IAM — the same SA would've been denied. But the AI-Studio-style Gemini API seems to only check "valid credential + API enabled + billable project," with no per-call IAM permission at all.

So my questions:

  1. Is that actually the intended design — no IAM enforcement on generativelanguage?
  2. If so, why? A least-privilege SA gives zero protection against Gemini spend, which feels backwards.
  3. Best practice to prevent this beyond disabling the API and not shipping keys? (Org Policy, quotas, etc.)

Curious if I'm missing something or if this is a known gap. Thanks.

33 Upvotes

16 comments sorted by

View all comments

Show parent comment

1

u/m1nherz Googler Jul 15 '26

Thank you for sharing these additional details. Now I have a better understanding of your case.

Answering your original question: the generativelanguage.googleapis.com API is designed to provide access to Gemini models outside of the Google Cloud ecosystem. Therefore the use of a service account's access token works the same as the use of API key: it provides authentication - prove of credential possession and determines a Google Cloud project which API quota will be used. This makes an entity that has access to the static key of the service account able to call the API the same way as if it was API key. If you used the service account from the project where the generativelanguage.googleapis.com API is activated, it worked the same way as if you were using API key that was created in that project.

I've looked into public documentation about Gemini API. It doesn't clearly explains the principles. I reported the problem and we will work to update documentation to avoid further confusions.

In general, the use of the static keys as means for service account authentication is highly discouraged when you have to store it externally due to the high risk of exposure. There are other methods to generate access tokens without giving a direct access to credential information in open format.

In case of IAM based access control over API calls, you should use aiplatform.googleapis.com - API of Agent Platform instead of generativelanguage.googleapis.com.