This is a submission for the Google Cloud NEXT Writing Challenge
I'll be honest — I went into Google Cloud NEXT '26 a little skeptical.
The "agentic era" pitch had started feeling like a vibe rather than a thing. Every vendor was throwing the word "agent" on products that were, at best, a prompt chain with a for-loop. So when Google rolled out 260 announcements across three keynotes, I was mostly skimming, coffee in hand, waiting to feel something real.
Then I hit this, buried in a bullet point list:
"Assigns every agent a verifiable identity in the form of a unique cryptographic ID. This creates a clear, auditable trail for every action an agent takes, mapped back to defined authorization policies."
I read it twice. Then I closed the tab and went for a walk, because that's what I do when something clicks.
This is Agent Identity — a feature inside the new Gemini Enterprise Agent Platform — and it's the most underrated announcement of the whole conference.
Let me tell you about a bad night I had
About eight months ago, I was on-call when a production agent we'd built started doing something weird. It was supposed to summarize customer support tickets and route them to the right team. What it actually did, starting at around 11pm on a Tuesday, was re-open 200 closed tickets and send routing notifications for all of them.
Support leads woke up to full inboxes. It was a mess.
You know what our audit logs said? That sa-support-agent@ourproject.iam.gserviceaccount.com had performed a series of write operations on the ticketing system. Thanks. Super helpful.
We had no idea which invocation caused it. No idea what reasoning chain led there. No idea if it was a fluke in a single run or something that would happen again. We spent three hours reconstructing what happened from API call timestamps and hoping the pattern made sense.
That is the current state of AI agent observability for most teams. A service account and a prayer.
What Agent Identity actually does
The concept is straightforward but the implications run deep.
Every agent deployed through the Gemini Enterprise Agent Platform gets a cryptographic ID — a unique, verifiable identity that travels with it. Every action that agent takes is signed with that ID and logged against it. And that log is mapped back to the authorization policies that defined what the agent was supposed to be allowed to do.
So instead of "service account did a thing," you get: "Agent X, version 2.1, operating under goal context Y, invoked tool Z at 11:23pm, and that invocation was either within or outside its defined policy scope."
That's a completely different conversation. Something you can debug. Something you can show to a security team. Something you can explain to your CTO at 2am when things go sideways.
Why this matters more than the TPUs
The 8th-gen TPU announcement is genuinely cool. The dual-chip approach — TPU 8t for training, TPU 8i for inference at 80% better performance per dollar — is impressive infrastructure work. The Cross-Cloud Lakehouse on Apache Iceberg is smart. The Agent Inbox will make product managers very happy in demos.
But all of those things make agents faster or easier to build.
Agent Identity makes agents possible to trust.
And right now, trust is the bottleneck. Not capability.
The number one reason AI agents don't make it to production — or get quietly rolled back after launch — isn't that the AI isn't smart enough. It's that nobody can explain what the AI is doing. Not in a way that holds up to a security review, a compliance audit, or even just a post-mortem when something breaks.
We've been shipping autonomous systems with the accountability infrastructure of a shared Dropbox folder. Agent Identity is the first thing I've seen that treats this as a platform responsibility rather than something each team should hack together on their own.
The thing that really gets me
What I find genuinely interesting — and a little overdue — is that this mirrors a shift that already happened in backend infrastructure.
Around 2012–2016, distributed tracing went from "thing Netflix and Google do" to "table stakes." If your infrastructure platform didn't give you request traces that spanned microservices, it was second-class. Datadog, Jaeger, Zipkin — the whole observability wave — happened because we collectively decided that "the server did a thing" wasn't good enough when the system was distributed and complex.
AI agents are more complex and more autonomous than microservices. They make decisions. They take actions with real-world consequences. The idea that we'd hold them to a lower observability standard than a REST API is kind of absurd when you say it out loud.
Agent Identity, paired with Agent Anomaly Detection (which flags unusual reasoning in real time using an LLM-as-a-judge framework) and the Agent Security Dashboard, feels like Google finally saying: observability is infrastructure, not application code. We'll give you the rails. You write the policies.
I'm not going to pretend it's perfect
A few real limitations I keep coming back to:
It's GCP-scoped for now. The moment your agent steps outside Google Cloud — calls a third-party API, hits an on-prem system, invokes a Lambda — the identity chain breaks. For real enterprise workloads, this is significant. Most production agents are hybrid by necessity.
The policy problem is harder than the identity problem. Having a cryptographic ID attached to every action is great. But detecting whether an action is "within policy" requires that you've actually defined the policy clearly. Most teams haven't. They have a system prompt and vibes. The infrastructure is only as useful as the formal definitions underneath it — and Google hasn't told us how to write those yet.
An ID doesn't fix nondeterminism. Same agent, same input, different behavior run to run — that's just how LLMs work. Agent Identity tells you who acted. It doesn't guarantee consistency. You still need evals, behavioral baselines, and a real answer to what "normal" even means for a probabilistic system.
What I'd actually do with this
If you're building agents — anywhere, not just on GCP — I'd encourage you to internalize the model even if you can't use the specific tooling yet.
Every agent should have a defined identity. Every invocation should be traceable. Every action should be loggable against the intent that spawned it. Whether you implement this with the Gemini Enterprise Agent Platform or wrap your own service accounts, the discipline is what matters.
If you are on GCP, the Agent Development Kit (ADK) is worth a real look. Its graph-based framework for wiring sub-agents together is a more rigorous mental model than the prompt-chaining approach most teams are using. The Agent Registry — a central library of approved tools and skills — is the kind of artifact that makes governance conversations with security teams go from painful to productive.
And if you're in "reading the docs" phase: start with the Agent Identity docs and the Agent Anomaly Detection overview. Even if you don't deploy tomorrow, working through what policies you'd write is a useful exercise. It surfaces gaps in how you've defined what your agents are actually supposed to do.
The bottom line
Two hundred and sixty announcements. TPUs, Lakehouses, Agent Inboxes, Workspace avatars, BigQuery cost savings, a $750 million partner fund. It was a lot.
But when I think about what actually changes the trajectory of AI agents in production — not in demos, in production — it's this: the moment platforms start treating accountability as their job, not the developer's problem.
Agent Identity is an early, imperfect version of that moment. And I think in three years we'll look back at it the way we look back at distributed tracing — as the thing that made a whole category of technology finally viable for people who couldn't afford to get it wrong.
The agentic era is here. Now we need to make it trustworthy.
If you've shipped agents to production and dealt with the debugging nightmare I described — I'd genuinely love to hear how you handled it. Drop it in the comments.
Top comments (0)