How is shadow AI different from shadow IT?

Shadow IT is usually an unapproved vendor relationship, which leaves traces in billing and network logs. Shadow AI is often an unapproved *capability* added to an approved tool through a config file, which leaves no such trace.

Should we just block AI tools we have not approved?

Blocking without a sanctioned alternative moves the activity to personal devices, which is strictly worse for visibility. A curated, fast, obviously-better internal path outcompetes the shadow path.

Practices

Shadow AI

definition

Shadow AI is the use of AI tools, models, or agent configurations inside an organisation without the knowledge or approval of IT and security.

In depth

Shadow AI is shadow IT with a shorter adoption curve and a worse data profile. An engineer signs up for a coding assistant with a personal account, pastes a proprietary file into a consumer chat product, or connects a third-party MCP server to a work laptop. Each step is individually reasonable and collectively invisible.

Discovery is genuinely harder than it was for shadow SaaS. The old playbook — find the unsanctioned vendor in the expense report or the network logs — misses most of this. Agent capability arrives as a config file, not a purchase. A local MCP server may only ever talk to localhost. A skill is a folder of Markdown. Nothing crosses a boundary a CASB is watching.

The exposure has two halves that get conflated. One is data: what left, to whom, under what retention terms. The other, newer and less discussed, is *capability*: which unreviewed tools an approved AI surface can now reach, and with which credentials. The second is the one that turns a policy problem into an incident, because it is what gives a prompt injection somewhere to go.

Bans reliably fail here, and they fail in a specific way: usage moves to personal devices and personal accounts, where there is no telemetry at all. The organisations that get this under control offer a sanctioned path that is genuinely faster than the unsanctioned one, and make the approved artifacts easier to install than the arbitrary ones.

Why it matters for governance

The practical starting point is an inventory, not a policy. Which AI surfaces are in use, which skills, rules, hooks, and connectors each one loads, and which of those has anyone looked at. Most organisations discover they cannot answer the second question at all — which is itself the finding, and the reason a central registry with a real lockfile is the first control worth building.

Frequently asked

How is shadow AI different from shadow IT?: Shadow IT is usually an unapproved vendor relationship, which leaves traces in billing and network logs. Shadow AI is often an unapproved *capability* added to an approved tool through a config file, which leaves no such trace.
Should we just block AI tools we have not approved?: Blocking without a sanctioned alternative moves the activity to personal devices, which is strictly worse for visibility. A curated, fast, obviously-better internal path outcompetes the shadow path.

Sources

Primary sources for the claims on this page. Specifications and vendor documentation change — verify against the source if a detail is load-bearing for a decision you are making.