GCP Workload Identity Federation for Autonomous Agent Services

GCP Workload Identity Federation uses short-lived credentials in place of stored service account keys, which removes a major risk for autonomous agent services. But keyless access is only the start. Agents also need narrow permissions, a traceable identity through delegated calls, and governance that follows their actions. WIF and Agent Identity provide the GCP foundation, provided their configuration and lifecycle receive as much attention as deployment.

Why autonomous agents break the assumptions behind service account keys

A leaked JSON service account key works for anyone who has it and, without rotation, may take years to expire. Static keys can remain valid for up to ten years and rarely get rotated. A key can be copied, committed to a public repository, and found by an attacker without its owning team knowing. Unrotated credentials enabled the Snowflake customer breaches, while a stored service account credential started the 2023 Okta incident.

Autonomous agents make that weakness structural. They inherit permissions designed for human-operated pipelines, then use them at machine speed in sequences no operator specified. A CI/CD pipeline calls endpoints that are fixed at build time. An agent discovers tools at runtime, so its credential may cover an unpredictable call graph across several trust domains. The resulting blast radius scales with the agent’s autonomy.

What Workload Identity Federation actually does and how GCP implements it

WIF replaces a stored secret with runtime proof of identity. In the OIDC flow, the workload’s native platform issues a signed token, which the workload presents to Google Cloud’s Security Token Service, or STS. STS validates it against a configured trust relationship and returns a short-lived access token for use with configured IAM permissions. Google Cloud’s documentation also lists support for AWS, Azure, Active Directory, X.509 client certificates, GitHub, GitLab, and OIDC or SAML 2.0 providers.

Attribute mapping takes claims from the external token and turns them into Google token attributes. An attribute condition, written in Common Expression Language, then restricts which external identities are accepted. Authentication does not itself grant resource permissions. With direct resource access, the federated principal receives a role on the target resource. With service account impersonation, the external identity gets the Workload Identity User role on a service account and acts through it, so the audit chain has another principal.

That separation explains why, on a first attempt, token exchange often succeeds but every API call returns a 403. When WIF is not enabled, any pod can get the underlying worker node’s Google Cloud credentials through the metadata server.

Where standard WIF reaches its limit with agentic workloads

Standard WIF resolves the first authentication hop. An agent may authenticate to an identity platform, call internal APIs, then need separate credentials for Salesforce, GitHub, and Slack. Each step crosses another trust boundary. How does the agent obtain narrowly scoped access, and how does that action trace back to the originating user or workload? WIF alone provides no built-in answer for the whole chain, especially when tools are discovered at runtime.

The records fragment at those same boundaries. The external issuer logs token issuance, GCP logs role assumption, and the downstream service logs the action. Connecting them requires deliberate configuration. Google’s documentation says that projects with workload identity pools need Data Access logs on both the Security Token Service API and the IAM API. Without those logs, an action may appear under an impersonated service account with no record of the external caller, so an investigation can go no further than the federation boundary.

WIF configuration also needs protection from overbroad trust. Tenable’s research identifies a default choice that grants service account access to every identity in a pool, regardless of its environment. The same research describes how an attacker with iam.workloadIdentityPoolProviders.update can attach their own AWS account ID and federate into a privileged service account. These permissions have security consequences. With keyless roles, there is also no rotation event to prompt access reviews, so teams lose a governance check that token exchange alone cannot provide.

How GCP's Agent Identity extends WIF with per-agent cryptographic attestation

Google Cloud’s Agent Identity became generally available on 22 April 2026 and added a separate IAM primitive based on the SPIFFE standard. The August 2026 auth manager general-availability milestone anchors the production-ready picture. Each deployed agent gets a unique SPIFFE ID and an X.509 certificate that is valid for 24 hours. Google Cloud renews the certificate automatically. This gives the agent an attested identity of its own rather than relying solely on the identity of its hosting workload.

Google Cloud’s Agent Identity documentation says that access tokens made for Google Cloud APIs are cryptographically bound to the agent’s X.509 certificate. A bound token is valid only over a mutual TLS connection authenticated with that certificate. Stealing the token alone is not enough. Traffic through Agent Gateway adds DPoP protection, binding token use to the agent’s certificate key through mTLS and DPoP. The protection targets replay from a different client.

That identity also supports authentication to MCP servers, cloud resources, other agents, and external endpoints, either for the agent itself or on an end user’s behalf. The SPIFFE ID remains stable throughout the agent’s lifetime. Audit records can therefore be correlated by agent principal rather than reconstructed solely from token exchanges and shared service accounts. Automatic certificate renewal handles credential maintenance, though it does not replace a review of the agent’s permissions.

The operational traps that appear after Agent Identity is configured correctly

An agent’s identity is derived from the resource ID of its host resource. Deleting it and deploying a replacement produces a new principal, even when the display name, code, and configuration are identical. The old IAM bindings do not follow it. A continuous-delivery process that treats replacement as an ordinary update can therefore leave the new agent without access. Identical packaging does not make it the same principal.

On Vertex AI, the execution environment poses a separate risk. XM Cyber and Unit 42 documented attack paths in which users with read-only Viewer-level permissions could get service agent credentials and use them to gain project-wide access to Cloud Storage, BigQuery, Pub/Sub, and Artifact Registry. Code in a custom training job, Ray cluster head node, or deployed Agent Engine reasoning engine can query the metadata endpoint without authentication for the attached service agent’s OAuth 2.0 token. That token reflects the service agent’s broad, project-scoped permissions. As of the January 2026 disclosure, Google classified the Agent Engine and Ray on Vertex AI vulnerabilities as “working as intended,” with no remediation planned at that time.

Correct per-agent identity configuration still leaves surrounding permissions to govern and deletion cleanup to perform. Google’s documentation says that when an agent is deleted, its IAM bindings stay in project policies as inactive grants, which must be removed during decommissioning. Frequent replacement compounds this residue even as replacement agents require fresh grants. Without lifecycle cleanup, the policy becomes a guest list populated by ghosts.

Configuring WIF and Agent Identity for scoped, auditable agent access

GKE-hosted agents need WIF enabled at both cluster and node pool level to prevent access to node-level credentials through the metadata server. Where service account impersonation is used, each Kubernetes service account should be annotated with the GCP service account it is permitted to impersonate, with the corresponding IAM grant scoped accordingly. Pool and provider ownership belongs in this initial setup. A documented review schedule supplies the checkpoint that key rotation no longer provides.

Attribute conditions should restrict acceptance to the exact repository, branch, Kubernetes namespace, or cloud role. Treat changes to these conditions as IAM policy changes. For resource access, grant roles directly to the federated principal where possible so that access does not need an extra impersonation step. Where impersonation is required, scope the Workload Identity User grant only to the intended identity and specific service account.

Audit configuration comes before declaring access ready. Enable Data Access logs for both STS and IAM in every project containing a workload identity pool so that token exchanges and impersonation remain traceable. For Agent Identity deployments, use the SPIFFE ID to correlate audit queries within each agent’s lifetime. Then automate IAM grants in the deployment pipeline and binding removal in the decommissioning pipeline.

The multi-cloud boundary that GCP Agent Identity does not cross

Agent Identity governs agents within Google’s control plane, but it does not provide a shared trust anchor for AWS workload identities, Entra Agent IDs, and Vertex’s SPIFFE-based identities. This is a platform boundary. An agent calling AWS after authenticating through Agent Identity needs a separate AWS-side credential or independently maintained trust brokering. The supplied documentation establishes no standards-based route that makes a GCP SPIFFE identity directly consumable as an AWS or Azure federated credential without custom configuration on both sides. Strong identity within GCP does not automatically become portable authority elsewhere.

Even when each cloud’s logs are complete, they sit in separate systems with no shared principal identifier, so they do not by themselves give a continuous account of the agent’s actions. Runtime monitoring above any single cloud’s identity layer supplies the next governance layer. Such a capability can discover running agents, observe API traffic, compare behavior with declared policy, detect anomalies, and produce unified audit logs across clouds. It complements the cloud’s authentication controls by following behavior where a single provider’s identity plane stops.

The governance posture that makes WIF and Agent Identity operationally sustainable

List the existing service account keys and plan how to replace them with federation. Leaving them in place preserves their original exposure. Monitoring new key creation is also necessary where iam.disableServiceAccountKeyCreation is not enforced, because a newly created key can silently restore the risk federation was meant to remove. Giving the trust configuration a named owner and setting times to review it keeps it under scrutiny after migration.

Those reviews must be paired with visibility into behavior. An agent can stay within its IAM permissions while using an allowed tool in an unintended context or exceeding the delegation its user authorized. Permission is not a statement of purpose. Runtime monitoring compares observed actions with declared policy, flags anomalies before they complete, and preserves the context needed to investigate them. This is the ongoing enforcement that a correct deployment configuration cannot supply on its own.

The final test is what an audit can establish. Authentication records show which identity obtained or used a credential, but they do not alone explain the agent’s conduct. A regulated environment needs the actions as well. Its complete audit trail must connect what the agent did to the user or workload on whose behalf it acted.