GCP Agent Identity Auth Manager and APIs: What GA Changes

Last Updated on August 26, 2026 by Arnav Sharma

On 22 August 2026, Google Cloud moved the Agent Identity auth manager and the Agent Identity APIs to general availability. Read it quickly and it looks like a convenience feature. Read it as an architect and something larger is happening. GCP’s Agent Identity auth manager and APIs represent a specific, opinionated answer to the hardest question in agentic security, and it is not the same answer Microsoft gave, nor the one the Model Context Protocol working groups are converging on.

The question is deceptively short. Who is the agent, and on whose authority does it call the tool?

Google answers with a broker that holds delegated secrets on the agent’s behalf. Microsoft answers with a directory object that carries policy. MCP answers with a federated token exchange. Those bets produce different failure modes and very different experiences at three in the morning. That comparison is what this article is for.

What went GA on 22 August 2026

The announcement is the last step in a sequence that started in April, and several capabilities people assume arrived together did not.

Date	Capability	Launch stage
22 April 2026	Agent Identity (cryptographic, SPIFFE-based identity per agent)	GA
22 April 2026	Auth manager for Agent Identity	Preview
22 April 2026	Privileged Access Manager support for agent identities as requesters and approvers	Preview
18 June 2026	Agent Identity API (agentidentity.googleapis.com), replacing the legacy Connectors API	Preview
14 August 2026	Organization Policy custom constraints for Agent Identity resources	GA
14 August 2026	VPC Service Controls integration for the Agent Identity APIs	GA
22 August 2026	Auth manager and the Agent Identity APIs	GA

First, the perimeter controls landed eight days before the thing they protect. You can now add the Agent Identity API and the Agent Identity Credentials API to a VPC Service Controls perimeter and specify agent identities in ingress and egress rules. A secrets vault without a perimeter is a data exfiltration primitive.

Second, the Agent Identity APIs replace the legacy IAM Connectors API to manage auth providers and agent identities. If you built against it during preview, that is migration work, not a no-op. Google’s guidance is explicit that the legacy connectors API will not reach general availability.

One caveat for any design review: parts of the surrounding Gemini Enterprise Agent Platform documentation still carry pre-GA terms even where the underlying IAM primitive is GA. Not everything beside a GA feature is GA.

Why agent identities are a new category

Traditional identity and access management sorted the world into two buckets. Human identities are interactive, consent-capable and accountable. Machine identities are static and bolted to infrastructure. Agent identity differs from both: non-deterministic like a person, unattended like a service, and able to switch between acting for itself and acting for someone else inside one session.

Forcing agents into either bucket fails predictably. Human identity management patterns produce consent prompts nobody is present to answer. Traditional identity management patterns produce shared, over-permissioned principals no audit trail can disentangle. AI agent identity management is a third category, and both vendors have now built for it explicitly.

The consequence is scale. A serious estate means each agent needs its own principal, grants and trail, which is why a durable identity for AI agents matters. Agent identity management establishes a unique identity for each agent rather than a pool of shared secrets, and existing access policies can then name that principal directly. An agent identity management system that cannot do this collapses back into shared service accounts within a quarter, which is exactly what happened to the first wave of identity management solutions retrofitted for AI agent identities.

If you want to manage agent identities effectively, every call needs three answers: which agent made it, whether the agent is authorized for that resource, and whose authority it carried. Agent authentication answers the first. IAM answers the second. Only the delegation model answers the third, and that is where the vendors diverge.

How GCP’s Agent Identity auth manager and APIs actually work

Understanding how agent identity works means starting with the identity itself, because the broker is meaningless without it.

When you deploy an agent, Google Cloud assigns each agent a unique SPIFFE identity and an X.509 certificate, with that certificate rotated on a 24 hour cycle. This is a genuinely different class of identity from what came before. Unlike service accounts, agent identities are not shared by multiple workloads by default, cannot be impersonated, and do not allow developers to generate long-lived service account keys. Access tokens minted for Google Cloud services are cryptographically bound to that certificate, which makes a stolen token useless outside the runtime that holds the matching key.

That is the strong part of the design. Certificate binding turns token theft from a full compromise into a nuisance, and it is a verifiable identity rather than a claimed one. Agent credentials of this kind prove that a particular process made a particular call, which is the foundation of any secure agent deployment. Whether the agent is acting for itself or for a person is a separate question, and the agent’s identity material is identical either way.

The auth manager solves a different problem: outbound authentication to everything that is not Google Cloud. When AI agents interact with external tools such as BigQuery, Jira or GitHub, they need a secure mechanism to authenticate outbound requests, and the auth manager provides it by acting as a centralized credentials vault and authentication broker. You create auth providers, which are the configurations that acquire and hold API keys, OAuth client IDs and secrets, and delegated end-user tokens. Three provider types are supported: 3-legged OAuth for user-delegated access, 2-legged for the agent’s own authority, and API keys.

Which credential the agent uses depends on whose authority the call is being made under, and that choice is made in configuration.

The two trust models nobody contrasts

Here is the part the documentation never puts side by side. Google describes two different secret-handling paths, in two different documents, with materially different security postures.

In the direct path, the Agent Development Kit intercepts the tool call, requests the secret from the vault, and the auth manager returns that credential to the agent, which then attaches it to the outbound request. The secret lands in the agent’s process memory.

In the gateway path, when the agent identity is used with Agent Gateway alongside Gemini Enterprise, end-user credentials are encrypted by the auth manager and decrypted at the gateway, so that the agent can never access the raw credential.

Those are not two descriptions of one thing. They are two architectures.

	Direct ADK path	Agent Gateway path
Where the secret is decrypted	In the agent runtime	At the gateway
Does agent code see the raw credential	Yes	No
Blast radius of a prompt injection that dumps process memory	Live token for the target tool	Nothing usable
Blast radius of a compromised dependency in the agent	Live token	Nothing usable
Egress policy enforcement point	Agent’s own network path	Gateway
Transport binding	mTLS to Google Cloud APIs	mTLS to gateway, DPoP beyond it

Take one thing from this article: an agent runtime is an environment where untrusted text routinely reaches a component that can be talked into things. Putting a live third-party access token into that process is a decision, not a default you inherit. The gateway path matches the threat model. The direct path is what most quickstarts show, because it is fewer moving parts.

That distinction is the single most consequential thing in the GA release, and no vendor page states it as a trade-off.

Three answers to one question

All three are trying to establish who the caller is and whose authority it carries. Each makes a different structural bet.

Dimension	Google Cloud	Microsoft	MCP
Core primitive	Credential broker plus SPIFFE identity	Directory object plus policy engine	Federated token exchange
Where authority lives	In the vault, as stored secrets	In the directory, as assignments	In the token, as claims
Identity substrate	SPIFFE ID, X.509, 24 hour rotation	Agent identity, blueprint, blueprint principal, agent user	Whatever the authorisation server issues
Delegation mechanism	Auth provider type chosen per tool	On-behalf-of or autonomous assignment	RFC 8693 exchange, audience rebinding
Policy enforcement point	Identity and Access Management, Organization Policy, VPC Service Controls, the gateway	Conditional Access, ID Protection, access packages	The resource server, per call
Scope of the answer	Agents on the platform	Agents in the Microsoft estate	Any client and any server
Maturity as of August 2026	GA 22 August 2026	Agent ID GA April 2026, Agent 365 GA 1 May 2026	Spec revised 28 July 2026, working group forming

Google: a broker that holds delegated secrets

The bet is that the hard part is secret handling, so the platform takes custody and hands out only what is needed, only to attested callers. The strength is that the identity underneath is cryptographic rather than declarative, and IAM already knows how to reason about it. Agent identity management secures the outbound path by removing secrets from application code entirely.

The weakness is structural and follows directly from the strength: the vault knows everything.

Microsoft: a directory object with policy attached

Microsoft’s bet is that agents are a new principal type in an existing directory, and existing governance machinery should extend to cover them. Entra Agent ID introduces four object types: agent identity blueprint, blueprint principal, agent identity and agent user. Agent identities start with limited permissions inherited from their parent blueprint, and can have resource access assigned through access packages. Agent 365, GA since 1 May 2026, is the control plane and registry on top.

The strength is governance maturity. Access packages, entitlement management, lifecycle workflows and attestation already exist for humans, and extending them to a new principal type is a smaller leap than building governance from scratch. Identity governance for agents is not a research project here, it is a licensing decision.

The weakness is that a directory object tells you who the agent is, not what it did with a third-party secret. The model is strong on authorisation and quiet on custody of secrets used outside the Microsoft estate.

MCP: a federated token exchange

MCP’s bet is the most conservative and, in my view, the most durable: invent nothing. Its agent identity work focuses on Workload Identity Federation, the Identity Assertion JWT Authorization Grant used by Enterprise-Managed Authorization, and RFC 8693 token exchange, coordinated with the IETF OAuth and WIMSE working groups. The specification forbids token passthrough and requires audience validation, so a server calling a downstream API for a user must obtain a new token issued for that audience rather than reuse the incoming one.

The strength is that delegation becomes a property of the token rather than a property of a configuration screen. A token exchanged under RFC 8693 carries an actor claim, so the chain is legible in the artefact itself.

The weakness is that a specification is not a product. There is no vault, no lifecycle, no console, and no answer for tools that only accept an API key.

The failure-mode comparison nobody publishes

Comparing feature lists is easy and mostly useless. Compare what happens when each model fails.

Failure	GCP	Microsoft	MCP
Compromised agent runtime	Direct path leaks live token; gateway path leaks nothing usable	Leaks bound token, replay limited by Conditional Access	Leaks short-lived audience-bound token
Compromised broker or vault	Catastrophic; every stored secret for every tenant path in scope	Not applicable, no equivalent secret custody	Not applicable, no equivalent secret custody
Over-permissioned identity	IAM allow policy too broad on the agent principal	Blueprint grants inherited too widely	Scope union too broad at consent
Stolen token replayed elsewhere	Blocked by certificate binding	Blocked by Conditional Access conditions	Blocked by audience binding, DPoP where implemented
Wrong authority used	Silent; the call simply succeeds under the wrong principal	Silent unless assignment differs	Visible; wrong audience is rejected
Detection latency	Cloud Audit Logs, minutes	Sign-in and audit logs, minutes to hours	Immediate at the resource server

A broker centralises secrets, so it centralises blast radius

This is not a criticism unique to Google. It is the cost of the architecture, the same one every secrets manager has carried. But it changes shape when the consumer is an autonomous system rather than a deployment pipeline.

A traditional secrets manager is called by code you wrote, at times you predicted, for resources you enumerated. A credential broker for autonomous AI agents is called by a non-deterministic process, at times nobody predicted, for whichever tool the model decided to reach for. The vault is doing the same job under worse assumptions.

The mitigations exist and you should use all of them. Organization Policy custom constraints, GA since 14 August 2026, restrict how those resources are created and configured. VPC Service Controls puts a perimeter around the API so a stolen caller token cannot pull secrets to an attacker-controlled project. Granular SPIFFE ID access control means a specific agent principal reaches only the providers it has been granted.

Use them. But understand what you have built: a single, high-value, always-available store of live third-party secrets, reachable by processes that read untrusted input. That belongs in the risk register as its own line item, not a footnote to the agent programme.

On whose authority? Configuration versus protocol property

This is the deeper problem, and it is the one I expect to cause real incidents.

In the broker model, the difference between an agent acting as itself and an agent acting on behalf of a user is which auth provider you configured. Pick a 3-legged provider and the call carries a user’s delegated token. Pick the 2-legged OAuth auth provider in Agent Identity and the same tool call runs under the agent’s own authority. The agent code can be identical. The tool is identical. The audit record differs, but only if you know to look.

In the token exchange model, that distinction is carried in the token. An exchanged token that preserves a subject and adds an actor claim is structurally different from a client credentials token. A resource server can tell them apart without knowing how the caller was configured, because the difference is in the protocol rather than a console.

Google has made delegation a deployment-time setting. MCP is making it a wire-level property. Microsoft sits between, distinguishing on-behalf-of from autonomous assignment in the directory: better than a per-tool setting, weaker than a claim on the token.

Configuration drifts. Protocols do not.

The 3am audit trail

An agent has done something wrong. Money moved, a record changed, data left. You have been paged. What can you reconstruct?

On Google Cloud, you have two audit log streams, one for the Agent Identity API and one for the Agent Identity Credentials API, plus Cloud Audit Logs for whatever the agent touched. When an agent acts on a user’s behalf, logs show both the agent’s and the user’s identities. The identity is unambiguous because it is a SPIFFE ID bound to a certificate, so you know precisely which deployed agent made the call.

What you will not have is the third-party side. The vault logs that a credential was issued. The tool logs that a request arrived with a valid one. Correlating the two across a SaaS audit log with different timestamps, different identifiers and a retention window you do not control is the actual work, and nothing in the GA release makes it easier.

On Microsoft, the agent appears in sign-in logs as a first-class principal alongside interactive users, service principals and managed identities. Conditional Access evaluation results are recorded, which tells you not only what happened but which policy allowed it. If access came through an access package, the entitlement trail tells you who approved it and when. That is the richest governance narrative of the three.

The gap is symmetrical to Google’s: outside the Microsoft estate, custody of the secret is somebody else’s problem, so the trail thins at the boundary.

Under MCP token exchange, the audit story is the most elegant and the least available. Because delegation is carried in the token, a correctly implemented resource server can log the full chain: this subject, via this actor, for this audience, with these scopes. Every action the agent takes is attributable without joining across systems. The catch is that “correctly implemented” carries enormous weight, and many servers in the path will not validate audience, refuse passthrough or log the actor claim.

Agent actions are only as reviewable as the weakest log in the chain, and in all three models that weakest link sits outside the identity platform. Summarised honestly: Microsoft gives you the best governance trail, MCP gives you the best attribution model, and Google gives you the strongest proof that the caller was who it said it was.

What I would deploy in a regulated environment

An opinion, clearly labelled as one.

For agents that operate entirely inside Google Cloud and touch only first-party services, Agent Identity alone is the strongest option any vendor offers today. Certificate-bound tokens that cannot be replayed outside their runtime solve a problem Conditional Access solves probabilistically and bearer tokens do not solve at all. I would not use service accounts for a new agent workload.

For agents that reach third-party tools in a regulated environment, I would deploy the auth manager only behind Agent Gateway, and I would treat the direct ADK path as unsuitable for anything touching regulated data. I can defend a design in which agent code never holds a live third-party secret. I cannot defend one where a prompt injection and a memory disclosure bug are all that stand between an attacker and a production token for a payment system.

I would also insist on three things that are easy to skip. Put the Agent Identity APIs inside a service perimeter on day one. Write Organization Policy custom constraints before the first provider is created, not after the fiftieth. And require that every agent action reaching a regulated system runs under user-delegated authority, so that the accountable human is named in the record rather than inferred from a roster.

Where the estate is Microsoft-centric, use Entra Agent ID and Agent 365, and accept that you are buying governance depth rather than secret custody. Where you are building your own agent platform, build to the MCP authorisation model and adopt token exchange now, because the AI agent governance and identity and governance controls you will be asked for in two years are far easier to retrofit onto audience-bound tokens than onto a configuration table.

What I would not do is pick one model and pretend it is complete. This is not a Google Cloud Next keynote slide, it is a release note, and the honest reading is that three vendors are building partial answers to a problem nobody has finished specifying.

Operational notes before you enable this

A short list of things that will bite.

• Migrate off the connectors API deliberately. Existing auth providers were mirrored into the new hierarchy during preview, but your IAM policies, agent code and client applications reference the old paths. Plan it as a change, not a cutover.
• Check regional availability. The auth manager runs across the Americas, Europe and Asia Pacific, but vault data residency is a real constraint and is not uniform.
• Do not opt out of token binding. Google Cloud documentation notes an escape hatch for injecting tokens directly in a header. Taking it removes binding protection and makes short-lived tokens replayable. Treat any request to use it as a design failure.
• Certificates rotate every 24 hours. Anything caching the agent’s identity material for longer fails in ways that look like intermittent authorisation errors.
• Watch the launch stage per page, not per product. Several adjacent surfaces are still pre-GA. Verify at deployment time.

The GA of the auth manager and its APIs is a real advance, and the SPIFFE foundation underneath it is the most defensible identity substrate any of the three vendors has shipped. Just be clear-eyed. You are not removing credential risk. You are relocating it, from a thousand config files into one well-defended box, then pointing a non-deterministic process at that box and asking it to be sensible.