How to detect shadow AI

Write down the line. A useful definition is: any AI tool, model, agent or feature used for work that the organisation has not approved, or that touches data the approval does not cover. That includes obvious cases (staff pasting text into a public chatbot), and quieter ones: browser extensions with AI features, AI add-ons switched on inside tools you already pay for, meeting-notes bots, personal accounts of approved tools, and agents built by a team with an API key from a personal card.

Separate three questions, because they need different answers. Is the tool known? Is it approved? Is it used with data it is not approved for? An approved tool used on restricted data is a data problem, not a discovery problem. An unknown tool used on public marketing copy is a low-priority discovery item.

Agree the principles with data protection and, where you have them, employee representatives, before you start collecting. The aim is to find tools and data flows, not to read individuals' conversations. Say that in writing, and keep to it.

Many AI assistants ask you to "sign in with" your work account and request access to mail, files or calendars. Those requests leave a trail in your identity provider, which makes it one of the best places to look.

In Microsoft Entra, sign in to the Entra admin center as at least a Cloud Application Administrator, browse to Entra ID, then Enterprise apps, then All applications, pick an application and select Permissions. The Admin consent tab shows permissions granted for the whole organisation. The User consent tab shows what individual users or groups granted. Microsoft notes that you cannot revoke user-consented permissions in the portal; you use Microsoft Graph or PowerShell for that, and revoking does not stop users consenting again unless you change how consent is configured.

In Google Workspace, go to Menu, then Security, then Access and data control, then API controls, and select Manage App Access to see configured and accessed apps. For each app you can set it to Trusted, Limited, Specific Google data, or Blocked. Sort the list by number of users and by the scopes requested, and look at anything with access to mail, drive or calendar that you did not approve.

Record each app, who granted it, the permissions and the number of users. Do not revoke yet. First learn what people use it for, in step 5.

If you route traffic through a proxy, secure web gateway or firewall that logs destinations, you can match them against AI services. Microsoft Defender for Cloud Apps, for example, describes cloud discovery as analysing traffic logs against a catalogue of over 31,000 cloud apps, scored on more than 90 risk factors. It supports snapshot reports from logs you upload from firewalls and proxies, and continuous reports through endpoint integration, a log collector or a secure web gateway. It lists many supported firewalls and proxies, and notes that apps not in the catalogue cannot be discovered by default.

That last point matters for AI, where new services appear quickly. Whatever tool you use, keep your own list of AI domains, update it monthly, and treat a long tail of unknown domains with high upload volume as worth a look. If you have no discovery product, DNS or proxy logs filtered by that list will still give a first picture.

Look at aggregates first: which services, how many users, how much data uploaded. Resist the pull to look at individuals. If a service looks risky, ask the owning team what it is for before anyone looks at a name.

Search expense claims and card statements for AI vendors and subscription descriptors. Check procurement for tools bought by a department without a security review. Ask finance for recurring charges under a threshold, since small subscriptions are how many tools enter.

In cloud billing, look for model API services and GPU instances in accounts or projects outside your platform team. In code, search repositories for model-provider SDK imports and API base URLs, and for keys in config. A script that calls a model with a personal key is shadow AI that no network control will see from the inside.

Keep what you find factual: vendor, owner, monthly cost, and purpose if known. You are building a register, and a register is only useful if people trust that being in it is not a punishment.

Logs show tools. People tell you reasons. Run a short anonymous survey: which AI tools do you use for work, what for, what data do you put in, what would you need to stop using a personal account. Add two or three team conversations with heads of function.

Say clearly how the answers will be used. If people think a candid answer leads to discipline, they will under-report, and your data will be wrong in exactly the places that matter. An amnesty window, stated plainly, works better than a threat.

Compare the survey to the logs. Tools in the survey but not the logs show where your visibility is weak, such as personal devices or home networks. Tools in the logs but not the survey show where people have not realised the tool counts.

Give each tool a data rating: what is the most sensitive data staff put into it? Use your own classification. Add what you can learn about the tool: does it keep inputs, train on them, where is data processed, what contract is in place, which sub-processors does it use. Ask the vendor if the information is not public, and mark what you could not confirm.

Then decide. Approve tools with an adequate contract and low-risk use. Replace tools used on sensitive data with an approved alternative. Restrict tools that are fine for public content by saying what data may go in. Block only where there is a clear unacceptable risk and a workable alternative.

Handle the high-risk cases first: sensitive personal data, customer data, source code, credentials, regulated records. If a tool holds credentials or broad account access through an OAuth grant, treat revocation and a credential rotation as part of the response.

Shadow AI exists because the tool is useful and the official route is slow or missing. Blocking without an alternative moves the activity to personal devices, where you can see even less. For each common use case in your findings (drafting, summarising, coding help, translation, data analysis), name the approved tool and how to request access.

Publish a one-page policy in plain language: what is approved, what data may never go into an AI tool, how to ask for a new tool, and who to tell about a mistake. Give a fast review path for new tools, measured in days. If review takes months, people will not use it.

For tools you build yourselves, such as internal agents, the same rules apply through how to govern AI agents. For a company-hosted option, how to self-host a ChatGPT alternative shows one route.

Set a monthly review: new app grants since last time, new AI domains in traffic, new AI spend, and survey pulse results every quarter. Keep the output at the level of tools, teams and data types. Alert on high-risk patterns, such as a new app with broad mail or drive access, or a large upload to an unknown AI service, rather than on individuals' general browsing.

Be careful with monitoring that touches people. It may involve personal data and, depending on where you operate, employment rules and employee consultation. Involve your data protection contact and any employee representatives before you collect more than aggregate tool-level data, and document the purpose and retention. This guide is not legal advice.

Feed findings into your wider inventory. An AI system you have discovered is one you can now classify and govern, which is the starting point for the work in how to prepare for the EU AI Act and how to audit AI systems.