Google Cloud Agent Identity: SPIFFE Principals, Auth Manager and Hardening for Agents

Agents deployed on Google Cloud have often run as service accounts that need careful scoping, and Google Cloud Agent Identity replaces that with a per-agent cryptographic principal. Agent Identity gives each agent on Gemini Enterprise Agent Platform Runtime (Agent Runtime, formerly Vertex AI Agent Engine), Gemini Enterprise or Cloud Run a SPIFFE-based identity with a short-lived X.509 certificate, certificate-bound tokens, and an auth manager that brokers API keys and OAuth tokens for outbound tool calls. This guide explains how the identity is formed, which roles to grant, how to fence agents with Principal Access Boundary and VPC Service Controls, what the audit logs show, and the misconfigurations that undo the model. It is for cloud platform engineers, IAM teams and security architects running agents on Google Cloud. Facts are from Google Cloud documentation checked on 8 November 2026; the deployment documentation labels the feature Preview under the Pre-GA Offerings Terms, so details may change.

This is an independent guide from NHI Mgmt Group, based on Google Cloud's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.

Key takeaways

• The agent is the principal. Each agent gets an identifier of the form principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH and you grant IAM roles to it directly, with no service account in between.
• Credentials are short-lived and bound. The X.509 certificate lasts 24 hours and renews automatically; Google Cloud access tokens and ID tokens are bound to it with mTLS and DPoP, enforced by a Google-managed Context-Aware Access policy.
• The identity follows the resource, not the code. Redeploying creates a new principal, and deleting an agent leaves its IAM bindings behind, so lifecycle hygiene is your job.
• Fence agents on the egress side. Principal Access Boundary policies bound to agent principal sets cap what any agent can reach, whatever roles it later collects; VPC Service Controls can include the two Agent Identity APIs.
• Watch the auth manager. It holds third-party API keys, OAuth client secrets and delegated user tokens; RetrieveCredentials is a Data Access event, so enable Data Access logs for it or you will not see credential use.

How identity and access work in Google Cloud Agent Identity

Google documents Agent Identity as "a strongly attested, cryptographic identity for each agent", based on the SPIFFE standard. It sits beside two related services: Agent Registry, which catalogues tools and destinations, and Agent Gateway, which enforces access policy and inspects agent traffic.

Identifier formats

What makes it different from a service account

• Not shared: Google states agent identities are not shared by multiple workloads by default, so each agent's actions are attributable to it alone.
• Not impersonable: no principal can mint tokens as the agent through impersonation, which removes the iam.serviceAccounts.getAccessToken escalation path that service accounts carry. See the Google Cloud IAM and Service Accounts Guide.
• No long-lived keys: developers cannot generate service account keys for agent identities. Compare the Google Cloud Service Account Keys Security Guide.
• Bound credentials: the auto-provisioned X.509 certificate is valid for 24 hours and chains to a Google-managed root. Calls to Google Cloud APIs use mTLS; calls through Agent Gateway also carry DPoP, which Google calls a "double-bound" credential. ID tokens for external services are bound through the cnf claim. See the DPoP Guide and the SPIFFE and SPIRE Guide.

Three identities in delegated flows

Google's delegation architecture names three identities: the user identity (the person, authenticated with OAuth 2.0 or OIDC), the agent identity (the SPIFFE principal), and the delegated identity (scoped three-legged OAuth credentials the auth manager brokers when the agent acts for the user). Audit logs record both agent and user when the agent acts on a user's behalf, and end-user access events are attributed to the agent's SPIFFE ID.

Authentication models

Admin roles and privileged access

Three groups hold power over agent identity: people who deploy agents, people who grant roles to agent principals, and people who manage the auth manager. Treat each as privileged.

• Separate deployers from grantors: the person who ships agent code should not also be able to grant that agent roles. Put IAM grants for agent principals through a reviewed pipeline (Terraform or similar) with approval.
• Keep the recommended baseline small: Google lists Agent Context Editor (roles/aiplatform.agentContextEditor), Agent Default Access (roles/aiplatform.agentDefaultAccess), Service Usage Consumer, Browser and Storage Object Viewer as recommended agent roles. Grant Storage Object Viewer on the specific bucket, not the project, and add task roles per agent.
• Use deny policies for hard limits: agent principals work in IAM deny policies, so you can deny permissions such as resourcemanager.projects.setIamPolicy to the organisation-wide agent principal set regardless of later allow grants.
• Restrict the auth provider IAM policy: each auth provider has its own IAM policy. Grant retrieval to named agent principals only, never to a project-wide principal set or to human developer groups beyond what testing needs.

For privileged human access to the Google Cloud console generally, see the Google Cloud Security Guide.

Integrations, API tokens and service accounts

The auth manager is a Google-managed credential vault and authentication broker for outbound tool calls. It stores credentials in auth providers, runs OAuth consent, code exchange and refresh, and through the Agent Development Kit (ADK) injects headers such as Authorization or X-Goog-Api-Key into tool and MCP server calls. The agent authenticates to the auth manager with its SPIFFE ID, and IAM decides which agents and developers can use each provider.

• Retire the service accounts agents used before: after moving an agent to Agent Identity, disable the old service account, remove its keys and bindings, and confirm nothing still impersonates it. See How to inventory Google Cloud service account keys and replace them with federation.
• Keep secrets out of agent code: anything the auth manager can hold should not sit in environment variables or the deployment package. Remaining application secrets belong in Secret Manager with per-agent access.
• Treat API keys as live risk: a key's reach grows with the APIs enabled on its project, as the Google API Keys Exposure 2026 showed when Gemini access was added to keys published years earlier. See the Google API Keys Security Guide.
• Avoid the deprecated path: Google's provider management page marks the IAM Connectors API Preview as not going to general availability and directs users to the Agent Identity API.
• Do not switch off token binding: setting GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN=false disables binding for both access and ID tokens across the runtime; Google does not recommend it. Where a specific non-mTLS endpoint needs an unbound ID token, use the per-request bind_id_token=False option (google-auth 2.61.0 or later on GKE, 2.62.0 or later on Cloud Run) and record the exception.
• Gate traffic through Agent Gateway where available: Agent Gateway governs Client-to-Agent (ingress) and Agent-to-Anywhere (egress) traffic over MCP, A2A, REST and gRPC, and blocks connections unless an IAM policy grants them. Google lists it as available for Agent Runtime and Gemini Enterprise, with GKE, self-managed Cloud Run and cross-cloud marked coming soon. See the MCP Security Guide.

Logging and detection

Two APIs write audit logs: agentidentity.googleapis.com (auth provider management) and agentidentitycredentials.googleapis.com (credential retrieval). Admin Activity logs are always written; Data Access logs are off by default for most Google Cloud services, so configure them at organisation level. See the Google Cloud Audit Logs and Log Sinks Guide.

Google's audit logging reference lists DeleteAuthorization and FinalizeCredentials as methods that produce no audit logs, so do not build detections that depend on them.

• IAM changes on agent principals: alert on SetIamPolicy anywhere that adds a member starting principal://agents.global. or principalSet://agents.global. with a role outside your approved list.
• Agent activity in service logs: query Admin Activity and Data Access logs where protoPayload.authenticationInfo.principalSubject contains the agent trust domain, then baseline the methods and resources per agent.
• Gateway telemetry: Agent Gateway writes access logs and OpenTelemetry traces to Cloud Logging and Cloud Trace; use them for tool-level denials and unusual destinations.
• Threat mapping: stolen tokens map to ATT&CK T1528 Steal Application Access Token and T1550.001 Application Access Token; misuse of the agent principal maps to T1078.004 Cloud Accounts.

Metrics that show the model is working:

• Share of deployed agents running with Agent Identity rather than a service account (target 100% on supported runtimes).
• Number of IAM bindings referencing deleted agent principals (target zero, checked weekly).
• Agent principals covered by a Principal Access Boundary policy, as a percentage of all agent principals.
• Auth providers with more than one agent principal allowed to retrieve credentials.
• Runtimes or requests with token binding disabled, each with a recorded exception.

Hardening baseline

1. Inventory first: list every agent on Agent Runtime, Gemini Enterprise and Cloud Run, its identity type (service account or Agent Identity), owner and the tools it calls. Agent Registry helps for destinations.
2. Enable Agent Identity at deploy: set identity_type to AGENT_IDENTITY (in .agent_engine_config.json for ADK deployments) and copy the principal from the Identity column on the Deployments page. Pilot one low-risk agent in a non-production project, since the feature is Preview.
3. Grant per agent: bind task roles to the single principal:// identifier on the narrowest resource. Use principalSet:// grants only for the documented baseline roles, if at all.
4. Apply a Principal Access Boundary: bind a PAB policy to the agent principal set //agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.container/projects/PROJECT_NUMBER listing only the projects or folders agents may reach. PAB policies only block, never grant; each principal set accepts up to 10 policies, each policy up to 500 rules. Check that the permissions you care about are in the policy's enforcement version.
5. Add deny policies: deny IAM policy changes, service account key creation and organisation policy changes to the agent principal sets.
6. Put the Agent Identity APIs in your perimeter: add agentidentity.googleapis.com and agentidentitycredentials.googleapis.com to the VPC Service Controls perimeter, route through restricted.googleapis.com, and use agent principals in ingress and egress rules. Run the perimeter in dry-run mode first.
7. Configure the auth manager: one provider per external system and authority type, retrieval limited to named agents, narrowest scopes, rotation owner recorded.
8. Turn on logging: enable Data Access logs for both Agent Identity APIs and route them to your central sink and SIEM.
9. Rollback: keep the previous service-account-based deployment available until the agent passes functional tests under Agent Identity; roll back by redeploying it, then remove its bindings once you cut over again.

Decision guidance: a small team with a handful of agents in one project can rely on per-agent grants, the auth manager and logging, and add PAB later. Organisations with many agent teams should start with PAB and deny policies at folder or organisation level, because the number of principals grows with every redeploy and per-grant review does not scale. If an agent runs outside the supported runtimes, keep using workload identity federation rather than service account keys; see the Workload Identity Federation Guide. For runtime controls beyond identity (memory, code execution sandbox, network egress), read the Vertex AI Agent Engine security guide.

Framework mapping

Common misconfigurations

• Orphaned bindings after deletion: Google states deleting an agent does not remove IAM bindings that reference its principal. They remain as inactive grants that clutter reviews and hide the real access picture. Remove them in the same pipeline that deletes the agent.
• Silent re-grant on redeploy: the identity derives from the hosting resource ID, so a redeployed agent with the same name and code gets a new principal. Teams that copy all old grants forward, or grant to a project-wide principal set to avoid the work, lose per-agent least privilege.
• Disabling token binding to fix a 401: setting the runtime-wide opt-out turns the agent's tokens back into bearer tokens that can be replayed if stolen. Fix the endpoint or use the per-request option.
• Open auth providers: granting retrieveCredentials to every agent in a project lets a compromised or prompt-injected agent pull another agent's GitHub or Salesforce tokens.
• Data Access logs left off: without them there is no record of which agent retrieved which credential, the event most investigations need first.
• Legacy bucket role assumptions: agent identities cannot be granted legacy Cloud Storage bucket roles such as storage.legacyBucketReader; workflows that rely on them fail, and teams sometimes fall back to a service account with broader rights. Use IAM roles on the bucket instead. See the Google Cloud Storage Security Guide.

Practitioner checklist

• Inventory agents on Agent Runtime, Gemini Enterprise and Cloud Run with identity type, owner and tools.
• Deploy new agents with identity_type=AGENT_IDENTITY and retire the service accounts they replace.
• Grant task roles to individual principal:// identifiers on the narrowest resource.
• Bind a Principal Access Boundary policy and IAM deny policies to agent principal sets.
• Add both Agent Identity APIs to the VPC Service Controls perimeter via the Restricted VIP.
• Limit each auth provider's IAM policy to named agents and the narrowest scopes.
• Keep token binding on; record any per-request bind_id_token=False exception.
• Enable Data Access logs for both APIs and alert on provider and IAM policy changes.
• Remove IAM bindings when agents are deleted or redeployed, and check weekly for stale ones.
• Recertify agent access on a schedule. See the Agent Identity Recertification.

Standards and references

• Google Cloud: Agent Identity overview
• Google Cloud: Agent identity for Agent Runtime
• Google Cloud: Authenticate using an agent's own identity
• Google Cloud: Agent Identity auth manager overview
• Google Cloud: Agent Identity audit logging
• Google Cloud: Principal Access Boundary policies
• Google Cloud: Agent Gateway overview
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Vertex AI Agent Engine security guide · Agent Identity and Access Guide · Google Cloud IAM and Service Accounts Guide