Two things happened at Google last week that most C-suite readers noticed one of and ignored the other. The consumer Gemini Spark agent now operates the desktop version of Chrome using your logged-in accounts and saved passwords — booking property viewings, running flight searches, executing multi-step web tasks. That was the headline.

The second was quieter: Google announced general availability of the Gemini Enterprise Agent Platform, and buried in the documentation was a specific design decision. Every deployed agent gets its own identity, separate from any human's — its own credentials, its own permission scope, its own audit trail. When the agent acts on a user's behalf, the log records both.

Two launches. Two different opinions about how AI agents should authenticate. Every CIO is about to make an architectural decision between them — most without realizing it's a decision.

The identity model most enterprises are inheriting by default

The Gemini Spark browser agent authenticates as you. It uses your session, your cookies, your saved passwords. Every action it takes looks — to every downstream system — like you took it. That model works for consumer convenience. It's a disaster for enterprise governance.

When the agent authenticates as the human, several load-bearing pieces of your existing access controls stop functioning. The principle that people should have the minimum access needed for their job breaks — the agent inherits the full session the user has, not just what the agent needs. Separation of duties becomes theatrical: one credential is shared between the human and the software acting for them. Audit trails lose resolution because the log says the human did it, but the human's fingerprints aren't on the keyboard. Incident response can't distinguish "the user made a bad call" from "the agent acting on the user's behalf made a bad call." And liability allocation gets murky in a way your legal team hasn't priced in.

Most enterprises are drifting into this model right now, without a decision. The default in almost every consumer agent product is human-inherited authentication. When employees start using browser agents, desktop copilots, or productivity assistants, the enterprise inherits that posture. Nobody signs off. It just happens.

The pattern Google just published

Google's enterprise architecture is the opposite of the consumer one — worth studying not because it's the only right answer, but because it's the first commercially published pattern of what "right" looks like. Every agent gets its own cryptographic identity, pinned to the software actor rather than a person. Administrators grant permissions to that agent identity directly: this permission, to this agent only, on this specific resource. Credentials rotate automatically; tokens can't be reused elsewhere. And critically, when the agent acts on a user's behalf, the audit log records both — the human who requested the action and the agent that performed it.

That's the architecture your enterprise needs. It's also the architecture your enterprise almost certainly doesn't have.

Why this is a C-level decision, not an IAM team decision

Three reasons.

It's architectural, not policy. Once your organization commits to agents-authenticate-as-users, unwinding it is a multi-year migration. Every downstream system that logs, audits, or authorizes based on user identity has to be re-instrumented. Every security-monitoring rule rewritten. Every access certification process redesigned. This isn't a control you add later — it's a foundation the rest of your AI governance sits on.

The wrong default is happening silently. Nobody is running a memo to the CIO's office asking permission to let browser agents inherit user credentials. It's just happening in the browser, in the desktop app, in the productivity suite. By the time governance notices, the pattern is embedded in a thousand workflows.

Regulators are about to score you on this. The EU AI Act's full application on August 2 requires "traceability" and "human oversight" for high-risk AI systems. Traceability requires knowing which entity performed an action. If your log says the human did it and their fingerprints show they were asleep, you don't have traceability — you have plausible deniability, which is the opposite. UK regulators are asking similar questions. FS CIOs should expect explicit questions on this in their next supervisory dialogue.

The one question to bring into your next architecture review

Not "how do we let agents in?" — they're already in. The question is "do our agents authenticate as themselves, or as the humans they serve?" The answer determines whether you have an auditable, governable AI environment in three years, or a legal-and-security cleanup project the size of your last cloud migration.

Google made one architectural opinion visible. AWS, Microsoft, and Anthropic have parts of this pattern in flight. CIOs who make this decision deliberately over the next two quarters will be operating cleanly. The ones who inherit whichever default their vendors ship will spend the second half of the decade unwinding it.

Sources:

Google Cloud, "Agent Identity overview — Gemini Enterprise Agent Platform." https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-identity-overview

Google Cloud, "Use Agent Identity with Agent Runtime — Gemini Enterprise Agent Platform." https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity

AI Agent Store, "AI Agents News — Week of August 11, 2026" (Gemini Spark Chrome operation, Gemini Enterprise Agent Platform GA). https://aiagentstore.ai/ai-agent-news/this-week

Pebblous, "Google Agent Identity and AI Agent Access Control" (SPIFFE identity architecture analysis; retrieval-entitlement gap). https://blog.pebblous.ai/blog/gemini-enterprise-agent-identity/en/

EU AI Act, full application deadline for high-risk AI systems: August 2, 2026 (transparency, traceability, and human oversight requirements; penalties up to €35M or 7% of worldwide turnover).