Shadow AI and Agent Sprawl: How to Govern Copilot Studio Agents Nobody Remembers Building
Shadow IT used to mean someone signing up for a SaaS tool without telling procurement. Shadow AI is a different scale of problem. Research from Token Security reported that 82% of organisations had already found AI agents running in their environment that nobody formally approved, and only 21% had a proper process to shut an agent down when it was no longer needed.
In Microsoft 365 the cause is simple: Copilot Studio, Agent Builder and Teams made building an agent a five-minute job. That’s a real productivity win. But creation takes five minutes and ownership lasts for years, and only one of those gets recorded anywhere. Here’s how I help clients get agent sprawl under control without killing innovation.
How agent sprawl happens (for good reasons)
- A Copilot Studio workshop where everyone builds something, because that’s the point of a workshop.
- A department answers its own HR-policy questions in an afternoon, which is exactly what the platform promises.
- A pilot is built for a board demo, the demo goes well, and the agent stays switched on.
None of that is misuse. It’s the product working. The problem appears months later: the builder changes role or leaves, and the agent keeps running, still connected to a SharePoint site full of sensitive documents, with nobody accountable for it.
Why it’s riskier than traditional shadow IT
A rogue SaaS subscription is mostly passive: a cost and compliance issue until finance notices the invoice. An agent is active. It can read data, call connectors and take actions, using whatever access it was given. Agents, service accounts and API keys now far outnumber human identities in most enterprises, and in a shadow AI scenario none of that access was ever reviewed.
Four states worth separating
“How many agents do we have?” is the wrong first question. The number on its own tells you nothing. Split the population into four states instead:
| State | What it means | Priority |
|---|---|---|
| Published and used | Working software, delivering value | Leave it alone, but review it when its sources change |
| Published and unused | Live and reachable, but answering nobody | Low: retire to reduce clutter and attack surface |
| Orphaned | The owner has left or changed role | High: nobody can say what it’s for |
| Touching sensitive content | Grounded in HR, contracts or labelled content | High: shorter review cycle |
An unowned agent is worse than an unused one
An unused agent costs you clutter. An unowned one costs you the ability to make any decision about it. Retiring it, re-grounding it, restricting access or answering an auditor’s question all start with finding a person who can say what it’s for. Without that person, the “safe” option is always to leave it running, so it runs.
That’s why ownership needs to be a field you can report on, not a convention people are asked to follow.
The knowledge source is the risk, not the agent
Think of an agent less as an app and more as a front door onto content. It answers from whatever it’s grounded in, through the permissions of the person asking. So the real governance question is rarely “is this agent dangerous?” but “what is it grounded in, and who can reach that?”
A useful inventory entry reads like this: this agent, owned by this person, grounded in these sites, published to these channels, last used on this date. An inventory without knowledge sources is only half an inventory.
Governance as a lifecycle, not an approval gate
The instinct after finding dozens of agents is to put a request form in front of the next one. That usually produces a queue, and people quietly building outside it. The lighter model that actually works has four parts, and none of them blocks creation:
- Every agent has a named owner, recorded at creation and checked regularly.
- Ownership transfers with the person. Agents belong in the leaver process, next to the mailbox and licences.
- Every agent has a review date proportionate to what it’s grounded in: short for sensitive content, long for a public FAQ bot.
- Retirement is normal. Most workshop agents should be switched off within a quarter, and saying so up front makes it easy.
Add the platform guardrails too: DLP policies on connectors, Managed Environments with sharing limits, and mandatory Entra ID authentication for Copilot Studio agents. See the Power Platform governance guide for the setup.
Finding the agents you already have
Everything above depends on knowing what exists. Write the policy after the inventory, not before. The Microsoft 365 admin centre’s agent inventory is a good start. For a governance worklist, LogiSam’s Copilot Insights lists every agent with its owner, channels and authentication mode, and flags unused, orphaned and sensitive-data agents. It reads metadata only and never conversation content.
For the architecture side, meaning how to design agents that are reliable and safe from the start, read Copilot Studio architecture: knowledge vs actions.
FAQ
What is shadow AI?
AI tools and agents used or built without formal approval or oversight, from personal ChatGPT accounts to Copilot Studio agents connected to company data.
Should we stop employees building Copilot agents?
No. Allow creation in governed environments, require ownership and authentication, and review agents regularly. Blocking creation pushes it further into the shadows.
What should happen to an agent when its owner leaves?
Ownership should transfer as part of the leaver process. If nobody takes it on, the agent should be retired.
