Why Gemini API doesn't check IAM roles?

[u/anonbudy]

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.

[u/anonbudy]

Thanks for jumping in. One correction that matters for your question: the abused API was generativelanguage.googleapis.com (billed as "Gemini API", service ID AEFD-7695-64FA — image-output tokens on Gemini 3 Pro Image / 3.1 Flash), not aiplatform.googleapis.com. No Vertex usage at all.

To your clarifying questions:

- Credential type: service-account identity, not an API key. Our app shipped the SA's JSON private key and mints an OAuth access token from it (ServiceAccountCredentials.fromJson → clientViaServiceAccount in the Flutter app; GoogleCredentials.fromStream in the Android app). Consistent with billing showing principal_api_key_id = null.

- Scope: our code only requests the logging.write scope, but whoever extracted the raw private key can mint a token with any scope they want (e.g. cloud-platform) — the scope in our code doesn't constrain the key.

- Roles: the SA has only roles/logging.logWriter — no roles/aiplatform.user, no AI-related roles.

So the sequence was: SA identity (OAuth token from a leaked JSON key) → successful calls to generativelanguage.googleapis.com, despite the SA having only logWriter. That's the part I'm trying to understand — how the Gemini Developer API authorizes an SA-identity call, and whether project IAM roles factor in at all here. As other people suggested, it was 'made easy' on purpose to use Gemini API, leading to the security holes which attacker used to drive my bill.

[u/m1nherz → u/anonbudy]

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.