How to discover AI agents in an enterprise.
Agents do not announce themselves, and software inventory does not find them, because most of them are not installed software. They are credentials granted to something that acts. So you follow the credentials.
- Software inventory does not find agents. Most are an OAuth grant, a config file or a CI step rather than an installed binary.
- Follow credentials, not software. Four trails cover most of what exists.
- Expect the first pass to be incomplete, and expect the count to be higher than anyone guessed.
- Discovery without ownership is a list nobody acts on. Assign owners as you go, by reach.
Published Last reviewed
Four trails, in order of yield.
Finish each one before opening the next. Partial coverage of four sources is worse than full coverage of two.
Google Workspace third-party app access and the OAuth token audit log, Microsoft Entra ID enterprise applications and consent events. This is where employee-installed AI tools show up, with their scopes and the person who approved them. It is the highest yield per minute of any source.
MCP configuration the clients read, and the same files inside repositories. These give you the agent and its credential together, because the token is usually in the env block of the same file.
Search workflow files for AI CLIs and note which secrets each step receives. A step that only reviews code but holds a deploy token is a discovery and a finding in one.
Cloud audit logs record the user agent and source of each call. A long-lived key suddenly calling from an AI SDK or a notebook host is an agent nobody registered. Model provider billing is the same signal from the other side.
What each trail misses.
The misses column is why no single source is enough, and why the overlap between two sources is itself informative.
| Trail | What it returns | What it misses |
|---|---|---|
| OAuth consents | Employee-installed AI tools, their scopes and approvers. | Anything running on a service account. |
| Config files | MCP servers and the tokens beside them. | Agents configured only in CI. |
| CI workflows | Agents in pipelines and the secrets they receive. | Anything on a laptop. |
| Key usage | Agents reusing existing credentials. | Anything that has not run recently. |
How to run it. Four steps.
Designed to produce something usable after the first source, not after the fourth.
Whichever system you already have admin access to. Momentum matters more than starting with the theoretically best source.
Empty is allowed. Missing is not. An entry with no owner is the output, not a failure of the method.
Twenty agents reading a wiki rank below one with a production role. Do not work the list in the order it came out of the export.
Discovery is not a project. The difference between two runs tells you more than either run alone.
Questions, answered.
Short answers on how to discover ai agents.
Why does software inventory not find AI agents?
Because most agents are not installed software. An OAuth grant to a SaaS AI tool, an MCP server started by a config entry and a CI step calling an AI CLI are all agents with real access, and none of them appears in an endpoint software list.
What is the fastest way to find the most agents?
OAuth consent logs, in most organisations. They cover the tools employees connected themselves, which is the largest and least governed group, and they come with scopes and an approver attached.
How many agents should we expect to find?
More than anyone estimates beforehand, and that is the useful part of the exercise rather than a number worth quoting. Published ratios vary so widely between vendors that a count from your own environment is the only one worth planning against.
See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.