What permissions does the Google Cloud Service Account Creator Role grant?

The Google Cloud Service Account Creator Role grants permission to create service accounts in a Google Cloud project. That capability can be useful for automation, but it also increases the risk of identity sprawl if many principals can mint new workload identities. Limit it to trusted provisioning paths, and monitor service account creation against approved naming and ownership standards.

What this role actually permits in Google Cloud IAM

The Service Account Creator Role is narrowly scoped to creating service accounts within the project where it is granted. It does not, by itself, grant the ability to impersonate those accounts, attach permissions to them, or use them to access resources. That separation matters because creation is the first step in an identity lifecycle, not the same thing as operational access.

For teams that manage Google Cloud IAM, the practical question is whether the permission is being used for controlled provisioning or whether it is effectively letting too many principals mint new workload identities. The role is most defensible when it sits inside a defined provisioning path with naming, ownership, and approval standards.

Google Cloud IAM and service accounts are easier to govern when creation, binding, and usage are treated as distinct actions. The Google Cloud IAM and Service Accounts Guide is useful here because it separates predefined roles, custom roles, service account keys, impersonation, and least-privilege design into the same operating model.

Why creation permission is a governance and blast-radius issue

Granting service account creation widely can create identity sprawl. Even if the accounts start unused, they become durable workload identities that can later be granted roles, keys, token exchange paths, or impersonation rights. That expands the number of identities security teams must inventory, review, and eventually retire.

The control concern is not only privilege, but ownership. A newly created service account without a clear owner or purpose can become orphaned, over time turning a simple provisioning convenience into an unmanaged access path. The broader NHI operating model is captured well in Ultimate Guide to NHIs, which ties lifecycle, visibility, and offboarding to service account security.

When many principals can create service accounts, you also lose signal quality. Monitoring becomes harder because not every new identity is evidence of a legitimate automation need. The cleanest governance model is to treat creation as an exception path, not a default entitlement.

How to use the permission without creating unmanaged workload identities

The safest operating pattern is to let the role exist only where automation truly needs to provision identities, such as infrastructure pipelines or controlled platform services. In those cases, the creation path should be paired with explicit ownership metadata, approval workflow, and post-creation review so the account is not just created, but also governed.

That governance should extend beyond the initial create action. Service account lifecycle controls need to cover who requested it, which system owns it, whether it has an attached use case, and whether it is later reused for an unrelated workload. The Service Account Security Guide and the NHI Ownership and Accountability Guide both reinforce that creation only stays safe when ownership and least privilege are defined at the same time.

For cloud-native environments, creation should also be paired with workload identity design rather than static secret habits. The Cloud Workload Identity Guide is relevant because it frames Google service accounts alongside temporary or federated patterns that reduce dependence on long-lived credentials.

What practitioners should verify after granting it

After assigning the role, verify that every principal with create access is an approved provisioning actor, not a general developer or operator. Check whether each newly created service account has a named owner, a documented purpose, and a follow-on policy for role assignment and credential handling.

It is also worth checking whether the project has controls for detecting unusual creation volume, naming drift, or service accounts that never receive a legitimate workload assignment. In practice, the role is safest when paired with review of the accounts it creates, not just the permission itself.

For a deeper view of how this failure mode shows up in the wild, the State of NHI & AI Agent Breach Report 2026 is a useful reference point because it shows how compromised or mismanaged service accounts can become an entry point for wider identity abuse.

Risk and Threat Considerations

Widespread service account creation permission can turn a simple admin convenience into a persistent attack surface. The more identities that can be minted, the more opportunities there are for weak ownership, shadow automation, and later privilege expansion through those accounts.

Failure mechanism: A principal with create access provisions a service account outside approved provisioning paths, then the account is left with unclear ownership, excessive trust, or follow-on privileges that were never reviewed with the same scrutiny as the original permission.

Impact: The environment accumulates orphaned or overused workload identities that are harder to audit, easier to abuse, and more likely to be reused in ways that expand blast radius across projects or automation pipelines.

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 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Service account creation governs identity material lifecycle and resulting access paths.
	AC-6 — Least Privilege	The role should be limited to trusted provisioning paths to reduce identity sprawl.
	AU-12 — Audit Record Generation	Creation events need logging so new workload identities can be monitored and reviewed.
Recommendation — Restrict who can create service accounts and track resulting credentials through their lifecycle. Limit service account creation to approved automation and tightly scoped admins. Log every service account creation event and review anomalies against approved patterns.
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	New service accounts become lifecycle assets that need ownership and eventual retirement.
	NHI-05 — Overprivileged NHI	Created service accounts can later accumulate excessive permissions if not governed.
Recommendation — Assign owners at creation and revoke unused service accounts quickly. Review privileges granted to newly created service accounts before deployment.

Practitioner Guidance

What to prioritise: Treat service account creation as a gated provisioning privilege, not a routine developer entitlement. The first control objective is to ensure every creation event has a business purpose and an accountable owner.

What to verify: Confirm that creation rights are limited to trusted provisioning paths, and that new service accounts are reviewed for ownership, naming, and intended use before they are granted any permissions or attached to workloads.

Common mistake: Teams often focus on who can use a service account while overlooking who can create one. That inversion leaves the organisation with an expanding set of identities that are technically valid but operationally unmanaged.

Practitioner takeaway: The role is acceptable when it enables controlled automation, but it becomes risky the moment service account creation is treated as free-form identity generation rather than governed provisioning.