On October 8, at its Gemini at Work 2026 event, Google gave its enterprise AI agent something no previous agent on this site has had: its own Workspace account, its own email address, its own calendar, and a presence in the company directory. Google Cloud CEO Thomas Kurian framed the shift as giving the agent “objectives, not just instructions.” Sundar Pichai put numbers behind the reach, citing 1 billion monthly active Gemini users and roughly 90% of the Fortune 100 already on Gemini Enterprise.
The coverage read it as a capability story: AI can now do your work, not just answer your questions. That is the least important thing that happened. The agent getting an inbox is the whole event, and not because it is impressive. It is because a thing that used to be software you invoke just became an identity you have to govern. Machine identities already outnumber human ones 109 to 1 in the average enterprise, they are the primary way enterprises get breached, and almost nobody has a lifecycle for them. Google just productized the creation of thousands more, each with a mailbox and initiative.
So the decision in front of you is not whether Gemini agents are good. They probably are. The decision is whether you are ready to run a non-human identity with its own email address as a first-class governance object: provision it, scope it, audit it, and, the part nobody demos, offboard it.
What Google actually shipped at Gemini at Work
The product is a single Gemini agent for enterprises that plans multi-step work, delegates to subagents, and picks the model for each step (you can override to a third-party model, with Anthropic’s Claude available first). It connects across Gmail, Drive, and Docs, plus Microsoft 365, Slack, Jira, Confluence, Git, BigQuery, Snowflake, and Model Context Protocol servers, and it reaches you through iOS, Android, Windows, Mac, a CLI, ServiceNow, and Slack.
The new piece is the “coworker” mode. In that role the agent receives its own Workspace account, email address, calendar, and company directory presence. Its access is “limited to the information that team members choose to make available, rather than inheriting broader organizational access.” Administrators can configure spending thresholds at the project level, and the agent suspends itself once a limit is hit. The audit trail attributes actions to the agent rather than to the person who triggered it. It is in private preview now, with broad availability planned for select Business and Enterprise Workspace plans. Early testers include On, Shopify, and PayPal; named Gemini Enterprise customers already running at scale include BNP Paribas (65,000-plus staff) and SOMPO (10,000-plus custom agents).
Read that feature list again as an IT operations person would. It is not a description of a chatbot. It is the spec sheet for provisioning a new employee.
The email address is the story, not the autonomy
Underneath the coworker agent sits the Gemini Enterprise Agent Platform, and its governance layer is the tell. Every agent gets an Agent Identity: a unique cryptographic ID with authorization policies. There is an Agent Registry of approved tools, an Agent Gateway with Model Armor protections, Agent Anomaly Detection and Agent Threat Detection for suspicious behavior, and an Agent Security dashboard powered by Security Command Center.
Google did not build an identity and access management stack for agents as a bonus. It built one because an agent with an inbox is, definitionally, a non-human identity, the same category as a service account, an API key, or a machine certificate. And that category is already the part of enterprise security that is most out of control. Palo Alto Networks’ 2026 landscape puts the machine-to-human ratio at 109 to 1 and reports that 9 out of 10 organizations suffered a successful identity-related breach in the past 12 months. KPMG’s 2026 figure is lower but points the same way, at roughly 80 to 1. GitGuardian’s 2026 work names non-human identity sprawl as the primary security risk for enterprise infrastructure. These identities carry elevated privileges and run without the oversight we apply to human staff, which is exactly why attackers hunt them.
A coworker agent with a Workspace account is one more of those identities. The difference is that Google is handing you a one-click way to mint them at employee scale, and the agent does not just hold credentials. It acts on them, all day, without being asked twice.
“Limited to what the team shares” is the right design and a line to verify
The scoping claim is correct. An agent constrained to what a team deliberately shares, rather than one that inherits the whole organization’s access, is least privilege applied properly, and it is the right default. Credit where it is due.
Two cautions keep it from being a settled matter. First, least privilege is a configuration you verify, not a property you assume; the same report that flags the breach rate also found 96% of human identities already operate with access far beyond their role, and those are the accounts we supposedly manage. An agent is not going to drift tighter than its human colleagues on its own. Second, the dangerous moment with any non-human identity is rarely the grant you make on day one. It is the scope that creeps outward over months as someone adds “just one more” connector to unblock a task, and the grant that nobody ever walks back.
The audit trail attributed to the agent is a genuine win, and worth saying so plainly. If you can reconstruct exactly what the agent did under its own name, you can answer the question the new agent-operator liability framework now assumes you can answer, and it pairs directly with the observability and attestation work covered here recently. Just make sure that trail lives somewhere the agent cannot edit, the same rule that applies to every other agent log.
Nobody demos the day the agent leaves
Here is the part the keynote skips, and it is the part I spent years on from the operations side of a large telecom.
Creating identities was never the hard problem. Onboarding is a happy path; everyone has a script for it. The identity governance that actually mattered, and the part that was always underbuilt, was the joiner-mover-leaver process, specifically the leaver half. The orphaned service account that outlived the project that created it, still holding standing credentials, still in the directory, owned by nobody after the person who set it up moved teams: that is the quiet foothold that shows up in breach write-ups over and over. Not a clever exploit. A deprovisioning step that never ran.
A coworker agent inherits every one of those failure modes and adds one of its own, which is that it keeps working on its objectives while you are not watching. When the project ends, when the team reorganizes, when the pilot quietly stops being used, who disables the agent’s Workspace account? Who reviews what it can still reach? Who archives its mailbox and removes it from the directory? If the honest answer is that there is no owner and no process, you have not deployed a productivity tool. You have minted a privileged, persistent identity with no leaver plan.
And note what the spend cap does and does not do. Suspending the agent when it hits a budget threshold is a cost control, and a good one. It is not a security control. A suspended-on-budget agent still holds every grant it had the moment before; the credentials do not evaporate because the invoice did.
Treat it as onboarding a non-human employee
The reframe that makes this buyable is to stop evaluating a model and start running an onboarding. You are adding a non-human employee to your identity system, so use the process you already have for that, or build it before the agent arrives, not after.
You are ready if you already run non-human identity governance (an inventory, a named human owner per identity, least privilege, credential rotation, and a working offboarding step) and can extend it to agent identities. You are ready if you will put each coworker agent on the same joiner-mover-leaver process as a contractor, verify the “limited to what the team shares” scoping in the actual configuration, and re-review that scope on a schedule rather than at setup only.
You are not ready if you cannot name, today, who owns and who offboards a given agent. You are not ready if your instinct when it fails a task is to widen its Workspace or Microsoft 365 access until it works. And you are not ready if you are treating the spend cap as the thing that keeps you safe.
Three questions for the Google representative are worth more than any demo. Which of your own identity-governance primitives (lifecycle, periodic access review, deprovisioning) does the coworker agent actually plug into, versus which I still have to run by hand? When you say the agent has both a cryptographic Agent ID and a real Workspace account, which one is the system of record for what it can access, and can they ever disagree? And can I produce an offboarding report that proves a specific agent’s access was fully revoked, on the day I need it for an audit?
This is the same shift the headless-enterprise pivot and always-on consumer agents have been pushing all year, now with a mailbox attached, and it is the internal mirror of the access-control fight playing out at the storefront in agentic commerce. The agent that gets its own email address is the easy thing to switch on and the hard thing to switch off. Budget for the day it leaves before you celebrate the day it starts. Build for the identity you will one day have to revoke.