Guide · Govern
How to find and shut down shadow AI
Blocking AI domains does not remove AI from your company. It removes your visibility of it, moves usage to personal devices, and converts a governance problem you could measure into one you cannot.
before you start
- Read access to egress logs or your network monitoring, and to SaaS OAuth grants.
- Expense and procurement data — a great deal of shadow AI arrives on a corporate card.
- Authority to offer a sanctioned alternative, because inventory without a replacement fails.
Why the obvious approach does not work
Shadow AI is usually framed as a discipline problem and treated with a blocklist. That framing is wrong on the facts. People adopt these tools because they work, under deadlines you set, and a block does not change the incentive — it changes the channel. The predictable result is the same work happening on a phone, a personal laptop or a home account, where you have no logs, no data-retention terms and no ability to revoke anything.
The inventory is also harder than it looks, because AI use has stopped being a website visit. It arrives as an IDE extension, a CLI installed with a package manager, an MCP server pointed at an internal database, a browser extension, a GitHub Action, and OAuth grants against your own SaaS. A DNS-level view of `chat.openai.com` catches a fraction of that, and the fraction it catches is the least risky part — a chat window is far less exposed than an agent holding a repository token.
The exposure that actually matters is rarely the model provider. It is the connection: an unsanctioned MCP server with credentials to a production database, an agent with repository write access on an unmanaged laptop, a browser extension with read access to every page including your admin consoles. Those are data-access decisions made by individuals with no review, and none of them look like 'visiting an AI site'.
Which is why the only durable exit is substitution, not prohibition. If the sanctioned path is slower, more restricted, or requires a ticket, people route around it and you are back where you started with worse telemetry. The programme has to end with a default that is genuinely easier than the shadow one — that is the whole game, and the inventory is just how you learn what you are competing against.
The procedure
Look where AI actually enters, not just at AI domains
Pull five sources in parallel: egress logs filtered for model-provider and AI-tool API endpoints, OAuth grants in your identity provider and SaaS admin consoles, IDE and browser extension inventories from endpoint management, package-manager telemetry for AI CLIs, and expense data for AI subscriptions. Each finds a population the others miss. Expense data in particular tends to surface whole teams at once.
you now haveA raw list of tools, the people or teams using them, and how each was discovered.
Rank by data access, not by user count
For each entry, record what it can reach: nothing, public code, internal code, customer data, production systems. Then sort by that, not by popularity. Forty people pasting text into a chat window is a policy conversation. One unsanctioned agent holding a production database credential is an incident waiting for a date, and it will sit near the bottom of any list sorted by usage.
you now haveThe inventory re-sorted by data reach, with your top five genuine exposures named.
Ask the users why, before you decide anything
Interview a handful of people from the top of the list, with amnesty and without a compliance framing. You are gathering requirements for the sanctioned replacement: what job it does, what the official option lacked, how long they have used it. This step is what makes the difference between a programme that lands and a policy people work around, and it usually reveals that the sanctioned tool was missing one specific capability.
you now haveThree to five concrete requirements the sanctioned path must meet to win.
Ship a sanctioned default that is genuinely better
Stand up the approved surface with the enterprise terms you need, then make it the path of least resistance: pre-authenticated, pre-configured with the connectors people actually asked for, and with the reviewed artefacts already loaded. If a developer has to file a ticket to add an MCP server, you have designed a system that loses to a shadow one. Configure the vendor's own admin controls fully while you are here — they are real and you are paying for them.
you now haveA sanctioned surface in production that is faster to use than the shadow alternative.
Revoke by access, then keep watching
Now remove the shadow paths — but revoke the *credential and the OAuth grant*, not the domain. Killing the token is what actually ends the data access; blocking the hostname just relocates it. Then make discovery a standing job rather than a project: the same five sources, on a schedule, with a named owner. New tools appear continuously and the inventory decays in weeks.
you now haveRevoked grants, a recurring discovery job, and a named owner for the inventory.
Shadow AI discovery sources
Work all seven. Each one surfaces a population the others structurally cannot see.
Shadow AI discovery sources
1. EGRESS / PROXY LOGS
Filter for model-provider API endpoints, not just chat UIs. API traffic is the
agent traffic, and agents are the higher exposure.
2. OAUTH GRANTS
Identity provider + every SaaS admin console. Look for AI tools granted scopes
against your own systems. This is where data actually leaves.
3. IDE + BROWSER EXTENSIONS
Endpoint management inventory. Extensions with broad page-read access see your
admin consoles and internal apps too.
4. PACKAGE MANAGERS
npm / pip / brew / cargo telemetry for AI CLIs and agent frameworks. Catches the
terminal-based agents that never touch a browser.
5. EXPENSE + PROCUREMENT
Card statements and reimbursements. Surfaces whole teams at once and gives you
the strongest signal of committed, habitual use.
6. CODE + CI
Repository search for API keys, agent config files, MCP server definitions, and
AI steps in CI workflows.
7. MCP SERVER CONFIGS
Per-surface config files on developer machines. This is the highest-risk and
least-inventoried category: connectors pointed at internal systems.
FOR EACH FINDING RECORD:
tool · owner/team · how discovered · data it can reach · credential held ·
sanctioned equivalent · revocation actionWhere this goes wrong
- Blocking domains and calling it done
It converts measurable usage into unmeasurable usage on unmanaged devices. You have not reduced the exposure, you have ended your ability to see it.
- Sorting the inventory by user count
Popularity and risk are nearly unrelated here. The single agent with a production credential outranks the forty people using a chat window, and only a data-reach sort surfaces it.
- Running the programme without amnesty
If disclosure gets people in trouble, you will discover only what your logs already told you. The interviews are where the requirements come from, and they need a safe framing.
- Treating it as a project
A one-off inventory is out of date within a quarter. Without a recurring job and a named owner, you will run the whole exercise again in a year and find the same categories.
Doing this without us
Discovery is entirely doable with what you already own — logs, your identity provider, endpoint management and finance data. The part that decays is the sanctioned side: keeping one reviewed set of connectors and skills current across every surface and machine, so the official path stays the easy path. That is the maintenance burden that quietly reopens the shadow gap, and it is what Vincosha Registry is for.
Frequently asked
- Isn't the simplest answer to ban AI tools outright?
- It is the simplest answer to write and the hardest to enforce. Enforcement requires preventing installation on managed devices, which does nothing about personal ones, so the work continues where you cannot see it. Organisations that have tried this generally end up with the same usage, worse telemetry, and staff who no longer tell them anything.
- How do we find MCP servers our engineers configured themselves?
- They live in per-surface configuration files on developer machines, so endpoint management or a repository search for those config filenames is the practical route. It is worth doing first: these are the findings with real credentials attached, and they will not appear in any network-level view because the connection is often to your own internal systems.
- How long does a credible inventory take?
- Two to three weeks for a first pass if you have log access and finance data, most of it spent reconciling duplicates across the seven sources rather than searching. Then treat it as recurring — the categories are stable but the specific tools turn over quickly.
Sources
Checked on 2026-07-25. Where a vendor control is changing quickly this guide describes the mechanism rather than asserting a current state — verify against the vendor's own documentation, and tell us if we have drifted.