Your AI Agents Now Have Mailboxes. Your Permission Model Does Not Know That.

The sentence worth re-reading

Copilot Studio agents can now be given their own Microsoft 365 account — a governed identity with its own mailbox, Teams presence and Office access — so they can participate in shared business processes across teams, with administrators controlling access, policies and use as a first-class entity.

Most coverage filed this under productivity. It is an identity change, and for SharePoint it is the most consequential one in years.

An agent is no longer a feature executing inside a user's session. It is a principal in your directory.

---

Why that single word changes your permission model

SharePoint permissions are granted to principals. That is the whole model.

Once an agent is a directory object, it can be:

• Added to Microsoft 365 groups and SharePoint groups
• Granted direct access to a site, library, folder or item
• Inherited into access through nested group membership
• Included in whatever broad organizational scopes your tenant uses

Every construct in your permission model will accept it, because every construct was built to accept principals and the agent is now a principal.

None of those constructs were designed on the assumption that a principal could be created by a citizen developer in an afternoon.

That is the gap. Not a vulnerability — a design assumption that quietly stopped being true.

---

Joiner-mover-leaver has no agent lane

Every mature organization runs identity lifecycle on three events:

• Joiner — HR hires someone, an account is provisioned, access follows role
• Mover — role changes, access is supposed to change with it
• Leaver — HR terminates, offboarding revokes access

It works imperfectly. Movers are where access accumulates. But there is a process, an owner, and a trigger.

Agents have none of the three.

Joiner: a maker creates an agent. Possibly for one project, one team, one quarter. No HR event. No role template. No access baseline.

Mover: the agent's purpose expands because it was useful. Someone grants it a bit more access. No review.

Leaver: the project ends. The team moves on. Nothing in the organization is responsible for noticing. No termination event fires. The agent keeps its mailbox, its Teams presence and its site access indefinitely.

That last one is the real exposure. Not a dramatic breach — standing privilege that nobody owns, created by someone who has moved on, attached to a purpose that no longer exists.

Service accounts taught this lesson already. The difference is that service accounts were created by infrastructure teams who at least knew they were creating something permanent. Agents are created by makers, by design, at scale, as a feature.

---

The question to answer before agents proliferate

Here is the one worth testing deliberately rather than assuming:

What can a newly created agent identity reach in your tenant by default?

Broad scopes and inherited group memberships are the mechanism by which access arrives at principals nobody explicitly granted. If your tenant has organization-wide groups that confer content access, and agent identities land inside them by default, then agent creation grants content access as a side effect of existing.

We are not going to assert what the answer is in your environment — it depends on your configuration and how the identity is provisioned. We are saying the answer should be tested and written down before the agent population grows, not inferred afterward.

Create a test agent identity. Enumerate what it can actually read. That exercise takes an afternoon and will tell you more than any amount of policy discussion.

---

The oversharing problem compounds, again

Readers of our Copilot coverage know the recurring theme: Copilot converts theoretical access into practical access. Content a user could technically reach but would never find becomes one prompt away.

Agent identities add a second multiplier.

A human with over-broad access is bounded by attention. They have a job, they look at what they need, the over-permissioned folder from 2019 stays unvisited.

An agent is not bounded by attention. It operates at machine speed, across whatever it can reach, repeatedly, as a scheduled or triggered process. Grant an agent membership in a group that confers access to three thousand sites and it does not get bored.

The oversharing that has sat harmlessly in your tenant for a decade was harmless partly because nobody had the patience to exploit it. That property does not survive non-human principals.

---

What good governance looks like

Treat an agent identity as what it functionally is: a service account that can read, write and send mail.

Named human owner. Every agent identity has a person accountable for it. Not a team — a person. When they leave, ownership transfers explicitly or the agent is decommissioned.

Documented purpose. One or two sentences on what it does and why it needs the access it has. If nobody can write that sentence, the agent should not have the access.

Explicit scope over inherited scope. Prefer direct, narrow grants to the specific sites and libraries the agent needs. Keep agents out of broad organizational groups unless there is a written reason. Direct grants are visible and intentional; inherited grants are neither.

A review date. Agents get reviewed on a cadence — purpose still valid, access still minimal, owner still present.

A decommission path. Defined before creation, not improvised at cleanup time. What happens to the mailbox, the Teams presence, the group memberships and the content it produced.

Inventory first. Microsoft shipped multi-tenant agent management in public preview in the Microsoft 365 admin center, giving administrators a centralized view across tenants. Use it. You cannot review, scope or decommission a population you have not enumerated, and agent creation is distributed by design.

---

Our read

This is the right architectural direction. An agent participating in business processes genuinely needs an identity — governing something that runs under a rotating cast of user contexts is far worse, and the pre-identity model made agent actions nearly impossible to attribute.

But the governance work landed in a different place than the capability. The capability sits with makers, who can create agents quickly. The consequence sits with whoever owns identity lifecycle and SharePoint permissions, who in most organizations has not yet been told this is now part of their remit.

The organizations that get this right will do something unglamorous: decide that an agent identity is a governed object with an owner, a scope and an expiry before they have two hundred of them. The ones that do not will run a non-human-identity cleanup project in about eighteen months, and it will be considerably harder than this conversation, because by then the agents will be load-bearing.

Your permission model is about to meet principals it was never designed for. Better to introduce them deliberately.

---

Need your permission model assessed before agent identities scale across your tenant? See SharePoint Consulting and SharePoint & Copilot, or get in touch.

Sources

• What's new in Copilot in SharePoint: October 2026 — Microsoft Community Hub
• SharePoint AI innovations hit GA, powering new Copilot app and agents — Microsoft Community Hub
• Microsoft 365 Roadmap Updates October 2026 — LevelUp M365