Why should users not hold Service Account User or Token Creator roles at project level in Google Cloud?

Users should not hold Service Account User or Token Creator roles at project level because those permissions can let them impersonate service accounts across multiple workloads. That broad reach makes privilege escalation and credential abuse easier. Grant these roles only where needed, preferably on specific identities, and regularly review project-level bindings for overreach.

Why project-level Service Account User and Token Creator create broad impersonation reach

At project scope, these roles can become a shortcut to impersonating service accounts that were never meant to be broadly usable. That matters because the permission is not just about one login path, it can open access across many workloads that rely on those identities. The more widely the binding is granted, the harder it is to reason about who can mint or use credentials in practice.

For Google Cloud teams, the key issue is scope. A project-level grant can attach to many service accounts, so a user who only needed access to one automation identity may gain the ability to act as several. That is why the safer pattern is to bind the role to a specific service account or a narrowly defined set of identities, rather than to the whole project. Google Cloud IAM and Service Accounts Guide

That distinction also helps prevent role creep. When a project binding is treated as a convenience, it tends to survive long after the original use case has changed, which makes later review harder and increases the chance that a routine user can obtain capabilities that were intended only for a deployment pipeline or backend workload. Ultimate Guide to NHIs

How overbroad impersonation turns into privilege escalation

The practical security problem is that impersonation collapses separation between the human user and the non-human identity they can assume. If that service account already has sensitive project, data, or deployment permissions, the user inherits those rights through impersonation rather than through a direct grant. The result is privilege escalation that is easier to miss in access reviews because the risky power sits inside a seemingly ordinary project IAM binding.

This is especially dangerous when the impersonated identity has lateral reach into multiple services or environments. A single overbroad role can be used to access runtime secrets, call internal APIs, trigger automation, or operate deployment tooling, even when the human account itself looks low risk. That is why project-level grants deserve the same scrutiny as administrative privileges, not just routine access control. Service Account Security Guide

The risk is not limited to misuse by an insider with legitimate access. If the user account is compromised, the attacker may inherit a ready-made path to mint or use service account credentials without first breaking into each workload separately. That changes a single account compromise into a wider trust-bypass problem. The State of NHI & AI Agent Breach Report 2026

What good access design looks like in Google Cloud

Good design starts with the smallest effective scope. Grant Service Account User or Token Creator only to the identities that truly need to impersonate a specific service account, and prefer resource-level or identity-level bindings over project-level grants. If the use case is workload access, consider whether the workload can use a managed identity, workload identity federation, or another short-lived credential path instead of broad impersonation rights. Cloud Workload Identity Guide

Reviewing these bindings should be part of ordinary IAM hygiene, not a one-time hardening task. The most useful check is whether the grantee can still justify impersonating every service account covered by the project binding, because any “no” means the grant is wider than required. If the answer is uncertain, tighten the binding first and then restore only the specific access that the business case can defend.

In environments with shared services, the ownership question matters as much as the technical one. A binding that nobody owns will usually expand over time, so the review process should confirm a business owner, a technical owner, and a clear reason for each impersonation path. NHI Ownership and Accountability Guide

Risk and Threat Considerations

Project-level impersonation rights create a concentrated blast radius. If one human account is compromised, or one authorized user abuses the role, the attacker may gain access to multiple service accounts, their tokens, and the workloads those identities can operate.

Failure mechanism: A broad IAM binding allows the user to mint or use credentials for service accounts beyond the intended scope, which bypasses workload boundaries and makes privilege escalation easier to perform and harder to spot.

Impact: Attackers can move from a single user account into deployment systems, internal APIs, data services, or automation tasks, increasing the chance of lateral movement, data exposure, and persistence.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers lifecycle control of credentials and tokens used to impersonate service accounts.
	IA-9 — Service Identification and Authentication	Applies because users are being allowed to act through service accounts and related machine identities.
	AC-6 — Least Privilege	Directly addresses overbroad project-level access that enables unnecessary impersonation.
Recommendation — Restrict and review credential-issuing paths so impersonation rights stay narrowly scoped. Authenticate service-account use with tightly scoped mechanisms and approved trust paths. Limit impersonation roles to the smallest set of identities and resources required.
CIS Controls v8	CIS-6 — Access Control Management	Supports restricting and reviewing broad project-level access grants for service accounts.
Recommendation — Review and remove overbroad service-account role bindings that exceed business need.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Matches the core issue of granting broad impersonation power to non-human identities.
	NHI-10 — Human Use of NHI	Applies when users are allowed to use service-account identities directly for broad access.
Recommendation — Scope service-account impersonation to the minimum identities and permissions required. Prevent humans from using service-account access paths except for tightly approved cases.

Practitioner Guidance

What to verify: Check whether any project-level Service Account User or Token Creator bindings still exist because of convenience rather than necessity. Verify that each binding maps to a named service account and a documented business reason, not to an entire project by default.

What good looks like: A user can impersonate only the specific service account needed for a defined task, the binding is time-bounded or exception-based where possible, and access reviews can explain why each impersonation path exists.

Common mistake: Treating project-level grants as harmless because the role looks narrowly named. In practice, scope matters more than the label, and broad scope turns a targeted control into a reusable access path.

Practitioner takeaway: The core decision is not whether impersonation is useful, it is whether the scope of that impersonation matches the blast radius you are willing to accept.