Google Agent Identity Auth Manager Is Now Generally Available, Moving Agent Credentials from Application Code to a Separate Control Plane

Google Cloud announced on August 22 that Agent Identity auth manager, `agentidentity.googleapis.com`, and `agentidentitycredentials.googleapis.com` are now generally available. The change addresses a practical risk in agent systems: once agents begin interacting with GitHub, CRM platforms, or internal APIs, storing long-lived tokens in prompts, environment variables, or standard application configuration can create an excessively broad credential exposure surface across models, tool executors, and logs.

The new architecture separates “who the agent is” from “which external credentials it can obtain.” After deployment, an agent first authenticates using its dedicated Agent Identity, then requests credentials from a provider bound to the auth manager. It currently supports static API keys, two-legged OAuth without user interaction, and three-legged OAuth for authorization delegated by individual users. Administrators can manage providers using `roles/agentidentity.editor` or custom roles, and can suspend, update, or delete configurations, as well as restore them during a 30-day soft-deletion period.

For engineering teams, the value goes beyond eliminating some OAuth code. Agent identities, user delegation, and third-party secrets can now be audited separately, while Organization Policy and VPC Service Controls can be used to restrict resource fields and network boundaries. Google has also stated explicitly that the preview IAM Connectors API will not become generally available. Users must rebuild their providers and API calls rather than assume the endpoints will be upgraded in place.

Centralized credential storage, however, does not automatically enforce least privilege. Deployers remain responsible for the scopes granted by providers, the tools available to agents, and whether credentials enter tool logs after retrieval. The next areas to watch are whether tokens gain finer-grained, per-call constraints; how broadly third-party SaaS providers are supported; and whether cross-cloud or self-managed agents can adopt the same identity boundary.