AI agent identities: Google Cloud rolls out its access manager

Google Cloud announced the general availability of its Agent Identity authentication manager and associated APIs. This evolution responds to a problem that has become central: when an agent acts on several tools, it should not blindly reuse user IDs or keep permanent secrets in its code.

An agent needs his own identity

Traditional applications already distinguish human accounts, service accounts and workloads. Agents add a difficulty: they can be created dynamically, act on behalf of a person, use multiple tools during the same task and maintain a state for a variable duration. A simple API key copied into an environment variable does not describe who requested the action or what the agent was allowed to do.

Google presents Agent Identity as a highly attested cryptographic identity, linked to the life cycle of the resource that hosts the agent. The authentication manager then acts as a centralized safe and broker for outgoing connections to third-party services.

Three authentication modes covered

The service supports three actors OAuth, when the user must consent to the agent's access to a service; The two-part OAuth, suitable for service-to-service exchanges; and the API keys, still used by many tools. The interest of a central broker is not only to store secrets. It allows normalization of attribution, rotation and use without exposing them directly to all components.

APIs agentidentity.googleapis.com and agentidentitycredentials.googleapis.com replace the old IAM Connectors API for managing authentication providers and agent identities. Google had planned a migration phase during which existing resources were reflected in the new hierarchy in order to gradually move policies and applications.

Why an identity per agent improves audit

With a shared account, logs only indicate that a generic application used a resource. With a distinct identity, it becomes possible to link an operation to an agent, his environment and the policy that granted him access. This facilitates the analysis of an incident and the application of any privilege.

This granularity is particularly useful for specialized agents. A support agent can read a documentary database and create a draft response without changing the billing. A commercial agent can enrich a CRM without accessing infrastructure secrets. A development agent may open a merger application without the rights to deploy in production.

The secret box is not enough: the delegation must be limited

A secure architecture must distinguish between the identity of the agent, the person who launches the task and the identity actually used with the tool. The delegation must remain explicit. A user authorized to view a data should not automatically allow all agents in their organization to read it.

The length and scope of tokens must also be defined. Ephemeral identifiers reduce the consequences of a leak, while targeted authorisations avoid that a limited task has global access. When a tool only offers a static key, the broker can improve storage and rotation, but it cannot invent a granularity that the remote service does not provide.

Organisational safeguards become available

Google Cloud has also made available the custom organizational policy constraints on Agent Identity resources as well as integration with VPC Service Controls. An organization can frame the creation or modification of authentication providers, place APIs within a service area, and specify the entry and exit rules for agent identities.

These controls bring agents closer to the usual cloud governance practices. They allow platform and security teams to establish common rules, rather than let each prototype invent its own secret storage.

A method of progressive implementation

1. Inventory of actions: list the tools called, the data consulted and possible changes.
2. Separate roles: create different identities for agents who do not have the same responsibilities.
3. Reduce Authorities: provide only the necessary operations from the necessary resources.
4. Shorten duration: prefer temporary tokens and revoke access when the agent disappears.
5. Set context: maintain the identity of the originator user, task, tool and result.
6. Test diversions: simulate a quick injection, a compromised tool and an attempt to access outside the perimeter.

What the application still needs to decide

Identity Agent manages authentication; it does not replace the business rules of application. The fact that an agent is recognized does not mean that all their applications must be accepted. Irreversible or financial transactions may require human validation, double control or contextual policy.

The confidentiality of newspapers should also be considered. A useful audit trail describes the action and its result, but must not copy a token, a sensitive document or the entire prompt containing personal data. Observability depends as much on what is excluded as on what is retained.

A foundation to industrialize without trivializing the risk

The first prototype agents often start with a shared key because it is the shortest path. This solution becomes fragile as the number of tools, users and environments increases. The general availability of a dedicated identity service shows that the ecosystem is gradually moving from demonstration to controlled exploitation.

For a company, the benefit is not just a specific cloud product. It resides in the architecture model: a verifiable identity by agent, a broker of secrets, limited tokens, central rules and an audit trail. These principles remain valid regardless of which supplier is selected.

View Google Cloud's IAM version notes · Prepare a controlled agent architecture with SDX →