Google is temporarily restricting new Gemini API access from service accounts

Google added a caution to its current IAM service-account documentation stating that, starting August 27, 2026, it will temporarily restrict new access to the Gemini API from service accounts. Google says existing service accounts that are already used with the Gemini API will continue to work. For new integrations, it recommends using authentication-enabled API keys instead. The notice appears in both Google's service-account overview and service-account-key documentation. Google has not published a fixed end date, a detailed grandfathering matrix, or a public explanation of why the temporary restriction was introduced.

Service accounts are a standard Google Cloud identity for unattended server workloads, CI jobs and backend services. A temporary restriction specifically on new Gemini API access means teams cannot assume that an authentication pattern already working in one project can be reproduced unchanged in a new project or service account. Existing integrations are grandfathered for now, so the risk is asymmetric: migrations, new environments and disaster-recovery rebuilds can encounter a different authentication boundary from production. Builders should therefore document which credential path each Gemini workload uses and validate new environments before depending on service-account parity.

Google's notice explicitly says existing service accounts used with the Gemini API will continue to work. This is not a blanket shutdown of current service-account-authenticated Gemini traffic. The change applies to new access, which makes project creation, account replacement and new deployment environments the more immediate areas to test.

For new Gemini integrations, Google recommends authentication-enabled API keys. That changes the credential decision for teams that would normally default to a service account for an unattended workload. The exact security and lifecycle model should be documented explicitly rather than treating an API key as a drop-in equivalent to existing service-account authentication.

Google has not stated when the restriction will end or what condition will cause it to be lifted. It also does not publish a complete matrix explaining whether every service-account authentication path, project type or API surface is affected identically. Teams should avoid designing a migration around assumptions that are not in the current documentation.

A production workload can remain healthy because its existing service account continues to work while a newly created staging, regional failover or recovery environment cannot establish the same Gemini access. Authentication should therefore be part of environment-rebuild tests, not something inferred from the health of an older deployment.