Microsoft’s customers created three million agents in a single year. Very few organizations can say who owns theirs, what those agents can reach, or what happens when the person who built one leaves. That’s agent sprawl.

In 2020 you turned on Microsoft Teams for everybody, and it was the right call. The alternative was watching your organization improvise on consumer tools in the middle of a crisis. Nobody who made that decision should regret it.

What followed was not a failure of judgment. It was arithmetic. Adoption moved faster than governance, and within two years a great many organizations could not say who owned half their workspaces, which ones still mattered, or what was sitting inside them. The cleanup bill arrived long after the decision that caused it, which is precisely why it never felt connected to that decision at all.

That pattern is running again. It is running faster this time, and the thing multiplying is no longer a container. It is an actor.

The numbers are Microsoft’s own

In July 2025 Microsoft told investors that customers had created three million agents in a single year using SharePoint and Copilot Studio. Six months later the company reported that more than eighty percent of the Fortune 500 had active agents built with its low-code and no-code tools and added a sentence that deserved more attention than it received: as agents proliferate, every customer will need new ways to deploy, manage and protect them.

Read that again with your operations hat on. The platform vendor announced extraordinary adoption and, in the same breath, conceded that the management model for it does not exist yet.

One caveat, stated plainly before somebody else raises it: three million is a creation count, not a production count. Plenty of those agents were experiments that went nowhere. That is exactly the problem. An experiment that goes nowhere and is never switched off is the precise object under discussion.

An agent is not a site

A neglected SharePoint site is inert. It holds stale content, consumes storage and waits. A neglected agent does none of those things. It keeps running.

The Teams wave The agent wave
What multiplied Workspaces Agents
Who could create one Anyone with a license Anyone with a license
When neglected Sits idle, holding stale content Keeps running, holding live credentials
Limit of exposure What the site’s own permissions allow What the builder’s permissions allow
Usual trigger for cleanup A storage bill or an audit A production incident

The second row of that table is the one most executives have not been shown. Copilot Studio allows the person building an agent to supply credentials for the agent to use on behalf of whoever is talking to it. Configured that way, the agent does not run with the permissions of the employee asking the question. It runs with the permissions of the person who built it.

Picture a finance director who builds a useful reporting agent and shares it with her department. A SharePoint site could only ever expose what its own permissions allowed. An agent can hand its builder’s reach to everyone who talks to it. That is not a bug, and it is not misuse. It is a documented configuration option, chosen by people who are trying to be helpful and who have never been told what they are choosing.

Microsoft has a name for this – Agent Sprawl.

“Agent sprawl” is not a phrase coined by a vendor with something to sell. It appears in Microsoft’s own Entra documentation, defined as the uncontrolled expansion of agents across an organization without adequate visibility, management, or lifecycle controls.

The same documentation describes how it arises: when agents created for temporary purposes remain in production indefinitely, and when agent permissions exceed actual requirements and are never reviewed.

Those two clauses are a description of your Teams estate in 2022 with one word substituted. The platform vendor has written down the failure mode in advance, which is a courtesy the last wave did not extend to anybody.

The evidence it is already happening

Gartner expects that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps identified only after a production incident occurs. Not caught in design review. Caught afterward, by the incident.

IBM’s 2025 breach research, drawn from six hundred real breaches, found that 13% of organizations reported a breach of an AI model or application. Of those, 97% had no AI access controls in place. Unsanctioned AI use added an average of $670,000 to the cost of a breach.

The attack class is no longer theoretical either. EchoLeak, catalogued as CVE-2025-32711, was the first known case of a prompt injection being weaponized to exfiltrate data from a production AI system. Microsoft patched it and no customer action was required, which is the good news. The bad news is that the category now exists and will be iterated on.

The part nobody wants to hear

An agent can only expose what it is able to reach. Its blast radius is your permissions model, not its own configuration. That single sentence reorders most of the agent governance conversations currently happening in boardrooms.

It means the agent governance program you are about to fund depends on work that has nothing to do with agents. It depends on whether your sites have owners. Whether sharing links have ever been reviewed. Whether permission inheritance is intact. Whether anyone can produce an accurate inventory of what is in the environment at all.

Gartner’s June 2026 survey of 186 organizations found that 51% named oversharing and data loss as the top barrier to a successful Copilot deployment. Ahead of cost. Ahead of user adoption. The barrier was never the AI. It was the data underneath it.

Which is why buying an agent governance tool before doing the permissions work is buying the second thing first. The controls will be excellent, and they will be pointed at a foundation nobody has surveyed.

For a sense of the scale underneath, one governance platform reports scanning an average of 40,000 sharing links across 1,400 workspaces. That is roughly 28 ways into an average workspace, most of them created years ago by people acting in good faith, none of them reviewed since. Every one of those is a door your agents can also walk through.

The questions worth asking

“How many agents do we have?” is the wrong opening question. It produces a number, everyone relaxes, and nothing changes. These are better.

  • Who owns this agent by name, and what is supposed to happen to it when that person changes roles or leaves?
  • Whose permissions does it run on, the user’s or the builder’s?
  • What can it reach today, as distinct from what it was intended to reach on the day it was built?
  • How would anyone find out that it had stopped being needed?
  • Can the person who owns it answer all of the above without being handed administrator rights?

That last question decides whether any of this survives contact with reality. If answering it requires an administrator, it gets answered once, during the project, and never again. Governance that depends on the busiest people in the building is governance with an expiry date.

What closing the gap actually looks like

None of those five questions needs new technology to answer. They need an inventory that is current, owners who are named, and a way to put a question in front of an owner without routing it through an administrator. That is unglamorous work. It is also the work that decides whether your agent strategy has a floor under it.

This is where a governance platform earns its place, and it is worth being concrete rather than gesturing at “visibility.” Orchestry, the platform we implement, works on the substrate. It finds workspaces that have no owner. It inventories every sharing link across SharePoint and OneDrive, risk-rates them, and removes the open ones in bulk. It surfaces broken permission inheritance. It scores the tenant against thirteen governance signals in a Copilot readiness dashboard, so oversharing and ownership drift are numbers on a screen rather than a suspicion. And it runs workspace creation through approved templates, so naming, permissions and sensitivity labels are applied at the moment a workspace is born instead of corrected by whoever notices later.

The piece that matters most for agents is the delegation model. Recurring reviews put ownership, membership, sharing and sensitivity in front of the person who actually owns the workspace, on a schedule you set, and that person answers without being handed tenant-wide administrator rights. That is the difference between a governance program that runs once during a project and one that is still running two years later. A university reported saving roughly 75 hours a month by automating those reviews and handing the decisions back to owners.

Now the honest part, because this is where most vendor writing stops being useful. What nobody on the market fully solves yet is the agent object itself: a live register of every agent, what it connects to, whose credentials it carries, and when it was last reviewed by a human. Microsoft is building toward that with Entra Agent ID. Orchestry is extending its governance model in the same direction. Anyone who tells you the finished answer ships today is selling you something.

Which is the argument for starting underneath rather than waiting for the agent controls to mature. The permissions work is not a prerequisite you clear before the real project begins. It is most of the project. When agent-specific governance does arrive, it lands in an environment where ownership is known and exposure is bounded, or it lands in the one nobody has surveyed. You are choosing which of those you hand it today.

Two sentences on where we fit, since this is our blog and you should be able to see the interest behind it. Compass365 implements Orchestry and designs the governance model underneath it: what gets archived and when, who may approve a new workspace, what a review asks and how often it asks. The software enforces those decisions at a scale no team can match by hand. Somebody still has to make them, and that is usually what we are hired for.

The question What makes it answerable
Who owns this, and what happens when they leave? Ownerless detection across Teams, sites and groups, with reassignment routed to the most active member
Whose permissions does it run on? A permissions and sharing picture for the content underneath, so the answer is bounded either way
What can it reach today? Tenant-wide sharing link inventory with risk ratings and bulk removal, plus broken inheritance detection
How would anyone know it stopped being needed? Policy-driven lifecycle: inactivity thresholds, owner validation, then archival or decommissioning
Can the owner answer without admin rights? Delegated review campaigns and role-based access, so business owners decide without IT in the middle

One thing to check this quarter

Microsoft made Entra Agent IDs mandatory in July 2026, with no opt-out. At around the same time it stopped actively maintaining the Power Platform Center of Excellence Starter Kit, which is the tooling a great many enterprises quietly depend on to find orphaned objects. If that describes your organization, you are running orphan detection on unmaintained software while the number of things to detect climbs. It is a five-minute question to your platform owner and a genuinely awkward one to be asked first by an auditor.

When this is not your problem yet

If you have not deployed Copilot and have not opened up Power Platform, this is a 2027 conversation. File it and revisit when the first business unit asks.

If your permission model is genuinely current, with owners in place, sharing reviewed and inheritance intact, you are in better shape than most and the agent question is a much smaller one for you. It is worth confirming that rather than assuming it.

And if the honest answer is that nobody wants to own the policy, which agents are permitted, who approves them, how long one may run unreviewed, then no platform will rescue that. Software enforces decisions. It does not make them, and it cannot manufacture the will to make them.

You do not get to opt out of the pattern

Adoption always outruns governance. That is what adoption is and slowing it down is rarely the right answer. The choice in front of you is not whether the gap opens. It is whether you close it deliberately, or whether it gets closed for you by something you have to disclose.

Last time, the bill arrived as storage costs, a painful cleanup project, and a year of nobody quite trusting the search results. This time the same bill comes with credentials attached.

Have the awkward conversation before an auditor does.

If you’re not sure who owns your workspaces or what your agents can reach, Qais Gharib can help you find out. Email qgharib@compass365.com to set up a conversation

Frequently Asked Questions

Agent sprawl is the uncontrolled expansion of AI agents across an organization without adequate visibility, management, or lifecycle controls. Microsoft defines it this way in its own Entra documentation. It happens when agents built for a temporary purpose stay in production indefinitely, and when their permissions are never reviewed.

A neglected SharePoint site just sits there, holding stale content. A neglected agent keeps running, and it can hold live credentials. If it was configured to use its builder’s permissions rather than the end user’s, it can expose far more than a stale site ever could.

It depends on how the agent was built. Copilot Studio allows a builder to configure an agent to use their own credentials on behalf of anyone who talks to it. That means the agent’s reach can equal the builder’s reach, not the requester’s.

An agent can only expose what it is able to reach, and that is governed by your existing permissions model. Governance software points at that foundation. If ownership, sharing, and inheritance haven’t been reviewed, the tool has nothing solid to work from.