On September 1, Cloud Run's release notes added Agent Platform features: you can now authenticate AI agents and MCP servers on Cloud Run services and jobs using system-managed Agent Identities, with automatic registration in the Agent Registry. It is Preview. It is also the first Agent Identity release that lands on infrastructure I run. My public site and its analytics services run on Cloud Run, some of my private apps sit behind IAP, and my personal agent platform hosts MCP servers.

An Agent Identity is a first-class IAM principal, not a new label for a service account. It is unique to the agent, cryptographically attested, lifecycle-bound, and expressed as a SPIFFE ID. Access tokens are bound to the agent's X.509 certificate, so a stolen token is harder to replay outside its trusted runtime. Google's docs are blunt about the difference: unlike service accounts, agent identities "can't be impersonated, and don't allow developers to generate long-lived service account keys."

That fixes a real ambiguity. If five agents share one service account, the log proves which credential called an API but not which agent decided to. The Cloud Run change matters because it moves that principal from something you provision by hand to something the runtime issues once the service is configured for it. Fleets converge on defaults, not on provisioning guides.

Service accounts are not obsolete. A batch job still needs a workload identity, not an agent persona. The dividing line is behavioral: an agent picks tools at runtime and can produce a materially different sequence from the same prompt.

The model also separates two kinds of authority: an agent acting as itself, and an agent acting for a user through delegated OAuth. "May read the fare table" and "may book a flight for Alice" are different grants with different evidence and revocation requirements.

The August GA run changed the footnotes

When I first drafted this, the caveat was that the identity foundation was GA and the governance stack around it was mostly Preview. That caveat is now spent. Per the IAM release notes:

  • August 14: custom Organization Policy constraints for Agent Identity resources went GA, as did the VPC Service Controls integration. You can put the Agent Identity APIs inside a service perimeter.
  • August 22: the auth manager and the Agent Identity APIs (agentidentity.googleapis.com and agentidentitycredentials.googleapis.com) went GA. The auth manager is described as a centralized credentials vault and authentication broker, and the release note says these APIs replace the legacy IAM Connectors API (iamconnectors.googleapis.com).

That last item belongs on a migration board, not a reading list. A credentials vault going GA and superseding a prior API is a dependency change.

MCP is converging on the same model

On the same day, the MCP roadmap named agent identity and enterprise-ready security as a priority, noting that MCP authorization today "is built around a person approving access in a browser" while "more and more of the callers are agents running as cloud workloads." The stated work: finalize DPoP and define an opinionated path for agent identity and delegation through Workload Identity Federation. Explicitly away from pasted API keys and long-lived tokens.

Google's Agent Identity docs already name X.509-bound tokens and DPoP. A cloud vendor and an open protocol landing independently on proof-of-possession plus federated workload identity is the strongest signal in this cycle: the shared-static-credential era for agents has a visible direction of travel, even if the migration takes years.

Identity is still not judgment

None of the GA milestones touch the actual limitation, which is conceptual. Identity answers who made the call under whose authority? It does not answer was this call wise?

A correctly authenticated purchasing agent can order the wrong quantity. A support agent with legitimate access can disclose data to the wrong customer because it misread the conversation. An agent authorized to update production can faithfully execute a malicious instruction retrieved from an untrusted document. None of those actions is anonymous or unauthorized in the IAM sense. Better attribution makes the incident easier to investigate. It does not prevent the decision.

That is why Google pairs Agent Identity with Agent Gateway, which understands MCP and A2A and creates a place to apply authorization, DLP, and prompt-injection defenses to agent traffic. Identity supplies the subject. The gateway supplies request context.

But a gateway governs only the traffic that traverses it. A direct network path, an unregistered tool, or credentials handed to the agent becomes a bypass. "We deployed an agent gateway" is not a control statement until consequential egress is forced through it and alternate paths are denied. Automatic Agent Registry enrollment helps here: you cannot enforce policy against a tool you do not know exists.

The durable pattern is layered:

  1. Give each consequential agent its own lifecycle-bound identity.
  2. Record whether it acts on its own authority or on delegated user authority.
  3. Grant the smallest resource and operation set the task needs.
  4. Route tool and external traffic through an enforcement point that sees agent, user, destination, operation, and data context.
  5. Require human approval or a separate deterministic control for irreversible, expensive, or high-impact actions.

Google has made the principal precise and, as of September, available in Preview on a runtime plenty of people already use. The harder problem is turning "this agent may call this tool" into "this action, in this context, should happen."

Identity is the necessary first half of that answer. It is not the verdict.

See also

Sources

  1. Google Cloud: Cloud Run release notes (2026-09-01 entry)
  2. Google Cloud: IAM release notes (2026-08-14 and 2026-08-22 entries)
  3. Google Cloud: Agent Identity overview
  4. Model Context Protocol: The New MCP Roadmap (2026-08-22)
  5. Google Cloud: What's new in IAM, security, governance, and runtime defense (2026-05-06)