What to Look for in an Agent Discovery and Inventory Tool
A good agent discovery and inventory tool finds agents across cloud, code, endpoint and browser without anyone reconfiguring them or routing them through a proxy, attributes each agent to a named owner, records every tool and data source it can reach, and tracks how that changes over time. The quickest test is to compare what it finds against your own count, because the agents you didn't know about are the ones you're buying it for.
What should an agent discovery and inventory tool do?
It should find every AI agent your organization runs and keep an accurate record of each one, without the agents or their developers having to do anything for it. The first half is discovery and the second is inventory, and the difference between them is set out in AI Agent Discovery, Inventory and Posture Management.
Most tools in the category do some of this well, so the useful question during an evaluation is which agents a given tool will miss and why. The six criteria below are the ones that most often separate a tool that finds the estate from one that finds the agents you already knew about.
Does it cover cloud, code, endpoint and browser?
Agents run on all four surfaces, and a tool that reads only one or two will produce an inventory with a hole the shape of whatever it doesn’t read. Cloud-hosted agents in managed services and SaaS platforms, agents defined in code repositories and CI pipelines, coding agents and assistants on endpoints, and browser agents acting inside users’ sessions each leave different evidence, and each needs its own way of being read.
A coverage figure is only useful broken down by surface, together with an explanation of how each surface is read, because a tool built around one surface, whether the network, the endpoint or the cloud account, usually covers that surface thoroughly and describes the others as roadmap.
Does discovery require anyone to reconfigure their agents?
If an agent has to be registered, wrapped in an SDK, or pointed at the tool before it can be found, then the tool’s coverage depends on everyone having done that, which is exactly the assumption discovery is meant to test. The agents most likely to be skipped are also the ones you most need to find, such as a developer’s locally configured coding agent or a team’s unsanctioned automation.
Discovery that reads the configuration agents already have, in repositories, on machines and in cloud accounts, finds agents regardless of whether their owners cooperated. Ask what has to change about an agent for the tool to see it, and treat any answer other than “nothing” as a coverage dependency.
Does it work without a proxy or gateway?
A tool that discovers agents by watching traffic through a proxy or gateway sees the agents that route through it, and misses capabilities that produce no traffic at all. Skills, for example, are defined inside an agent’s configuration and grant a capability with no outbound call for a proxy to observe.
Proxy-based discovery can be adequate where every agent is a sanctioned service routed through infrastructure you control, but it adds a network hop to every call it observes, which is a cost worth paying for enforcement and harder to justify for an inventory. The trade-offs are covered in Do You Need a Proxy or Gateway to Secure AI Agents?, and the practical question for an evaluation is whether the tool can produce a full inventory in an environment where no traffic has been re-routed.
Does it attribute every agent to a named owner?
An inventory entry without an owner leaves nobody to act on it, so attribution is the field that turns a list into something a team can work from. The owner should be a person or team who is accountable for the agent, which is often different from the identity it runs under, because many agents act through shared service accounts or a user’s delegated credentials.
Ask how the tool decides ownership, what it does when the obvious signal (a commit author, the account that created the agent) points to someone who has left, and what share of agents in a trial came back with no owner. The entry on non-human identity vs agent accountability covers why a service account can’t stand in for an owner.
Does it record each agent’s tool and data reach?
What makes an agent risky is what it can act on, so a tool that lists agents without their tools, data sources and permissions answers the least important question first. Reach should include every capability type, meaning MCP servers, skills, plugins, extensions and SaaS connectors, as well as the data classifications each agent can read or write and whether it can take actions that can’t be undone.
The more useful tools also distinguish what an agent is configured to reach from what it uses in practice, which is the distinction that lets a team remove access nobody needs without breaking anything. The full set of capability types is laid out in Agent Capabilities and the Tool Supply Chain.
Does it track drift over time?
Agents change after they are found, as tools get connected, permissions widen and behavior moves away from the original brief one step at a time. An inventory that captures a snapshot is accurate on the day it is produced and less accurate every day after, so the tool should record when each agent’s tools, permissions and behavior last changed and surface changes that matter.
In an evaluation, that comes down to how quickly a new tool connection appears in the inventory, whether an agent’s history is visible alongside its current state, and whether the tool builds a baseline of each agent’s normal behavior, so that a change in what it does shows up as well as a change in how it is configured.
What should you ask each vendor?
Discovery tools tend to inherit their strengths and gaps from the place they were built to watch, which makes the approach a useful predictor of how a tool will score.
| Criterion | The question to ask | What a weak answer sounds like |
|---|---|---|
| Surface coverage | What share of agents did you find on each of cloud, code, endpoint and browser? | One surface reported in depth, the others described as planned |
| No reconfiguration | What has to change about an agent for you to see it? | Agents must be registered, wrapped in an SDK or pointed at the tool |
| No proxy | Can you produce a full inventory without re-routing any traffic? | Discovery depends on agents using a gateway |
| Owner attribution | How do you decide who owns an agent, and how many came back unowned? | Owner is the service account the agent runs under |
| Tool and data reach | Which capability types and data classes do you record per agent? | MCP servers only, with no data classification |
| Drift tracking | How soon does a new tool connection appear, and can I see history? | The inventory refreshes on a scheduled scan |
How do you test a discovery tool before buying it?
Write down how many agents you believe you run before the trial starts, using surveys, gateway logs and any existing register, then let the tool run on the same scope and compare the two.
The comparison is most useful agent by agent. A strong result is a list of agents you didn’t know about, each with an owner, its tools and the data it can reach, plus at least one agent whose access changed while the trial ran; a weak one is a larger number with nothing beneath it that anyone could act on. A large gap between your count and the tool’s is common, and the entry on discovery, inventory and posture management explains why surveys and gateway logs undercount. If the tool’s count matches yours exactly, that’s either reassuring or a sign it reads the same sources you already had.
Common questions
Which vendors provide AI agent discovery across cloud, code and endpoint?
We don't publish vendor comparisons, partly because coverage claims in this category move quickly and partly because a list tells you less than the six questions above. The categories that claim discovery include gateway vendors, endpoint vendors, cloud posture vendors extending into AI-SPM, and platforms built for agents specifically. Geordie, which publishes this Knowledge Center, discovers agents across cloud, code, endpoint and browser without a proxy, and these are the criteria we expect to be held to as well.
How long should agent discovery take?
Long enough to read every surface once, which for configuration-based discovery is minutes to hours rather than weeks. In one engagement first findings arrived ten minutes after connection. A tool that needs a multi-week rollout before it shows you anything is usually waiting on agents to be re-routed or registered, which is a coverage dependency as much as a schedule.
Do we need a discovery tool if we already have AI-SPM?
Possibly not, if your AI-SPM tool reads every surface your agents run on and records tools, owners and behavior rather than model and pipeline configuration alone. Many AI-SPM tools were built for static AI workloads, so check them against the same six criteria. The entry on AI agent posture management explains where the two overlap.
What should a proof of value for agent discovery include?
Agree on your own count before it starts, from surveys, gateway logs and any existing register, then compare it with what the tool finds on the same scope. Ask for the agents it found that you didn't know about, the owner it attributed to each, and one agent whose tools or permissions changed during the trial, since those three answers test discovery, attribution and drift in a single exercise.
