Shadow Agents: Somebody in Your Company Has Already Built One

An operations manager I know built an agent that reads the daily exception report, cross-references it against three internal systems, and posts a prioritised summary to her team's channel every morning. It saves her team about six hours a week. It has been running for four months.

Nobody in IT knows it exists. She did not hide it. She just did not think of it as something that needed permission, because from where she was sitting it was a clever use of a tool the company had bought her a licence for.

That is shadow AI in 2026, and it is not an edge case. Copilot Studio users have collectively created over a million agents. Every major SaaS product now ships some agent-building capability. Developers connect MCP servers to their local tooling without a ticket. The population of agents in a large organisation is not something anyone decided; it accumulated.

Why the ban does not work

The first instinct is always to prohibit it. I understand the instinct and I have watched it fail enough times to be confident about the outcome.

Shadow IT was banned for two decades and the result was Dropbox in every department. The mechanism is straightforward: if the sanctioned path takes six weeks and the unsanctioned path takes an afternoon, people take the afternoon, especially when they are trying to do their job well rather than trying to break rules.

Agent building has an additional wrinkle that makes prohibition even weaker. The tools are already inside your perimeter, bought and licensed, embedded in products you deployed for other reasons. You cannot block them without disabling features your organisation is paying for and, in some cases, relying on.

And the demand is legitimate. That operations manager was solving a real problem that nobody was going to solve for her. A policy that stops her is a policy that costs the company six hours a week to avoid a risk nobody has quantified.

What actually goes wrong

I want to be precise about the risk, because vague risk language is why these conversations go nowhere.

Shadow agents create four specific problems.

Data reaching places it should not. The agent reads from a system with sensitive records and writes a summary to a channel with broader membership than the source system's access list. Nobody intended a permissions bypass; one happened. This is the most common and most serious issue by a distance.

Undocumented dependencies. The agent becomes load-bearing for a process. Then the person who built it leaves, or a source system changes format, and a workflow several people rely on quietly stops working correctly. Because it was never registered, nobody knows where to look.

Credentials that outlive their purpose. The agent uses the builder's own OAuth grants against half a dozen SaaS tools. When they change roles, the grants often persist. Now something is running with the access of a job nobody holds.

Compliance surface nobody counted. If a shadow agent influences a hiring decision, a credit judgment, or customer-facing content, it may fall under obligations you have carefully mapped for your official systems, and it is not in your inventory. That is the scenario where a discovery exercise during an audit is genuinely painful.

Notably absent from that list: the agent giving a wrong answer. That happens, and it is usually the least of it, because the person who built it is also the person checking it.

Finding them

Discovery is more tractable than people assume. A fortnight of work finds most of the population.

OAuth grants are the richest source. Every major SaaS platform can list third-party applications authorised against user accounts. Pull that list, filter for AI platforms and automation tools, and you have a substantial share of the shadow estate along with the names of the people who authorised them.

Your agent platform admin consoles know. Copilot Studio, and its equivalents in the other suites, have tenant-level views of what has been built. Most organisations have never looked at them.

Expense and card data catches the rest. Individual subscriptions to AI tools, API credits, and automation platforms show up as small recurring charges, often under someone's personal expense line.

Network and DNS logs catch the developer end: MCP servers, local agent frameworks, and API traffic to model providers from workstations.

Then, and this is the step people skip, ask. An amnesty announcement, phrased as "tell us what you have built and we will help you keep it running" rather than "declare your violations", surfaces more than the technical discovery does. People are generally proud of what they built and want it to be supported.

The response that works

The pattern that holds up is a tiered one. Not everything needs the same treatment, and treating a summary bot like a payments agent is how you make the whole programme unworkable.

Bright lines, few and absolute. A short list of things no agent may do without formal review, regardless of who built it or how. In most organisations that is: no agent touches regulated personal data, no agent moves money, no agent sends external communications on the company's behalf, no agent makes or influences employment decisions. Four rules that fit on a slide. Everything outside them is permitted.

The value of a short list is that people remember it. A thirty-page policy is a policy nobody reads and therefore a policy nobody follows.

A registry with a low barrier. A form that takes five minutes: what it does, what it reads, what it writes, who owns it. Not an approval process. A registration. The purpose is visibility, and adding an approval gate is what makes people stop registering.

A sanctioned path that is genuinely faster. This is the part that determines whether the programme works. If someone wants to build an agent that touches an internal system, they need to get access, and if that takes six weeks they will find another way. A path that gets them a scoped credential in an afternoon converts shadow builders into registered ones by making registration the easier option.

Adoption of the good ones. When discovery finds an agent that is genuinely valuable, and it will, take it seriously. Give it a technical owner, put it on supported infrastructure, and tell the organisation you did. That single act does more for compliance culture than any policy document, because it demonstrates that declaring something gets it supported rather than shut down.

The bit people get wrong

The mistake I see most often is treating this as a security programme rather than an enablement programme with security properties.

Run as a security programme, it produces a policy, a scary email, a low registration rate, and a shadow estate that is now deliberately hidden rather than merely unrecorded. You are worse off than before, because previously people would tell you if you asked.

Run as an enablement programme, it produces a registry that people voluntarily add to, because being in the registry gets you help. The security outcome is a side effect and it is better than the one the security programme would have achieved.

That framing is not a trick. It reflects something real: the people building shadow agents are usually your most engaged employees, working out how to do their jobs better with the tools available. Treating them as a risk to be managed rather than a resource to be supported gets you the compliance posture you deserve.

A reasonable first ninety days

Run the discovery in weeks one and two: OAuth grants, platform consoles, expense data, network logs.

Announce the amnesty in week three, with the short list of bright lines and the registration form. Be explicit that nothing gets shut down without a conversation.

Spend weeks four to eight triaging what you found against the bright lines. Most of it will be harmless and can be registered and left alone. A small number will cross a line and need real attention. In every exercise I have been part of, the number crossing a line has been under 10% of the population, and one or two of them have been genuinely alarming.

Build the fast path over the same period, because without it the whole thing decays within two quarters.

And put a review date on the registry, because agents outlive their usefulness and nothing ever gets decommissioned unless somebody is asked to look.

What this is really about

The uncomfortable truth underneath shadow agents is that they exist because your official AI programme is too slow for the demand it created. Every shadow agent is a small piece of evidence about a process somebody wanted improved and could not get on a roadmap.

Read that way, the discovery exercise is not just a risk assessment. It is the best list you will ever get of where automation would actually be valued, written by the people who do the work, ranked by how badly they wanted it. I would go through that list carefully before commissioning another AI strategy workshop.

We help organisations run this kind of discovery and then productionise the handful of shadow agents worth keeping. If you suspect you have a population you cannot currently count, that is a good place to start a conversation.