Google makes agent Auth Manager generally available Google makes agent Auth Manager generally available

Credentials move into a managed service

Auth Manager centralizes credentials in a Google-managed vault controlled through Identity and Access Management. Google says it automates OAuth authorization flows and refreshes tokens delegated by users. The service had appeared in preview in Google’s May security announcement. Its move to general availability changes the launch stage for that credential-management component. The separate token preview covers agents proving their own identity to systems outside Google Cloud, including other clouds and privately operated services.

The identity belongs to a particular agent

Google’s identity documentation describes a cryptographic identity based on the SPIFFE standard for each agent. Auth providers within the manager define the credential type and destination application. They can manage API keys, OAuth client credentials and user-delegated tokens. This gives an application different routes for different integrations, rather than one shared credential for every call. The documented model distinguishes an agent reading a user’s tasks from an autonomous workload accessing infrastructure. Those calls can originate in the same product while carrying different authority and appearing differently in audit records.

Delegation keeps both parties in the record

The delegation architecture separates three contexts: the person making a request, the agent running it and the combined authority used downstream. For a user-delegated call, Google says the request must satisfy the agent’s outbound policies and the user’s permissions and consented OAuth scopes. Logs record both identities. That structure makes the authorization decision more specific than recognizing the software alone. An agent’s identity answers which workload called. The delegated context additionally identifies whose access it is exercising, so a later investigation can distinguish the two.

External services still make an access decision

The external-token preview uses OpenID Connect identity tokens signed for the agent’s trust domain. Google publishes discovery metadata and public verification keys, so a receiving service can check them without Google Cloud credentials. Its guide separates signature validation from authorization. After checking the issuer, intended audience and time claims, the receiver evaluates the agent identifier against its own trusted set. That final check matters: a valid token identifies its caller, but the application still decides which protected resources that caller may use.

Shared service accounts are a different model

Google contrasts agent identities with conventional service accounts. The identities are not shared across workloads by default, cannot be impersonated and do not allow developers to create long-lived service-account keys. The documentation also describes certificate-bound access tokens for Google Cloud calls. These properties put the workload itself into the authentication design. For an application with several agents, that means their identities can remain distinct even when they serve the same user.