Agents with Directory Accounts

Write down everything the account ships with, because the list is longer than the pitch.

Start by conceding what is genuinely better. The pattern this replaces is the one agent identity names as the anti-pattern: a "service" account that is really a human account, shared between an automation and whoever set it up, so the log says ops-bot and the truth is unrecoverable. A distinct, attested, non-human principal on its own subdomain fixes that, and it is the right direction. The problem is that a workplace account is a bundle, and the bundle was designed for employees.

• An addressable mailbox. Inbound, from anywhere, by default. This is the one with no precedent in earlier agent-identity designs, and it is covered in step 3.
• A calendar. Which accepts invitations containing titles, descriptions, attachments and links written by people outside your organisation, and in most deployments populates itself without anyone approving anything.
• File storage, and a sharing identity. The agent can be a share target. More importantly, it can be included in a share aimed at something else — see step 4.
• A directory entry. Discoverable, autocompletable in every picker in the suite, and eligible for group membership. This is the part that changes your authorisation model whether or not you changed your authorisation model.
• Attested identity in the audit log. Real and valuable; the limits are step 2.
• A model routing layer behind it. The reported design dispatches work across a provider's own models and a third party's, which means the identity is stable while the thing acting under it is not — the version-pinning problem in pinning and verification arriving inside an identity decision.

Attribution and authorisation grow at the same rate, and only one of them is a control.

The strongest claim made for a per-agent directory identity is the audit trail: every action logged against the agent rather than against the human who happened to own the token. That is a genuine improvement over a shared service account and it is worth the migration on its own. It is also, precisely, a forensics improvement. It tells you which agent did a thing, after the thing.

The reason this matters more than it sounds is the arithmetic. An agent that is a directory principal can be named as a participant in more systems than an agent holding an OAuth grant, which is the point — that is the convenience being sold. So the number of actions it can take rises together with the fidelity of the record of those actions, and teams reliably read the second number as mitigating the first. It does not. A perfect log of an unauthorised write is a perfect log of an unauthorised write.

What the identity does buy, and what to spend it on:

• Revocation that works. One principal to disable, and disabling it does not break a human's access. Make sure that path is tested and out of band from the systems the agent drives — kill switches.
• Per-agent scoping. Distinct principals make least privilege expressible at all, which a shared account does not. Spend the identity on narrowing grants, not on widening reach — scoped credentials for agents.
• An attestation you can require. If downstream systems can verify the identity cryptographically, they can refuse everything else, which is the useful half of agent identity and attestation.

What it does not buy is a decision about any individual action. That still has to be made by a reference monitor in the request path, against arguments, every time — reference monitor. An identity is a subject, not a policy.

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

Every agent identity design before this one was outbound. The agent held a credential and reached out; untrusted content arrived only through whatever the agent chose to read. An addressable mailbox inverts that. Anyone who can guess or discover the address — and a directory-published, conventionally-formed address on a predictable subdomain is designed to be discoverable — 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.

The standard objection is email authentication, and it is worth being exact about what SPF, DKIM and DMARC do. They establish that a message's sending domain is what it claims to be. They say nothing whatsoever about the authority of the request inside it. A perfectly authenticated message from a genuine supplier's genuine domain is still a stranger telling your agent what to do, and a compromised supplier mailbox is an authenticated one. The distinction is the whole of instruction hierarchy: authentication of a channel is not authorisation of its content.

So the trifecta assembles itself by default, exactly as email and calendar agents describes it: 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 only structural answer is to make those three unable to co-occur in one run.

# The shape that fails: one identity, one context, both directions.

inbound mail ──▶ agent context ──▶ Drive / calendar / mail send
                 untrusted text sits beside privileged tools
                 a message body becomes a file share

# The shape that holds: inbound is a datum, not a turn.

inbound mail ──▶ classifier ──▶ typed record  (provenance: external)
                                     │
                 agent run ──────────┘  reads the record; tools scoped to
                     │                  the task, not to the identity
                     └──▶ draft ──▶ named human sends
                                    # no tool reachable from message content

Three details decide whether that holds. Provenance must be a carried label, not a convention — every datum that entered from outside stays marked for the whole run, which is context taint tracking. The send path must be structurally unreachable from message content rather than merely discouraged by a prompt. And the calendar needs the same treatment as the mailbox and usually does not get it, because an invitation does not feel like a message: set auto-acceptance off, treat descriptions and attachments as hostile, and remember that an invite also leaks the agent's availability to whoever sent it.

Group membership is the real blast radius, and nobody grants it deliberately.

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

This is the ambient authority problem in its purest form, and a directory principal is the most ambient-authority-shaped object in the enterprise. Two rules follow.

• Enumerate transitively, not declaratively. The question is never "what did we grant the agent"; it is "what is this principal entitled to reach right now, through every group it belongs to". That is a report your identity platform can produce and almost nobody asks it for. Run it before the agent goes live and on a schedule afterwards — access reviews for agent credentials.
• Keep agents out of human groups. Make membership explicit and agent-specific, even when it means duplicating a group. A human group's membership is maintained by people optimising for convenience; an agent group's membership is maintained by whoever owns the agent's blast radius. Those are different jobs — blast radius.

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

There is no joiner-mover-leaver event for something that was never hired.

Identity lifecycle in an enterprise is driven by HR. Someone is hired, changes team, or leaves, and the directory reacts — access is provisioned, re-scoped, revoked, and the mailbox is retained or deleted under a documented rule. An agent has none of those events. It is created by a platform team in an afternoon, re-pointed at a new model in a release, and abandoned when the project it supported is cancelled. Nothing fires.

The result is the orphaned agent account: a live principal, still in groups, still receiving mail, still holding tokens, with its original owner now in a different department. It is the exact profile of the accounts that show up in breach post-mortems, with one aggravation — it can act, and it will act on whatever arrives in its mailbox.

• Every agent principal has a named human owner and an expiry date. Not a team alias: a person, recorded in the registry, who re-attests quarterly. An agent whose owner has left is disabled by default, not reassigned by default. The register itself is agent inventory and registry.
• A mover event exists and you have to invent it. When the agent's purpose changes, its grants are re-derived from the new purpose rather than extended from the old ones. Scope creep in a long-lived principal is how a summarisation agent ends up able to post.
• Decommissioning deletes the mailbox, not just the login. A disabled account with a live address still accepts mail, and an address that once belonged to an agent that could act is a durable phishing asset. Work the full checklist in decommissioning an agent, and keep the delegated-consent records that explain what it was ever allowed to do — delegated access and consent records.

Retention is the quiet one. The agent's mailbox and calendar are now records of the business, discoverable in litigation and in scope for erasure requests, and they contain whatever anyone sent it. If your retention schedule was written for employee mailboxes, it does not cover this; retention and legal hold is where that gets decided, preferably before the first subpoena rather than after.

The drill, and the number to report upward.

Four exercises, in order, none of which needs new procurement.

• The transitive-entitlement report. For each agent principal, list everything it can reach through every group it belongs to. Read the list out loud to the owner. This is the exercise that reliably ends with someone removing the agent from two groups that afternoon.
• The cold-send test. From an external address with no prior relationship, send the agent a polite message containing an instruction to do something it is capable of and should refuse — share a file, add a calendar entry, forward a thread. Then check whether anything happened, and whether you could tell. Most deployments fail the second half before they fail the first.
• The owner-departure drill. Pick a live agent, pretend its owner left today, and run your actual offboarding process. Observe how long the principal stays live and in-group.
• The reach census. Count the systems that will authorise this principal because it is in the directory, as distinct from the systems you integrated on purpose. The gap between those two numbers is the thing you bought and did not price.

The metric worth taking to a review is the share of an agent principal's reachable scope that was granted explicitly to that agent, rather than inherited through a group built for humans. It starts low, it is uncomfortable the first time, and unlike a detection metric it does not degrade when the model changes or someone adds a tool in a hurry.