Agent sprawl is an access problem, not a count

The short answer: what agent sprawl is in Microsoft 365

Agent sprawl is the growing set of AI agents that people across the business build in Microsoft 365 without going through IT. The risk is not the number. An agent runs against the permissions of whoever built it, so one agent built by a person with broad access can answer questions about content nobody meant it to reach.

An agent is Copilot pointed at one job and left running
It inherits its builder's access, not a purpose-built grant
Reach, not volume, decides how big the problem is

Definition

What an AI agent is in Microsoft 365 Copilot

Microsoft 365 Copilot answers a question when someone asks it. An agent is the same underlying capability, pointed at a specific job and left running. Somebody decides that the weekly supplier summary should write itself, builds something that does it, and shares it with their team.

In Microsoft environments they come from a handful of places: Copilot Studio, Agent Builder, SharePoint agents, declarative agents, and agents brought in from outside. The important thing about all of them is who builds them. These are not developer tools. They are built by the people who understand the process, which usually means someone in finance, operations, or HR rather than anyone in IT.

That is a good thing. It is the same shift that made Power Platform useful, and before that SharePoint, and before that spreadsheets. Microsoft's 2026 Work Trend Index reports that active agents in Microsoft 365 grew 15 times year on year, and 18 times in large enterprises. That growth is adoption working.

Inherited access

Why an AI agent inherits the access of its builder

An agent runs against the permissions it is granted, and in practice that is usually the access of the person who built it. So when someone in finance builds an agent to summarize supplier contracts, that agent can reach what they can reach. Once they share it with the team, everyone who uses it is effectively asking questions through their colleague's permissions.

Nobody granted that access for this purpose, because nobody was asked. It was granted to a person doing a job, years before anyone built anything on top of it.

None of this requires anyone to behave badly. The access was legitimate. The agent is useful. The sharing was helpful. The gap opens because permissions were designed for people, and an agent is not a person. It does not forget what it saw, it does not change roles, and it does not notice that a document looks sensitive.

Which is why counting them misses the point

Most conversations about agent sprawl are about volume. How many will we have next year, how do we stop the number growing, should we restrict who can build them.

Volume on its own tells you very little. A thousand agents that each read one team's project plans is a smaller problem than three agents that can each reach the whole finance share. The number tells you how much there is to look at. It does not tell you what is actually exposed.

The question that does is this one: what can each agent reach, as opposed to who is allowed to use it? Those two things get treated as the same question, and they are not. Access to the agent is a sharing decision somebody made deliberately. Access through the agent is inherited, and usually nobody has looked at it.

This is also why restricting who can build agents rarely works as a response. It slows the thing that is creating value, and it does nothing about the agents already running.

This week

Three agent sprawl checks for this week

Find out who has built agents, and whether they still work here. Start by asking rather than scanning. The interesting answers are the agents built by people who have since moved team or left.
Pick one agent and trace what it can reach. Not who uses it. One agent traced properly tells you more about your exposure than a count of all of them.
Ask what happens when an agent's builder leaves. Offboarding usually handles the person. It less often handles what the person built.

Read the longer version

This builds on sections 4 and 5 of Regulating your AI companion, with the regulatory position, the cost picture and what a governance model for the agent layer looks like. Rencore Governance shows what every agent can reach, not only who uses it.

Download Regulating your AI companion (PDF)

Frequently asked questions

What is agent sprawl?

Agent sprawl is the growth of AI agents built by people across the business, in tools such as Copilot Studio, Agent Builder and SharePoint, without a central inventory, owner or review. The agents are useful; the gap opens because nobody can say what each one can reach.

Why does an AI agent inherit its builder's access?

An agent runs against the permissions it is granted, and in practice that is usually the access of the person who built it. Nobody approved that access for this purpose: it was granted to a person doing a job, years before the agent existed.

Should we restrict who can build agents?

Rarely. Restriction slows the thing that creates value and does nothing about the agents that already exist. A better response is to see every agent, name an owner and review what each one reaches.

What is the first thing to check?

Find out who has built agents and whether they still work here, then pick one agent and trace what it can reach. One agent traced properly tells you more about your exposure than a count of all of them.

How does Rencore help with agent sprawl?

Rencore Governance inventories the agents in your Microsoft 365 tenant with their owners and the content they can reach, flags agents with no active owner, and enforces policies on a schedule.

Go deeper

Agent sprawl is an access problem, not a counting problem