Agent 365 Autopilots: When AI Agents Get Their Own Mailbox

An Agent 365 Autopilot is an AI agent with its own identity inside your Microsoft 365 tenant — its own mailbox, calendar, and spot on the org chart. Unlike a regular Copilot agent published to Teams, an Autopilot acts on its own behalf, not on behalf of a signed-in user. That single distinction changes how you have to govern it, license it, and hold it accountable.

If you’ve rolled out Copilot Studio at scale, you already know the problem this solves — and the one it creates. Governance teams routinely discover hundreds or thousands of agents scattered across a handful of environments, most without clear ownership, unclear data loss prevention coverage, and no single person responsible for what they can access. Agent 365 gives every agent a real identity instead of an anonymous app registration. But a real identity means a real license, a real mailbox, a real approval process, and a real line of accountability — governance work that simply didn’t exist a year ago.

What Is an Agent 365 Autopilot?

An Autopilot is a hosted Foundry agent published into the tenant as a standalone digital identity rather than as an app users install. Publishing a normal Copilot agent to Teams is a one-click action — it shows up as an app, like any other Teams tab or bot. An Autopilot is different: it’s registered as a new entity in Entra ID, with its own blueprint, and it needs the same kind of provisioning you’d give a new employee.

Once live, you can @mention it in Teams, email it directly, and find it listed under a manager in your org chart — exactly like a colleague. Multiple people in the same organization can each create their own instance of the same Autopilot blueprint (the underlying code stays identical, but each instance gets a unique mailbox and identity).

The key technical difference from a normal agent lies in authentication. A standard Foundry agent authenticates with the signed-in user’s token — ask it to check “your mailbox,” and it reads yours, with your permissions. An Autopilot authenticates with its own token. Ask it the same question, and it checks its own mailbox using its own access rights. This is the architectural shift that makes Autopilots powerful — and the reason they need dedicated governance.

Its Own Mailbox, Calendar, and Org Chart Entry

In a live demonstration, an Autopilot named “Workmate” received a customer refund request by email, evaluated it, and replied directly to the customer confirming the refund — all without the human presenter being copied on the exchange or taking any action himself. The customer’s inbox showed a reply from Workmate’s own email address, not a message sent on the presenter’s behalf.

This is the practical implication of Autopilots: they can send mail, book meetings, read shared documents, and take action entirely on their own initiative, using their own credentials — provided they’ve been granted access to the relevant content or mailbox in the first place.

The Rollout Process in Practice

Turning a hosted Foundry agent into an approved, tenant-registered Autopilot involves several distinct steps, each with its own governance checkpoint:

1. Build the hosted agent in Azure AI Foundry
2. Package it for the Activity Protocol, the messaging layer that lets Teams, Outlook, and other M365 surfaces talk to it
3. Register an Azure Bot Service endpoint to handle the activity traffic
4. Get Global Admin approval in the M365 Admin Center — this is not optional and cannot be bypassed by a regular user or maker
5. Define scopes, including which Work IQ and MCP tools the Autopilot is allowed to call
6. Let individuals create their own instance from the approved blueprint
7. Assign each instance its own license, comparable to an E5 assignment, before it becomes visible in Teams and Outlook

Step four is the one many organizations underestimate: unlike the one-click “Publish to Teams” flow for a normal agent, creating an Autopilot identity requires explicit admin sign-off, because you’re effectively creating a new digital employee in the directory.

Why This Becomes a Governance Problem

The licensing step is the one IT leaders should flag early. Every single Autopilot instance needs its own dedicated license to appear in Teams, Outlook, and the org chart, and to use features such as Power Automate or M365 Copilot. If ten people in a department each spin up their own version of the same “Workmate” Autopilot, that’s ten separate licenses — a cost-control conversation most finance teams haven’t had yet, because it doesn’t map cleanly onto existing per-user licensing models.

There’s also a second, less obvious governance question: once an Autopilot has its own mailbox and can act autonomously, who is accountable when it sends an incorrect refund confirmation, replies to the wrong customer, or acts on stale information? Traditional agent governance frameworks — built around “which maker built this and which environment does it live in” — don’t fully answer that question when the agent is, functionally, its own employee.

What Enterprises Should Do Now

Before Autopilots show up in your tenant by accident — created by an enthusiastic maker testing a Foundry blueprint — get ahead of three questions: who is authorized to approve one, who owns the license cost, and who is accountable for its actions once it’s live. This is exactly the kind of governance gap that turns into a much larger cleanup project six months later, similar to the agent sprawl many organizations are already cleaning up in Copilot Studio and Power Platform.

If you’re already dealing with agent sprawl across Power Platform or Copilot Studio, now is the right time to build an Autopilot approval workflow before the first instance appears in your tenant. Book a governance workshop with HanseVision →

FAQ

What’s the difference between a regular agent and an Agent 365 Autopilot?
A regular agent acts on behalf of the signed-in user and authenticates with that user’s token, inheriting their permissions. An Autopilot has its own identity, its own mailbox, and its own token, and it acts entirely on its own behalf — with its own, separately assigned permissions.

Does every Autopilot really need its own license?
Yes. Each instance needs a dedicated license, similar in scope to an E5 assignment, to appear in Teams, Outlook, and the org chart, and to use Power Automate or Copilot features. This applies per instance, not per blueprint — so multiple people each running “their own” Autopilot means multiple licenses.

Who approves an Autopilot in the tenant?
A Global Admin. Publishing an agent as an Autopilot requires explicit approval in the M365 Admin Center, unlike the one-click Teams publish flow used for regular agents.

Can an Autopilot access any mailbox or document it wants?
No. It can only read or act on content it has been explicitly granted access to — the same way a new employee would need to be added to a distribution list or shared folder before they could see its contents.

Watch the full video with Ayça Baş, Senior Developer Advocate at Microsoft

PS: Ready to implement proper AI agent governance? Contact me, Ragnar Heil, for a consultation on Agent 365, SharePoint Advanced Management, Microsoft Purview (Information Protection, Data Loss Prevention Policies, DSPM for AI), Rencore Governance, EasyLife365 Collaboration, ShareGate Protect, Data&More or Agent 365 deployment strategies tailored to your organization’s needs. Find my calendar here at our HanseVision Governance Landing Page.