What Google's Agent Identity Deadline Means for Platform Teams

Google has not set a date when service accounts stop working for AI agents. A lot of the commentary implies otherwise, so it is worth saying up front. The pressure is still real. Agent Identity went GA in April 2026, its auth manager went GA in August, the legacy IAM Connectors API is being replaced, and Google has positioned Gemini Enterprise Agent Platform as the evolution of Vertex AI.

For platform teams, the practical deadline is simpler. Every agent you deploy on a shared service account today is one you will migrate later, by hand, after more systems depend on it.

What Google Actually Shipped

Agent Identity is a new IAM principal type built for agents, separate from human users and from service accounts. It was announced at Google Cloud Next in April 2026 and has filled in steadily since.

The mechanics matter more than the branding. When you deploy an agent on a supported Google Cloud service, Google assigns it a SPIFFE ID and an X.509 certificate that lasts 24 hours and renews on its own. The IAM principal looks like principal://agents.global.org-ORG_ID.system.id.goog/resources/..., derived from the resource that hosts the agent. Calls to Google APIs use tokens bound to that certificate over mTLS, and traffic through Agent Gateway adds DPoP protection.

A few properties set it apart from a service account. The identity is not shared across workloads by default. It cannot be impersonated. You cannot mint a long-lived key for it. When an agent acts for a user, audit logs record both the agent and the user.

Why Service Accounts Were Never a Good Fit

Most teams started their agents the way they start any workload: one service account per project or per environment, granted whatever the first demo needed. That works until something goes wrong. Then the audit log names a service account that four agents, a batch job and a notebook all share, and someone spends an afternoon reconstructing which one did it. One engineer described a similar incident after Next.

Agents make the old pattern worse in three ways:

They are not deterministic. The same agent can call different tools on different days, so permissions sized to “what it does” drift fast.

They act for people. A shared service-account identity does not, by itself, identify the user on whose behalf an action occurred. Agent Identity can record both.

They hold credentials for other systems. API keys and OAuth tokens for third-party tools tend to end up in environment variables or secret stores scoped far wider than one agent.

Per-agent identity fixes the attribution problem and gives you a principal small enough to scope properly. It does not decide what each agent should be allowed to do. That part is still your job.

Where the Deadline Actually Is

Nothing forces the switch today. The Agent Runtime docs say that if you don’t set the identity flag, the instance keeps using service accounts, and that this exists for backward compatibility with Infrastructure as Code deployments. That is a kindness to existing pipelines. It is also the trap, because the default path keeps adding agents to the old model.

The pressure comes from three directions:

The legacy IAM Connectors API is being replaced. Google says the new Agent Identity API supersedes it, with both APIs operating side by side during the migration period. No sunset date has been published.

The roadmap has moved. As Pythian put it, this “is not a migration deadline, but it is a direction.” Google has positioned Gemini Enterprise Agent Platform as the evolution of Vertex AI, and newer controls such as Principal Access Boundary for agents, Agent Gateway policies and auth manager are built around agent principals.

Your own count. Ten agents on shared service accounts is a week of cleanup. A hundred, owned by teams that have since reorganized, is a project.

What Changes When You Switch

A few behaviors catch teams off guard, and the first four are in Google’s own docs:

Deleting and recreating an agent creates a new principal. The identity is derived from the hosting resource ID, so replacing that resource creates a new identity, even if the configuration stays the same. Bindings on the old principal do not carry over. Pipelines that replace agent resources need to reapply roles after deployment, or use project-level principalSet bindings for baseline access.

Deleting an agent leaves its bindings behind. You need a cleanup step for stale IAM entries.

Legacy Cloud Storage roles are off the table. Roles such as storage.legacyBucketReader cannot be granted to an agent identity.

mTLS is enabled by default for direct access to Google Cloud APIs. Agent Gateway adds DPoP protection for traffic routed through the gateway. A Google-managed Context-Aware Access policy helps enforce credential binding. Anything in your egress path that terminates or inspects TLS is worth testing early.

Multi-cloud identity remains complicated. As FusionAuth points out, with an obvious commercial interest, Google’s native identity provisioning is centered on its own infrastructure. Google supports authentication to external services through OIDC, but establishing trust between agents hosted by different cloud providers still requires additional integration.

A Migration Playbook for Platform Teams

None of this needs a big-bang cutover. The order below keeps the blast radius small at each step.

Inventory first. List every agent, where it runs (Agent Runtime, Gemini Enterprise, GKE, elsewhere), the identity it uses today, and who owns it. Count how many agents share each service account. That number is your real risk.

Make Agent Identity the default for new agents on supported Google Cloud runtimes. Set the appropriate identity flag in your shared Terraform modules and deployment templates. Agent Identity support and configuration vary by environment, with GKE support still in preview. This change stops the backlog from growing wherever the feature is supported.

Fix the pipeline for principal churn. When deployments delete and recreate agent resources, reapply IAM bindings to the new principal, or grant baseline roles to a principalSet and keep per-agent grants narrow. Add a job that finds and removes bindings for agents that no longer exist.

Move outbound credentials into the auth manager. Third-party API keys and OAuth tokens belong in a vault with access scoped to the agents that need them, not in environment variables. If you used the IAM Connectors API, move to agentidentity.googleapis.com as part of the transition.

Put hard limits around agents. Use Principal Access Boundary to define what an agent can never reach, deny policies for the obvious no-go zones, and a VPC Service Controls perimeter around the Agent Identity APIs. Organization Policy custom constraints can enforce supported configuration rules across projects.

Update detection and audit. Alerts and dashboards keyed on a shared service account need to key on agent principals instead. Check that on-behalf-of user attribution shows up where your security team looks.

Migrate existing agents by risk. Start with agents that touch customer data or production systems, then the rest. Retire old service accounts and any keys once traffic is clean and no other workloads depend on them.

The Part Google Can’t Do for You

The identity, registry and gateway are plumbing. They make it possible to answer “which agent did this, for whom, and was it allowed.” They do not tell you who owns an agent after the person who built it moves teams, or what an agent should never touch. Those are governance decisions, and they belong with the platform team because nobody else sees every agent.

My own team’s path into this was ordinary. Our first Gemini integration for video analysis ran on an API key during prototyping. When it came time for production, we looked at Google’s authentication decision tree and picked Workload Identity Federation, mainly because most of our infrastructure runs on another cloud and nobody wanted to own a JSON key file. Agent Identity is the next step on that same road: fewer secrets, narrower principals, and logs that name the actual actor.

If you take one thing from this, make it step 2 of the playbook. Change the default in your templates this quarter wherever Agent Identity is supported. The migration of existing agents can follow at whatever pace your risk allows, but the count stops climbing the day the default changes.