Five ways unregistered AI tools get discovered

Your organisation has more AI tools than its registry lists. That much is not controversial. The interesting question is how you find the gap, and every method available to you has a specific blind spot.

Run one method and you get a confident, incomplete answer. The incompleteness is the dangerous part, because a discovery report that looks thorough stops people looking.

Here is what each of the five practical methods sees.

1. Identity provider OAuth grants

What it sees: every third-party application a user has granted access to your Google Workspace or Microsoft 365 tenant, along with the OAuth scopes granted and which users granted them.

This is the highest-signal source available, and usually the first one worth turning on. It needs no network changes and no endpoint agent, just admin API access to the directory you already run.

What makes it valuable is not the app list. It is the scopes. An employee signing into a note-taking tool with Google is one thing. That tool holding https://www.googleapis.com/auth/drive is another. The scope tells you what the tool can reach, which is the actual risk, and no other method on this list gives you that.

It also hands you a handle you can act on. A Google OAuth client ID or an Entra service principal object ID is more than a record. It is the identifier you pass to the Admin SDK or Graph call that revokes the app’s access, so the scan that found the tool also hands you what you need to switch it off.

What it misses: anything that skips SSO. A developer pasting code into a personal ChatGPT account on a personal login is invisible here. So is any tool used without OAuth, which covers most consumer AI usage.

2. Device and MDM inventories

What it sees: applications installed on managed endpoints. A desktop AI assistant, a local model runner, an IDE extension that ships as an app bundle.

Tools like Hexnode give you installed-application inventories across managed devices. This catches a category the identity provider cannot see at all: locally installed software that never touches your SSO.

What it misses: everything in a browser. ChatGPT, Claude, Gemini and the meeting-notes tools are all reached through a browser tab, so an MDM inventory alone will make your shadow AI problem look far smaller than it is. It also misses unmanaged devices entirely, and that is exactly where the riskiest usage concentrates.

3. Endpoint detection telemetry

What it sees: process execution and network connections observed by your EDR agent, such as CrowdStrike Falcon.

Technically this is the richest source, because it sees processes and destinations rather than declared applications. It catches the CLI tool, the local model server, the script hitting an API directly.

What it misses: it needs an agent, so coverage equals agent deployment. It also produces the noisiest output of anything on this list. Endpoint telemetry will happily tell you that a browser connected to an AI domain, which is true and nearly useless without aggregation. Getting value out of this source is mostly a matching problem rather than a collection problem.

A purpose-built agent narrows that matching problem considerably, because it can filter on the endpoint instead of shipping everything and sorting it out centrally. UrNammu’s own endpoint agent takes this approach: it holds no tool list of its own, fetches an allowlist derived from the tools registry, and reports only what matches — so a hostname that is not a known AI tool never leaves the machine, and the output arrives pre-aggregated per tool rather than as raw connection noise.

It also picks up the one thing nothing else on this list can see. A model served from 127.0.0.1 by Ollama or LM Studio reaches no proxy, appears in no vendor admin API, and resolves no domain your DNS logs could catch. From the network’s point of view nothing happened at all, which is precisely why local inference tends to be absent from shadow AI reports that otherwise look complete.

4. DNS and proxy logs

What it sees: every domain resolved or requested from your network, regardless of device, application or identity.

This is the broadest net available. It does not care whether the tool uses SSO, whether it is installed, or whether an agent is running. If traffic left your network for an AI vendor’s domain, the log has it. Netskope, Zscaler, your firewall and your DNS resolver can all produce this.

What it misses: identity, usually. A DNS log gives you a domain and often a source IP. That tells you a tool is in use somewhere, but not who is using it or what they did with it. It also misses everything off the corporate network, which after several years of remote work is a great deal.

The matching problem here is the real work. A raw DNS log is hundreds of thousands of domains. Turning that into “twelve people are using an AI meeting-notes tool” needs a registry of known AI vendors and their domains. Vendors use far more domains than their brand name suggests. A single tool might resolve across its marketing site, its app subdomain, its API endpoint, its auth endpoint, and two CDN domains that look unrelated to any of them.

For reference, the tool registry underlying this kind of matching in UrNammu currently covers 164 known AI tools across 16 categories, each with its domain set, client-name patterns, publisher patterns and app-ID patterns. That is the unglamorous asset that makes a DNS feed usable. It also needs constant maintenance, because the vendor market moves weekly.

5. Self-reporting

What it sees: whatever people tell you.

Easy to dismiss, and worth keeping. Self-reporting catches the category no telemetry does: tools used on personal devices, on personal accounts, off the network. It is also the only method that gives you intent. Knowing what someone was trying to accomplish is what lets you offer a sanctioned alternative instead of just blocking them.

What it misses: everything nobody volunteers, which correlates strongly with everything you would most want to know. Self-reporting works as a complement to a credible detection programme and fails completely as a substitute for one. People report when they believe you will find out anyway and would rather be asked than caught.

The overlap is the point

Method	Identity	Scopes	Off-network	Browser tools	Actionable handle
OAuth grants	Yes	Yes	Yes	Yes	Yes
MDM inventory	Yes	No	Yes	No	No
EDR telemetry	Yes	No	Partial	Partial	No
DNS / proxy	Rarely	No	No	Yes	Domain only
Self-reporting	Yes	No	Yes	Yes	No

No row is complete. The combination is what gives you coverage, and running several sources creates a problem of its own. The same tool arrives from three directions with three spellings and three different user counts.

Deduplication decides whether anyone trusts the numbers

Your OAuth scan reports “Otter.ai”. Your DNS feed reports otter.ai and api.otter.ai separately. Your EDR reports a process named Otter. Left alone you have four entries for one tool, and your shadow AI count is wrong in a way that makes the whole report untrustworthy.

Useful deduplication needs three things.

A stable identity. Key tools on something durable, such as a normalised tool name plus its detected domain, so repeated scans update one record instead of creating new ones.

Fuzzy matching against a known-tools registry, with a confidence score. Not every observation matches cleanly. A match should carry a confidence level and the reasons behind it, so a reviewer can see why the system thinks oaiusercontent.com is ChatGPT rather than being asked to trust it.

Explicit handling of non-matches. The tools that match nothing in your registry are the most interesting findings you have. Either a novel tool, or a false positive. Either way they need a reviewer rather than silent discard. Candidates a reviewer has already dismissed should also stay dismissed, or every scan re-surfaces the same noise and the team stops reading the output.

The failure mode is a report whose tool count nobody believes. A reviewer spots two entries for Otter on the first page, and from then on every number in the document is treated as provisional.

Discovery is the easy half

Worth saying plainly. Turning on an OAuth scan and pointing a DNS feed at an ingest endpoint is about a week of configuration. Deciding what happens to the sixty tools it returns takes months, and there is no default setting for that part.

A discovered tool needs a workflow. Discovered, then under review, then registered, approved or blocked. Each of those terminal states has to mean something operationally. “Blocked” in a governance tool that does not sit in the network path is a label rather than a control. Making it real takes either a feed your network controls consume, or an identity-layer action that disables the app where users authenticate.

That is why the OAuth method earns its place at the top of this list. It is the only one that hands you both halves. It tells you the tool exists, and it gives you the application handle you need to do something about it.

---

The enforcement half is covered separately: the shadow AI blocklist feed and identity-provider app disabling, and how discovery findings map to NIST AI RMF and SOC 2 controls.