Shadow AI: Employees Using Tools You Didn't Approve
5 min read · updated August 3, 2026
Shadow AI is usually discussed with a percentage attached. You do not need the percentage; you have the telemetry. Five systems you already run will tell you what is being used in your own company this week, and one of them will tell you something considerably more serious than a chatbot in a browser tab.
Why the ban does not work
The reflex is a policy that forbids unapproved tools. The mechanical problem with it is not that people are defiant; it is that the ban removes your remaining visibility. Before the ban, some use is observable in ordinary logs. After it, use moves to personal devices and personal accounts, where you have no telemetry at all, and the quantity you were worried about is now unmeasurable rather than reduced.
The second problem is that a ban with no sanctioned alternative asks people to be slower than their peers at the same job. That is a request, not a control, and it decays. So the sequence that works is: measure, then provide a path, then restrict — and the restriction is credible only because the path exists.
It is worth being precise about what is actually at stake, because “shadow AI” is often discussed as though the harm were obvious. There are three distinct harms and they need different responses. The first is disclosure: material leaves the company to a party whose terms nobody read, and once it has left you cannot un-send it. The second is contractual: if the material belonged to a customer, sending it to an unlisted processor may breach an agreement you signed, and that is a breach whether or not anything bad happens to the data. The third is provenance: output with no record of where it came from enters a document, a decision or a codebase, and nobody can reconstruct later what was checked. The first two are addressed by controls and contracts; the third is addressed by giving people a sanctioned tool whose use leaves a trace.
Five places it is already recorded
None of these requires new tooling. Each has a characteristic bias, and knowing the bias stops you over-reading a number.
| Source | Description |
|---|---|
| identity provider | SSO sign-in logs list every application anyone authenticated to with a corporate identity, with counts and first-seen dates. Strong signal of sustained use. Misses anything signed up for with a personal email or a password rather than SSO — which is most free-tier use. |
| web gateway / DNS | Requests from managed devices to known AI domains. Broad coverage of what is being visited. Over-counts badly: one curious page view looks identical to daily use, so read it as a candidate list rather than a usage measure. Misses personal devices and anything off the corporate network. |
| expense and card data | Individually expensed subscriptions and departmental card spend. This is the highest-confidence signal that exists — somebody paid — and it is the one that identifies tools already embedded in a workflow. Misses free tiers entirely, which is where most of the volume is. |
| OAuth grants in your own SaaS | Third-party applications your staff have authorised against your mail, files, chat or code hosting. Visible in the admin console of each platform. This is not a browsing signal; it is a standing data-access grant, and it is covered on its own below. |
| device inventory | Browser extensions and installed applications on managed endpoints. Catches the assistants that live in the browser and read every page, which the gateway logs may not distinguish from ordinary traffic. |
A sixth source is worth adding even though it is not telemetry: an anonymous internal survey. It under-reports, obviously and irreparably, so do not use it to count anything. Use it for the one question logs cannot answer — what were you trying to do — because the answer is the specification for the sanctioned tool you are about to provide.
Two cautions about reading the combined picture. The sources overlap unevenly, so do not add them up: the same person appears in the identity logs, the gateway logs and the expense data, and a naive union inflates the count while a naive intersection collapses it. Report the list of tools with the evidence for each rather than a headcount. And treat absence as weak evidence — the whole point of the exercise is that most of this activity is happening on paths you do not instrument, so a quiet inventory means your telemetry has gaps, not that nothing is happening.
The one everybody misses
Browsing to a chatbot and pasting a paragraph is a disclosure of that paragraph. Granting a third-party application OAuth access to your mailbox, your drive or your repositories is a disclosure of everything in them, continuously, until the grant is revoked — including everything added afterwards, and including whatever colleagues shared with that person.
These grants are easy to make, look like a normal sign-in, and are recorded in your own administration console rather than anywhere security is watching. They are also the finding most likely to be material: a note-taking assistant that joins meetings, an email assistant with mailbox scope, a coding assistant with repository access. For each grant, the questions are the ordinary ones — what the terms say about training, what retention applies, and who the sub-processors are — but they are now being asked about a vendor nobody reviewed.
Two practical notes. First, enumerate grants per platform and per scope rather than per user; the same application often holds different scopes for different people. Second, restricting who may grant which scopes is a control you can apply immediately and independently of any AI policy, and it is usually the single highest-value action on the whole list.
Triage by data reach
Do not rank the inventory by how many people use a tool. Rank it by what the tool can reach and for how long, which is the quantity that decides what a mistake costs.
priority = reach x persistence x sensitivity
reach 1 one paste at a time, typed by a person
2 files a person uploads deliberately
3 standing access to a mailbox, drive or repo
persistence 1 ephemeral session
2 account with stored history
3 continuous sync
sensitivity 1 public or already-published material
2 internal
3 customer, personal or regulated data
Anything scoring reach = 3 goes to the top regardless of
how few people are using it.This ordering is deliberately at odds with intuition. A chat tool used by two hundred people to rewrite emails is a policy and training question. One note-taking integration with calendar and mailbox scope, used by four executives, is a data processing arrangement nobody reviewed — and it belongs on the risk register this week.
What to do with the list
- Revoke on reach, not on brand. Standing grants that fail the data-terms rows of a vendor checklist come off now. Browser-tab use of the same vendor can wait for the policy.
- Provide the path before the prohibition. One sanctioned general-purpose tool, procured properly, available to everyone who wants it, with the data question answered. The cheapest way to end shadow use of a category is to make the approved option the fastest option.
- Write the rule about what may be pasted, not about which brand. Brand lists go stale monthly; a rule about data classes survives the next launch.
- Re-run the inventory on a schedule. Quarterly, from the same five sources, so the trend is visible. This is the one place a number is genuinely useful — your own, over time, measured the same way twice.
- Do not open with enforcement. The first inventory exists to size the problem and to find the standing grants. An inventory that arrives as a disciplinary exercise is the last honest one you will get.