You ask, we answer · 01 October 2026
Should Copilot Studio agents get their own mailbox and Teams identity?
IAM already tracks Entra Agent IDs for Studio agents. Now the roadmap talks about persistent identity — agents with their own accounts, mailbox, and Teams presence. Is that the same thing as Agent ID, and should we let makers create AI teammates with mailboxes before we have a licence and sponsor model?
Grounded with: Microsoft Learn — Agent 365 identity (agent’s user account, Agentic-User); Microsoft 365 Roadmap 570430 Persistent identity for Copilot Studio Agents
DIGITAL SKILL WORKS LTD / 12 PANES
You’re right to separate “the agent has an identity” from “the agent has a desk, a mailbox, and a presence blob in Teams.” Those are different risk surfaces — and marketing often collapses them into one slide.
Here’s what’s going on. Entra Agent ID (already in Studio for new agents) is the agent’s service principal — useful for connector scopes, Conditional Access visibility, and registry. Persistent identity for Copilot Studio agents (Microsoft 365 Roadmap 570430, status In development; preview timing September CY2026 and GA November CY2026 on the roadmap — verify for your cloud) is about giving an agent its own Microsoft 365 account: mailbox, Teams presence, Office access — a first-class collaborative actor admins can govern with policies like any other identity. In Agent 365 identity docs, that optional second object is the agent’s user account, used in Agentic-User execution mode when the agent must act as that account (own mailbox, Teams, Word/Outlook interactions). Learn is clear: add a user account only when the agent requires one; agents that only call tools and emit telemetry usually don’t. Critically, agents with their own user account are called out as available to tenants in the Frontier preview programme — treat that as a programme and licensing gate, not a free toggle on every environment. Sponsors still matter: blueprints and agent identities need accountable humans; a mailbox without a sponsor is just an orphaned colleague with APIs.
Steady Identity (Pane 04) before “AI teammate” theatre. Schofield’s First Law (historically attributed): don’t put organisational mail and Teams into an agent account unless you can see exactly how to reclaim, disable, and export when the project ends.
Options that actually work:
- Default to Agent ID + OBO/end-user credentials; reserve agent user accounts for named Wave 0 scenarios (shared inbox triage, coordinated onboarding) with sponsor, licence, CA, and reclaim date on the register. Best Steady path.
- Pilot persistent identity only inside Frontier / approved preview rings, with a short Entra group and no production mail routing until GA status is confirmed for your tenant.
- Let every maker spawn a mailbox “so the agent feels real.” Licence spray, directory noise, and Third Law exposure (easy for the agent to access mail → easy for whoever steers the agent).
- Assume Agent ID already gave you a mailbox. It didn’t — service principal ≠ user account.
12 Panes action / comms: Tell IAM: Two objects — Agent ID always; user account only with a business case. Tell makers: No mailbox until Security signs the AI-teammate pattern. Finance: Budget licences and reclaim; AI teammates aren’t free seats forever.
Benefits / risks: True collaborative agents become governable entities; Frontier/preview and roadmap dates move; licences, Conditional Access, and Purview must cover a new class of “user”; ownerless agent mailboxes are worse than ownerless bots. Verify Learn, Frontier enrolment, and Message Centre before promising mailboxes in a programme plan.
I’d suggest this week: update the agent register with a column for “needs user account? Y/N,” block mailbox provisioning outside a named pilot group, and pick one collaborative process that actually requires Agentic-User — not ten that only need a connector. You’ll get Steady Identity without inventing a ghost workforce.
DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer