Give each agent a short-lived workload identity

Learning objective

Apply Agent Identity so that each deployed agent proves its own identity with a short-lived SPIFFE/X.509 credential and mutual TLS (mTLS). Distinguish this model from giving agents a shared, long-lived service account key. This lesson focuses on workload authentication, not delegated user OAuth or registry governance.

Core idea

Treat an identity as a name and a credential as temporary proof of that name.

Agent Identity assigns each agent a unique SPIFFE ID tied to the resource that hosts it. A SPIFFE ID is a URI such as spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH. The ID remains the principal that policies refer to. A managed X.509 certificate proves that the running agent controls that identity.

The certificate is intentionally short-lived. Google Cloud provisions it when the agent is deployed, keeps it current automatically, and sets each certificate to a 24-hour validity period. The Agent Identity overview describes this lifecycle. Short validity reduces the useful lifetime of leaked credential material, but it does not replace least-privilege authorization or runtime isolation.

How it works

The authentication path has four parts:

1. Assign a principal. Google Cloud derives a unique SPIFFE ID from the deployed agent’s hosting-resource URI. Grant IAM roles to the corresponding agent principal instead of to one shared workload identity.
2. Issue proof. The platform attests the running agent and supplies a managed X.509 certificate and private key. In SPIFFE terminology, an X.509 SPIFFE Verifiable Identity Document (X509-SVID) contains exactly one SPIFFE ID in a URI Subject Alternative Name. See the X509-SVID specification.
3. Authenticate both peers. During mTLS, the agent validates the server’s certificate, and the server validates the agent’s certificate against its trusted certificate authorities. The server extracts the authenticated SPIFFE ID and compares it with its policy. TLS also protects the connection in transit.
4. Authorize the request. Authentication establishes who called. IAM or the destination’s authorization policy separately decides what that principal may do. For direct Google Cloud API calls, Agent Identity uses mTLS by default and obtains an access token cryptographically bound to the agent’s X.509 certificate. A copied token cannot be replayed from a client that lacks the matching private key; see Agent credentials.

Both sides must validate certificates and trusted issuers correctly. A TLS connection that validates only the server is ordinary one-way TLS, not mTLS and not proof of the agent’s SPIFFE identity.

Key distinctions and trade-offs

This comparison is about long-lived service account keys, not service accounts as a whole. An attached service account, service account impersonation, or Workload Identity Federation can issue short-lived credentials without a downloaded key. Google Cloud explicitly classifies service account keys as long-lived credentials and documents that user-managed keys do not expire by default; see Service account credentials and expiry times for user-managed keys.

Per-agent identity adds policy objects and lifecycle work. Deleting an agent does not remove IAM bindings that name it, and a replacement resource receives a new principal even if it has the same display name. Clean up stale bindings and grant the replacement explicitly. For a custom destination, you must also distribute the correct SPIFFE trust bundle and make its TLS and authorization layers understand SPIFFE IDs. Use Agent Identity where the hosting platform and destination support this trust model; do not weaken certificate validation to force compatibility.

Architecture / decision scenario

A company deploys separate purchasing and inventory agents. Both call a Google Cloud data service. The purchasing agent may write purchase orders; the inventory agent may only read stock levels. A proposed design places the same service account JSON key in both deployments because it is easy to configure.

Choose a distinct Agent Identity for each agent. Bind the write role only to the purchasing agent’s principal and the read role only to the inventory agent’s principal. Each runtime receives its own managed X.509 certificate. Direct calls to the Google Cloud API use mTLS and a certificate-bound access token. Logs and policy decisions can therefore distinguish the two callers.

The shared-key design creates a larger blast radius: compromise of either agent exposes a reusable private key with the union of both agents’ permissions. Key rotation also requires finding every copy. With Agent Identity, certificate renewal is automatic and credentials are separated by agent. However, a compromised live runtime can still exercise its present permissions. Narrow IAM roles, isolate runtimes, and stop the affected agent; short lifetime is damage containment, not complete protection.

Common exam traps

• Treating the SPIFFE ID itself as a rotating secret. It is the principal name; the X.509 certificate is the rotating credential, and its private key proves possession.
• Assuming mTLS grants permission. It authenticates both connection endpoints; an authorization policy must still permit the requested action.
• Calling any TLS connection mTLS. The server must request and validate the client’s certificate as well as present its own.
• Saying all service account credentials are long-lived. User-managed service account keys are long-lived by default, but Google Cloud also issues short-lived service account credentials.
• Assuming certificate expiry removes IAM access. Expiry invalidates one credential; IAM bindings and the agent principal have their own lifecycle.
• Assuming a short-lived credential makes a compromised agent harmless. The attacker can use the agent’s allowed capabilities while the runtime remains compromised.

What to remember

• Give each agent a distinct SPIFFE ID and grant permissions to that principal.
• Use the managed, short-lived X.509 certificate as proof of identity.
• Use mTLS to authenticate both peers and protect the channel; authorize separately.
• Prefer certificate-bound, automatically renewed credentials over shared service account keys.
• Distinguish long-lived service account keys from short-lived service account credentials.

Knowledge check

References

• Google Cloud, Agent Identity overview
• SPIFFE, SPIFFE concepts
• SPIFFE, X.509 SPIFFE Verifiable Identity Document
• Google Cloud, Service account credentials
• Google Cloud, Best practices for using service accounts