Google just solved agent identity. For Google Cloud

Google Cloud Next showed exactly where agent governance is headed — and exactly where it stops. Here's what the keynote got right, and the question nobody answered.

Authors

Published: April 24, 2026


The keynote showed exactly where agent governance is headed, and exactly where it stops.

Richard Seroter, Google Cloud's Chief Evangelist, had just kicked off the marathon simulation when an alarm klaxon fired and the demo stopped cold. The culprit, as Developer Advocate Megan O'Keefe later diagnosed on stage, was the Simulator Agent hitting Gemini's one-million context token limit. The agent's own tool calls had bloated its context faster than its built-in compression could trim it. A 400 error. A real failure in front of a live audience.

Developer Relations Engineer Emma Twersky's response was immediate: "It's not your fault. This is what happens with LLMs."

That unscripted moment was more useful than anything rehearsed could have been. Agents fail in ways their builders don't anticipate — including the builders at Google. They said it on stage, in front of thousands of people, and moved forward. Credit where it's due.

The rest of the keynote was built around that premise: autonomous systems need governance baked in. Bolting it on after the fact isn't enough.

What Google Gets Right#

Developer Advocate Ankur Kotwal's segment was the engineering highlight of the keynote. It deserves a fair read before we get to the questions it raised.

Google's Agent Identity gives every deployed agent a unique, immutable credential, automatically generated at deployment. Kotwal's analogy was apt: service accounts are a master hotel key shared between the whole event crew. Agent identities are a biometric scanner at every door, with a full audit trail behind each one.

Agent Gateway acts as a proxy between agents, enforcing IAM policies on all outbound traffic — what each agent can call, what tools it can access, what it can write versus only read. The demo was a live policy creation: block the Planner Agent from calling write-enabled tools on the Finance MCP server. A few clicks. Propagated in minutes.

Seeing RBAC enforced for non-human principals at the platform layer was encouraging. The industry needs exactly this, and it's a big part of why we brought the Permify team under the FusionAuth banner.

Where the Fence Ends#

Everything Google showed runs on Google IAM.

A2A — their agent-to-agent protocol — is a genuine cross-vendor tool, donated to the Linux Foundation. Agents advertise capabilities via Agent Cards. Other agents discover and call them via an open protocol. The latest version of the Enterprise Service Bus — everything old is new again.

But the trust layer enforcing those connections isn't open.

When an agent credentialed in AWS Agentcore or Azure Copilot Studio knocks on the door of your Google-hosted agent via A2A, it carries credentials Google's gateway has no native way to validate. The same unanswered questions keep surfacing:

  • Who is this agent?
  • What is it allowed to do?
  • Who delegated that authority?

Wiz, which Google acquired for $32 billion in March, explicitly supports AWS, Azure, and Oracle Cloud. The security scanning is multicloud. The identity governance underneath it stops at the fence. And the clock is ticking on how long that multicloud neutrality survives the full merger.

Same Song, Same Dance#

The web fragmented user identity. Mobile did it again. Every platform era starts with each major vendor building their own credential system, their own session model, their own access controls. Fragmentation follows. Standards eventually catch up.

The teams that go all-in on a single vendor avoid these early growing pains — but at a cost. Speed of change in this space is weekly, not quarterly. Vendors get acquired, shut down, or pivot. Architectures that can't adapt get left behind. The teams making pragmatic, best-of-breed choices across their stack absorb the fragmentation pain early — but they're also the ones who aren't trapped when the landscape shifts.

Most teams doing serious work fall into that category.

We’re moving faster than ever. The pace of change has accelerated from quarterly to weekly (at most). The model that led benchmarks in January got leapfrogged by March. The orchestration framework that everyone swore by six months ago is now old news. Betting your architecture on a single vendor’s primitives means that you’re working by their roadmap instead of your own. When they pivot, you’re also forced to pivot. When they shut their doors, you find out how much load that connection was bearing. The teams taking the fragmentation hit up front are building systems that can absorb a swap without a refactor. In a space that’s moving as fast as this one is, it’s the only architecture that actually ages well.

If your agents run entirely within Google Cloud, the governance story from the keynote covers you well. Stay there.

When your agent runs in Azure, connects to a compute workload in Google Cloud, and pulls data from your Snowflake instance in AWS. Every one of those platforms has its own identity layer, and none of them federate with each other. The agents are already hopping across those boundaries, but their credentials aren't.

Walled gardens are making a comeback like it's 2006.

Our Strongly-Held Opinion#

The right governance layer for machine identity looks a lot like what we learned to build for human identity: vendor-neutral, portable credentials, policy enforcement that doesn't depend on the runtime, and an audit trail that survives a migration.

The clouds are solving orchestration. Identity federation across clouds and runtimes is still the wild west. That's exactly the problem FusionAuth addresses. Machine-to-machine OAuth via client credentials means any agent, on any runtime, in any cloud, authenticates through a single identity layer using an open standard — no proprietary gateway required. And FusionAuth's Fine-Grained Authorization handles exactly what Google demonstrated with their read-only finance policy: scoping what an agent can do, which resources it can touch, and under what conditions. The difference is that FGA isn't tied to a specific cloud's IAM. It travels with your stack.

Ready to talk through your architecture? Grab some time with our Solutions Engineers.

More on ai agents

Subscribe to The FusionAuth Newsletter

Get updates on techniques, technical guides, and the latest product innovations coming from FusionAuth.

Just dev stuff. No junk.