What Is Agent Discovery?

TL;DR

Most enterprises can list every laptop they own and cannot list every agent acting on their behalf. That gap is what agent discovery closes: identifying every agent running across the company, wherever it came from and however it got there.

Agents don't arrive through one governed door the way hardware does. A team spins one up from a chat window in an afternoon, or a SaaS tool ships an assistant that's already switched on. A single OAuth click hands a vendor's agent standing access to a mailbox. None of that shows up on a device inventory, and nobody has to ask permission first.

We think the real mistake is treating discovery as a one-time audit instead of the layer everything else stands on. Permissions, credentials, ownership, retirement: none of it is answerable for an agent nobody has found yet.

This isn't about slowing anyone down before they're allowed to build. It's the difference between adopting agents with your eyes open and finding out what you built only after something forces it into view.

Overview

Every enterprise has a process for finding out what hardware it owns and what SaaS licenses are live. Almost none has an equivalent process for agents, and the two are converging fast: a team can stand up an autonomous system with less friction than ordering a laptop, and without anyone in procurement noticing either way.

That asymmetry is where this post starts. Agent discovery is the process of identifying every AI agent operating across an enterprise: agents built internally, installed from third-party platforms, embedded inside SaaS tools, or connected to enterprise systems through APIs, OAuth grants, service accounts, or a single employee's permission click.

It sits underneath every other layer of Agent Operations. Monitoring an agent, restricting its permissions, rotating its credentials, retiring it cleanly: each of those assumes someone already knows the agent exists. Discovery is what makes that assumption true.

What Counts as an Agent

Traditional IT discovery tracks physical and digital assets: laptops, servers, SaaS applications, cloud resources, user accounts. Those programs are mature because the things they track sit still long enough to be counted.

Agent discovery has to track something that doesn't sit still. The thing on the other end isn't a device or a static account, it's an actor: a system that reads data, calls tools, and takes action with a human somewhere between "reviewing every step" and "nowhere near it." A laptop is interesting because it exists. An agent is interesting because of what it can do, which is why "this machine runs in this region" is a complete inventory record and "this agent can read the customer table" is barely a start.

That's the test worth applying before anything else gets built out. Not every automated script is an agent, and treating a deterministic cron job as though it needs the same scrutiny as something that decides its own next step burns the scrutiny you actually need elsewhere.

Figure 1 — What actually puts a system in scope for agent discovery. Reach and autonomy decide the answer, not how the thing was built.

We'd rather see a team over-count here than under-count. Reviewing a script that turns out to be harmless costs an afternoon. Missing the one that wasn't costs a lot more, and it's the reason the boundary above leans toward "track it" whenever the answer is close.

Questions Discovery Should Answer

A discovery program is only as good as the questions it can answer about any agent on demand. At minimum, it should produce a clear response to each of the following:

• Which agents exist? The complete population, not just the ones a single team remembers.
• Who created them? The team or individual that brought the agent into existence.
• Who owns them? The accountable party today, which is often not the person who built it.
• What tools are they connected to? The systems, APIs, and integrations the agent can call.
• What data can they access? The records, files, and datasets within reach of those connections.
• What actions can they perform? The difference between reading information and changing it.
• Have they been reviewed? Whether the agent went through any oversight at all.
• Are they still active? Whether the agent is in use, dormant, or quietly abandoned.

If an organization cannot answer these for a given agent, that agent is effectively invisible: running with real access and no oversight.

Where Agents Hide

The reason discovery is hard is that agents don't arrive through a single, governed front door. They show up across the enterprise, usually through ordinary, well-intentioned work:

• An HR team stands up an internal agent to answer policy questions, granting it read access to the employee handbook and the leave-balance system.
• A finance analyst connects an agent to the close process so it can pull ledger entries and draft variance commentary each month.
• A procurement group authorizes an assistant to read supplier contracts and flag renewal dates buried in the contract repository.
• A data team deploys an agent that runs queries against the warehouse and posts summaries into a shared analytics channel.
• A marketing tool ships an embedded assistant that, once enabled, can reach campaign data, customer lists, and the email platform.
• A third-party meeting assistant receives an OAuth grant from a single employee and gains standing access to calendars, transcripts, and documents.

Each of these is reasonable on its own. The problem is the aggregate. No two arrived the same way, none was registered centrally, and most are unknown to security and IT. They aren't malicious. They're simply unseen, and an agent nobody can see is one nobody can govern, audit, or switch off.

None of this is hypothetical in the way it sounds. A finance-close agent carries write context that could touch financial reporting. A meeting assistant inherits a person's access without anyone reviewing it first. When ownership is unclear and access is broad, a small mistake propagates quietly, right up until something forces it into view.

Discovery in Practice

Because agents enter through so many channels, discovery cannot rely on a single source. It works by correlating signals that already exist across the enterprise and resolving them into a single picture of each agent.

In practice, that means looking in the places agents leave traces:

• Identity providers: OAuth grants, consented applications, and service accounts that reveal who authorized what.
• SaaS admin consoles: embedded assistants and AI features quietly enabled inside tools the company already pays for.
• Cloud and API gateways: keys, tokens, and traffic patterns that indicate an automated actor rather than a person.
• AI platforms and agent builders: internally created agents living inside the platforms teams use to build them.
• Code and configuration: agent definitions, connection strings, and credentials checked into repositories.

Consider a concrete reconciliation. An IT operations team finds a service account making frequent calls into the ticketing system at odd hours. On its own, that's just anomalous traffic. Correlated with an OAuth grant in the identity provider and an agent definition in an internal builder, it resolves into a clear entity: an internal triage agent, created by one engineer, owned by no one currently, still active, and connected to the full ticket queue.

That's what discovery produces: not an alert, but an identified agent with an owner, a scope, and a status. The goal is to turn scattered, ambiguous signals into a confident answer to the question the enterprise started with.

The First Layer of Agent Operations

Discovery is foundational because every later capability assumes it. You cannot restrict permissions on an agent you haven't found. You cannot rotate the credentials of an agent you can't name. You cannot maintain an audit trail, assign accountability, or decommission cleanly without first knowing the agent is there.

This is why discovery comes first. It's the input to the inventory, the permission model, and the audit trail that follow. Skip it, and every downstream control is built on an incomplete map.

We don't think discovery should work as a gate teams have to clear before they're allowed to build. It's a lens that makes whatever they're already building visible, governable, and safe, so the organization can encourage agent adoption with confidence rather than discovering its exposure after an incident.

Conclusion

Agents are spreading through the enterprise faster than most governance programs were designed to handle. They arrive through HR portals, finance workflows, procurement tools, data pipelines, and a single employee's OAuth click. Each is reasonable on its own; together they form a population no one has fully counted.

Agent discovery is how that population becomes knowable. It identifies the agents, names their owners, maps their reach, and marks which have been reviewed and which haven't. It's the starting point for everything else in Agent Operations.