What is shadow AI?
Shadow AI is AI that people at work are using without the people in charge of it knowing. Examples include employees chatting with AI tools on their personal accounts, using web browser add-ons that send their work to an AI, or running small scripts that quietly call an AI service. Increasingly, it also means new AI features that appear inside software the company approved years ago, back when that software had no AI in it at all.
The scale is no longer speculative. Published research through 2026 reports that shadow AI-linked incidents rose from a fifth to well over two fifths of all AI-related breaches year on year, with an average incident cost in the region of five million dollars. Separate telemetry work found the typical employee putting sensitive data into an AI tool roughly once every three working days.
Two tiers are worth naming separately because they carry different consequences, and most organizations are further into the second than they realise.
| Tier | What it does, and what that costs you |
|---|---|
| Shadow AI | Answers. The exposure is whatever somebody typed or uploaded into it, which is bounded by what they chose to share |
| Shadow agents | Acts. Queries databases, calls APIs, sends messages. The exposure is bounded by the credential it holds, which nobody chose deliberately |
One figure captures the current position better than any adoption statistic. In 2026 research, around a fifth of organizations reported not knowing whether unsanctioned agent-creation tools were in use at all. Not that they had some. That they could not say.
Why is it not just shadow IT?
Because the remediation is different in kind. Shadow IT was a visibility gap you closed by finding the application, revoking access and migrating the data. Shadow AI leaves data in somebody else's system under no contract you signed, and no amount of access revocation brings it back.
Shadow IT held still. An unsanctioned application sat somewhere, its data sat in a store, and both could be found and dealt with on your timetable.
- The exposure is already complete when you find it. Every prompt that already went out is a disclosure that cannot be withdrawn, which is why discovery speed matters more here than it did for shadow IT.
- The counterparty has no obligation to you. Data reaching a consumer tier service typically goes to a vendor with no data-handling agreement in place, which is a materially different position from an unapproved application inside your own estate.
- Discovery is genuinely harder. Shadow IT was an application inventory problem. AI usage hides inside features of software you already approved, in browser tabs, in extensions, and in model calls from developer scripts. An inventory of applications does not capture a behaviour.
- Remediation changes department. Revocation is a security task. Assessing whether a disclosure triggers a notification obligation is a legal one, and it runs on a regulator's timetable rather than yours.
Where does Shadow AI come from?
Five routes, and only the first is the one people picture when they hear the phrase. The other four explain why an organisation with a firm written policy and a well-maintained blocked-domain list still uncovers substantial unsanctioned usage the first time it measures rather than asks.
Worth walking each one, because they need different controls and the middle two are usually missed entirely.
- 01
Unsanctioned toolsSomebody installs or signs up for something outside the approved list. The control: discovery and blocking, which is the one most organizations already have.
- 02
The wrong tierA consumer or free account used for work where an enterprise agreement already exists. Same product, entirely different data terms. The control: account-level enforcement rather than domain blocking, since the domain is sanctioned.
- 03
AI that arrived inside approved softwareYou approved the tool years ago. It has AI features now. Nothing changed on your list. The control: re-reviewing sanctioned vendors when they ship AI, which almost nobody has a process for.
- 04
Direct model callsA developer calls a model API from a script. No application, no login, nothing for an app inventory to find. The control: egress visibility, because this route is invisible to everything else.
- 05
Agent builders inside platforms you licenseIncreasingly the largest source. Your existing platforms now let business users create agents, and those agents inherit real permissions. The control: discovery against the platforms themselves, covered at agent registry.
The third and fifth routes are the ones that defeat a conventional programme. Both arrive through software you already approved, so nothing in your procurement or blocking apparatus registers a change, and both are growing faster than the first.
What changes when Shadow AI can act?
When shadow AI can act, the damage it can cause no longer depends on what someone typed into it. It depends on everything its access key lets it reach. An unapproved chat tool can only leak what a person pasted in. An unapproved AI agent can look through company systems, use other software, and send messages on its own, using permissions that nobody ever set up with that kind of job in mind.
This is a step change rather than a worsening, and it arrives quickly once agent-creation tooling reaches business users. Platform telemetry published in 2026 reported active agents in one major ecosystem growing roughly fifteenfold year on year.
- Exposure is no longer self-limiting. A person pasting into a chat tool decides how much to share. An agent reads what its credential permits, which is usually far more than anybody would have pasted.
- It writes as well as reads. Sending, updating and creating are actions with consequences that outlive the session, and none of them leave the kind of trace a chat transcript does.
- Nobody assigned the permissions deliberately. A business user creating an agent inside a platform typically inherits their own access, so the agent quietly holds whatever that person holds, which is the confused deputy problem described at agent identity.
- It persists. A chat session ends. An agent keeps running on a schedule after the person who created it has moved teams, which is how the unregistered ones outlive their creators.
Why does an approved tools list cannot fix Shadow AI?
Because approving a tool decides which vendor receives your data, not what data reaches them. Sanctioning is a procurement control answering a procurement question, and shadow AI is a behaviour. The two are only loosely related, which is why mature organizations still find exposure.
Three reasons the list underperforms, in the order they usually surface.
- The sanctioned tool still sees whatever is pasted into it. An enterprise agreement constrains what the vendor may do with data. It does not constrain an employee from pasting a customer list into it, and no approval decision ever will.
- The list describes applications, and the risk is a data flow. The same person can use a sanctioned tool safely in the morning and expose regulated data through it in the afternoon. Nothing about the list changes between those two events.
- It ages badly by default. Vendors ship AI features into products approved before AI existed, and no list refreshes itself when that happens.
Which suggests a more useful framing than sanctioned versus unsanctioned. The questions worth asking are what data can reach this, and what can it do afterwards, both of which are answerable about a tool regardless of whether anybody approved it. That reframing is what moves the programme from a procurement exercise to a control.
How do you find and govern it?
Discover before you write policy, and discover by measurement rather than by asking. A survey finds the usage people are comfortable disclosing, which is precisely the usage that was never the problem. Research through 2026 shows the awareness gap has largely closed while the detection gap has not.
Five steps, in the order that produces a result somebody can act on.
-
Measure egress, not intentions
Look at what is actually leaving: traffic to model endpoints, to AI services, to agent platforms. This is the only route that catches direct API calls, and it is usually the first time anybody sees the real number.
-
Ask the platforms you already license what has been built in them
Agent-creation tooling inside your existing estate is now a leading source, and those platforms can be queried directly. This step alone often surfaces more than the network view.
-
Re-review sanctioned vendors that have shipped AI
Take your approved list and establish which entries gained AI features after approval. That set is shadow AI by every definition except the procurement one.
-
Sort by what the thing can reach, not by whether it was approved
A sanctioned chat tool holding no credentials is a smaller problem than an unsanctioned agent holding a service account. Triage on reach, and the list reorders itself usefully.
-
Offer a sanctioned path before you block
People adopt these tools because they work. Blocking without an approved equivalent moves the usage to personal devices, where you lose the visibility you just built. The aim is to make the governed route the easiest one.
One note on how this lands internally. Shadow AI is almost never a discipline problem, and treating it as one guarantees it goes further underground. It is people finding something that works faster than the organisation could approve it. The programmes that succeed treat the discovered usage as a demand signal for what to sanction next, rather than as a list of policy breaches to pursue.