The directory entry was the announcement, not the email address

At a glance

Announced at Google's Gemini at Work event on 8 October 2026, initially to enterprise customers in private preview. Thomas Kurian described it as a single, universal agent for work; it can delegate to subagents and route tasks across Google's own models and Anthropic's Claude, with others reported as planned. Google's own announcement was not among the sources available for this piece, so the per-feature details below are as reported by several outlets covering the event.

Nothing here is a criticism of the design in isolation. A distinct, attested, non-human principal on a separate subdomain is the right shape, and it is markedly better than what most organisations run today. The argument of this piece is that a workplace account is a bundle designed for employees, and the parts of the bundle nobody asked for are the parts that change your threat model.

The anti-pattern it fixes is real, and worth naming first

The thing this replaces is the shared robot user: a "service" account that is really a human account, created by whoever needed it, shared with an automation and three colleagues, with a password in a vault and an audit log that says ops-bot did something. When that account does something unexpected, the question "who did this?" has no answer, and the remediation question "what else can it reach?" has a worse one.

An attested per-agent principal answers the first question cleanly and makes the second answerable at all. It also makes least privilege expressible: you cannot scope a shared account to one task without breaking the three other things using it, which is why shared accounts accumulate permissions monotonically forever. Separate principals are the precondition for everything in scoped credentials for agents, and the attestation is the useful half of agent identity and attestation — downstream systems that can verify the identity cryptographically can refuse everything that cannot present one.

Take the win. Then notice that the win is entirely about knowing and constraining who acted, and that none of it decides whether a particular action should happen.

Attribution and reach grow together, and only one of them is a control

Put the three shapes of agent identity side by side on two axes and the trade is visible. A shared service account logs almost nothing useful and has no inbound surface. A scoped delegated grant — an agent acting for a named human, with consent recorded — logs well and still has no inbound surface. A directory principal logs best of the three and is the first one with a mailbox.

That pairing is not a coincidence or an oversight; it is the product. The reason to make the agent a directory principal is so that it can participate in the systems people participate in, which is exactly what expands what it can be asked to do and by whom. So the number of actions the agent can take rises alongside the fidelity of the record of those actions, and teams reliably read the second as mitigating the first. A perfect log of an unauthorised write is still an unauthorised write — the distinction we keep returning to in reference monitor: an identity is a subject, and the decision about an action has to be made in the request path, against arguments, every time.

There is a second, quieter wrinkle in the reported design. The identity is stable and the thing acting under it is not: work is routed across models from two vendors, with more planned. Your audit log will say the agent did something; it will not, without extra work, say which model's behaviour produced it. That is the version-pinning problem from pinning and verification arriving inside an identity decision, and it matters the first time a behavioural regression needs attributing to a model change.

The mailbox is an unauthenticated write channel into the agent's context

This is the structural change, and it is worth stating plainly because the announcement's framing — an AI colleague with its own email account — invites you to think about it as a convenience. Every agent identity design that preceded this one was outbound: the agent held a credential and reached out, and untrusted content entered its context only where the agent went looking. An addressable mailbox reverses that. Anyone who can guess or discover the address can place arbitrary text directly into the queue of things the agent processes, with no credential, no approval and no rate limit beyond your mail gateway's. And a directory-published address on a conventional subdomain is built to be discoverable.

The standard objection is email authentication, and it deserves an exact answer. SPF, DKIM and DMARC establish that a message's sending domain is what it claims to be. They say nothing whatsoever about the authority of the request inside the message. A perfectly authenticated email from a real supplier's real domain is still a stranger telling your agent what to do, and a compromised supplier mailbox is an authenticated one. That gap is the whole content of instruction hierarchy, and treating channel authentication as content authorisation is how the automated-reply failure in the automated reply was the authorisation happened.

So the lethal combination assembles itself with no attacker ingenuity required: untrusted input arrives in the mailbox, the agent's directory identity carries access to private data, and the mailbox is itself an egress channel. The structural answer is to stop those three co-occurring in one run — a classifier in front of the mailbox that turns external mail into a typed, provenance-labelled record the agent reads, rather than a turn it answers, with the send path unreachable from message content. The domain-specific version is email and calendar agents, and the label that has to survive the whole run is context taint tracking.

The calendar is worse and gets less attention, because an invitation does not feel like a message. It carries a title, a description, attachments and links written by someone outside your organisation, and in most default configurations it populates itself with no one approving anything. It also leaks the agent's availability to whoever sent it.

Group membership is where the first incident will come from

Here is the failure that needs no attacker at all. Somebody adds the agent to engineering@ so it can follow the team's threads. Six months of accumulated sharing in that suite was aimed at engineering@ — folders, documents, dashboards, calendars, a vault shared "with the team". The agent now holds all of it, transitively, and nobody made a decision about any single item. Nothing was mis-configured. The directory did what a directory does.

A directory principal is the most ambient-authority-shaped object in an enterprise, and the mitigation is boring and effective: keep agents out of groups whose membership is maintained for humans, even when it means duplicating a group, and audit transitively rather than declaratively. The question is never "what did we grant the agent" but "what can this principal reach right now, through every group it belongs to" — a report your identity platform can produce and almost nobody asks it for. The cadence for that is access reviews for agent credentials; the reason to care is blast radius.

The retrieval consequence is the one that turns a permissions problem into a disclosure. An agent that summarises or indexes what it can see inherits the union of every group it is in, so a single answer can combine material the asking human was never entitled to. If the agent reads with its own identity rather than the requester's, you have built a confused deputy with a directory entry — the failure permission-aware retrieval exists to prevent.

And then there is the lifecycle, which has no trigger. Enterprise identity lifecycle runs on HR events: hired, moved, left. An agent is created by a platform team in an afternoon, re-pointed at a new model in a release, and abandoned when its project is cancelled. Nothing fires, so the orphaned agent account — live principal, still in groups, still receiving mail, owner now in a different department — is the default end state rather than an edge case. The fix is a named human owner with a quarterly re-attestation and an expiry date, which is the discipline in agent inventory and registry and decommissioning an agent.

What to ask before you enable it

Five questions, in the order they will bite. None of them is an argument against the feature; all of them have a configuration answer and none of them has a default answer you will like.

• Can we have the attested identity without the mailbox? Nothing about an audit improvement requires an inbound address. Treat the bundle as six separate grants and approve them one at a time.
• Is the address discoverable, and does it follow a guessable convention? Obscurity is not a control, but base rates are real: an undiscoverable address receives the mail you route to it, and a discoverable one receives whatever every scanner sends to every address at your domain.
• Which groups is the agent in, and what do those groups transitively grant? Run the report before go-live. Expect to remove it from two groups that afternoon.
• Who owns this principal, and what happens when they leave? If the answer is a team alias, there is no owner.
• Is the agent's mailbox in scope for retention, legal hold and erasure requests? It is a business record containing whatever strangers sent it. A schedule written for employee mailboxes does not cover it — retention and legal hold.

The operational version of all five, with the control ranking and the drills, is agents with directory accounts.

Further reading

On this wiki:

• Agents with Directory Accounts — the operational version of this argument, with the drills.
• Agent Identity — the three patterns, and why the shared robot user fails.
• Ambient Authority — why a directory principal accumulates reach nobody granted.
• Email & Calendar Agents — building on a channel strangers can write to.
• Permission-Aware Retrieval — reading with the requester's entitlements, not the agent's.

Sources:

• TechCrunch — Google brings agentic AI to Gemini, starting with businesses
• The Next Web — Google launches workplace AI agent that gets its own email address
• MarkTechPost — Google Cloud launches Gemini Agent, one universal agent for enterprise work