Discovery runbook
Shadow AI
Shadow AI is artificial intelligence being used inside an organisation without the knowledge of the people accountable for its risk. It is not a policy failure — it is what happens when capable tools cost nothing and approval takes six weeks. This page maps the six surfaces where shadow AI is actually detectable, what each one misses, and the order to work through them.
Shadow AI is not shadow IT with a new name
The comparison is natural and it hides three differences that change how you find it and what it costs you.
| Shadow IT | Shadow AI | |
|---|---|---|
| Barrier to adoption | Sign-up, usually a card | A browser tab, frequently free, often already bundled into a tool that was approved |
| What leaves | Files, deliberately uploaded | Whatever is pasted into a prompt — and people paste context, not documents |
| Reversibility | Delete the account, recover the data | Content used for training cannot be recalled |
| Who introduces it | A team, for a task | Individuals, continuously, often without considering it a tool at all |
The third row is the one that matters commercially. A shadow SaaS tool is an unmanaged copy of your data. A shadow AI tool may be an unmanaged copy of your data in somebody else's training corpus, and no amount of subsequent account deletion undoes it. That is why shadow AI discovery is worth doing ahead of the broader SaaS cleanup that has been on the list for two years.
The bundling problem makes this harder than it looks. A meeting-notes tool that was approved in 2023 shipped an AI summariser in 2025. The vendor is on your approved list, the spend is on an existing invoice, the network traffic goes to a domain you already allow — and an AI system is now processing your meetings. Discovery that only looks for new vendors will never see it.
The six detection surfaces
Each surface sees a different slice, and every one of them has a blind spot. Coverage comes from combining them, not from choosing the best one.
| # | Surface | Signal | Blind to |
|---|---|---|---|
| 1 | Network egress and DNS | Resolutions and connections to known model-provider and AI-tool endpoints, from proxy, firewall, secure web gateway or DNS logs | Off-network devices; anything self-hosted; traffic to a shared cloud domain that also serves non-AI services |
| 2 | OAuth grants and app consents | Third-party applications users have granted access to your identity provider — and the scopes they hold | Tools that never request a grant, which is most consumer chat interfaces |
| 3 | Browser extensions | Installed extension inventory from managed-browser policy or endpoint management | Unmanaged and personal browsers; extensions in a second browser profile |
| 4 | Local binaries and IDE plugins | Installed-application inventory from endpoint management — local model runners, AI coding assistants, desktop clients | Anything on an unmanaged device; per-user installs where inventory only scans system paths |
| 5 | Spend | Card and expense data: model-provider invoices, per-seat AI add-ons, API credit purchases | Free tiers, which is where the majority of shadow AI lives |
| 6 | Code and configuration | Repository search for provider SDKs, API base URLs, model identifiers, agent frameworks, and MCP server configuration files | Everything outside version control; notebooks on individual machines |
Surface 5 is the one teams skip and the one that finds the largest single exposures. Free-tier shadow AI is broad but individually small. A team that has been spending £900 a month on API credits against a personal card has built something, it is in production, and nobody has assessed it.
A two-week discovery runbook
Ordered by yield per hour of effort, not by completeness. The point of week one is a defensible first picture, not a perfect inventory.
Days 1–2: the data you already have
- Export 90 days of DNS or proxy logs. Match against a list of model-provider and AI-tool domains — build it from your own known-vendor list plus public compilations, and expect to maintain it.
- Pull the OAuth application consent report from your identity provider. Sort by scope breadth first, not by user count: one grant with mailbox read access outweighs two hundred with profile access.
- Export card and expense transactions for the same period, searched for provider names and the words "AI", "credits", "tokens" and "API".
Days 3–5: the endpoint
- Query installed applications across managed endpoints for local model runners, AI-assisted editors and desktop AI clients. Include per-user install paths, which default scans often miss.
- Pull managed-browser extension inventory. Check permissions, specifically anything that reads page content on all sites.
Days 6–8: the estate you build yourself
- Search every repository for provider SDK imports, API base URLs, model identifiers, agent-framework dependencies and MCP server configuration.
- Check CI/CD secrets and environment variables for provider API keys. A key in a pipeline is a production AI dependency whether or not anyone called it that.
Days 9–10: ask
- Run a short, explicitly amnestied survey. Two questions: what AI tools do you use for work, and what would you stop being able to do if they were removed. The second question is the one that generates honest answers, because it lets people advocate rather than confess.
Then reconcile. The survey will name tools no technical surface found — personal devices, personal accounts — and the technical surfaces will find tools nobody named. The gap between the two lists is a better measure of your governance position than either list alone.
What to do with what you find
The instinct after a first discovery run is to block. It is the wrong first move, and it is wrong for a practical reason rather than a cultural one.
Blocking without providing a sanctioned path does not reduce shadow AI. It relocates it to personal devices, where you have no detection surface at all.
You will have traded a visible problem for an invisible one, and lost the telemetry that let you measure it. The sequence that works:
- Amnesty first, and say so before the survey runs. Declaration must be safe or the survey returns noise.
- Sanction something fast. Inside two weeks there should be an approved tool that does most of what the popular shadow tool does. Adoption of the sanctioned path is what actually reduces the shadow, and nothing else does.
- Triage on data, not on tool. The question is not "is this tool approved" but "what has gone into it". A sanctioned tool handling customer records is a larger problem than an unsanctioned one summarising public documents.
- Restrict narrowly and last. Block the specific combinations you have decided are unacceptable, once there is somewhere else to go.
- Re-run discovery quarterly. This is not a project. The estate changes faster than the policy does, and bundled AI features arrive without anyone adopting anything.
Metrics that mean something
Counting discovered tools measures how hard you looked. Four measures that track the thing you actually care about:
| Metric | Definition | Why it is the right one |
|---|---|---|
| Sanctioned share | Proportion of observed AI usage going to approved tools | Rises when governance is working; blocking alone moves it the wrong way by pushing usage off-network |
| Time to sanction | Median days from a tool being requested to a decision | The direct cause of shadow AI. If this exceeds a few weeks, no policy will hold |
| Sensitive-context exposure | Count of AI tools with access to systems or data classed as confidential, whether sanctioned or not | The measure that maps to actual consequence rather than to tidiness |
| Survey–telemetry gap | Tools named by staff that no technical surface detected | A direct read on how much of your estate is invisible to you |
Report the second one to the executive who is asking about the first. Long approval cycles are the mechanism that generates shadow AI, and it is usually the only variable in the list that leadership can change directly.
What Agent Trust Cloud covers, and what it does not
Worth being exact about this, because shadow AI discovery is sold by a lot of products that each see one surface and describe it as coverage.
| Surface | Covered by |
|---|---|
| 1. Network egress and DNS | Your existing proxy, firewall or secure web gateway for the broad sweep — you already have those logs and nothing here replaces them. Discover also reads model API traffic, but for finding agents rather than for policing browsing |
| 2. OAuth grants and consents | Your identity provider. The consent report is already there |
| 3. Browser extensions | Endpoint or managed-browser policy. Again, already yours |
| 4. Local binaries and IDE plugins | Endpoint management for the inventory. Coding agent security covers what those assistants then do |
| 5. Spend | Finance. No tool needed, and it finds the largest single exposures |
| 6. Code and configuration | Discover and agent discovery — SDK imports, agent frameworks, MCP configuration, service principals |
Four of the six surfaces you can work today with tools you already pay for. That is the honest position, and the reason this page leads with a runbook rather than a product.
Where a product starts earning its place is the step after the list. A discovery exercise ends with a snapshot; the estate moves, and the agents that act are the ones a snapshot describes worst. Discover finds agents from model API traffic, AI keys, MCP configuration, SDK dependencies and automation credentials rather than from a survey, and carries ten lifecycle statuses from Discovered through Quarantined to Retired — so an agent has a state rather than only an entry.
If your discovery run turned up scheduled jobs calling model APIs with production credentials, that is the point at which this stops being a shadow-AI exercise and becomes an agent-governance one. The 90-day founding pilot is built around exactly that transition — and the Discover plan is free with no card if you would rather start by running the inventory yourself.
Where this stops being about tools
Discovery finds tools people use. The category it does not cover is the one growing fastest: agents that act.
A chat assistant that drafts an email is a data-exposure question. An agent holding an API key, with permission to write to a system of record, running on a schedule with no human in the loop, is an access-control and accountability question — and none of the six surfaces above tell you what it is allowed to do, only that it exists.
The two exercises have different endpoints. Shadow AI discovery ends with a list and a policy. Agent governance ends with an inventory that records what each agent can do, a permission model that constrains it, and evidence that the constraint held. If your discovery run turned up scheduled jobs calling model APIs with production credentials, you have finished the first exercise and started the second.
Common questions about shadow AI
What is shadow AI?
Shadow AI is the use of artificial intelligence tools or systems inside an organisation without the knowledge or approval of the people accountable for security, privacy and compliance risk. It includes consumer chat tools, AI features bundled into already-approved software, browser extensions, locally-run models and internally-built systems calling model APIs.
How do you detect shadow AI?
By combining six surfaces: network egress and DNS logs, OAuth application consents in your identity provider, browser extension inventory, installed local applications on managed endpoints, card and expense data, and repository and CI/CD searches for provider SDKs and API keys. Each has a blind spot, so none is sufficient alone.
Why can't network monitoring find all shadow AI?
Because it observes destinations rather than behaviour. Models run locally on a device produce no external traffic at all; AI features served from the same hostname as an approved product cannot be separated at the domain level; and once a provider is allowed, the tool stops flagging traffic to it regardless of what data is going there.
Is shadow AI the same as shadow IT?
No. Shadow AI has a lower adoption barrier, frequently arrives bundled into already-approved tools rather than as a new vendor, and is less reversible — deleting an account does not remove content that has already been used for training.
Should we block shadow AI tools?
Not as a first move. Blocking without a sanctioned alternative pushes usage onto personal devices, where no detection surface reaches it, so you lose visibility rather than risk. Offer amnesty, sanction a capable alternative quickly, triage by what data is involved, then restrict narrowly.
How often should shadow AI discovery be repeated?
Quarterly at minimum. The estate changes continuously, and AI features appear inside existing approved products without anyone adopting a new tool, so a point-in-time inventory is stale within a quarter even if no employee behaviour changes.