What Is Agent Discovery?

Overview

Every enterprise has a process for finding out what hardware it owns and which SaaS licences are live. Almost none has an equivalent 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.

Agent discovery is the process of identifying every AI agent operating across an enterprise: agents built internally, installed from third-party platforms, embedded in SaaS tools, or connected to enterprise systems through APIs, OAuth grants, service accounts, or one 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 assumes someone knows the agent exists. Discovery is what makes that assumption true. The standards bodies agree on the ordering. The NIST AI Risk Management Framework's playbook puts it as a governance subcategory in its own right: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities", with the suggested actions describing an organized database of artifacts that can answer both a specific question and a portfolio one, right down to "how many models are currently deployed?"

Two Things Called Discovery

Search for agent discovery and you get two answers that share no machinery.

The first is protocol discovery, and it is genuinely specified. An A2A agent publishes an Agent Card at https://{agent-server-domain}/.well-known/agent-card.json, using the path prefix RFC 8615 reserved in May 2019 for "well-known locations". The card carries identity, capabilities, skills, a service endpoint and authentication requirements, and a client that authenticates may receive an extended card with "additional skills, capabilities" not in the public one. A2A names two other mechanisms beside it: curated registries, "employed in enterprise environments or public marketplaces, where Agent Cards are often managed by a central registry", and direct configuration for tightly coupled systems.

MCP's equivalent is a request rather than a file. server/discover "lets a client query a server's supported protocol versions, capabilities, and identity before sending any other requests", and servers MUST implement it. There is also an official registry, "a community driven registry service for Model Context Protocol (MCP) servers", which stores metadata rather than hosting anything and organizes it under namespaces such as io.github.owner/name whose ownership has to be proven through GitHub authentication or domain validation.

All of that is useful and none of it is a census. Protocol discovery finds endpoints that want to be found, and it describes them in their own words. Two lines in the specs make the limit explicit. RFC 8615 says it "does not define a format or media type for the resource located at '/.well-known/', and clients should not expect a resource to exist at that location". And MCP's discovery response warns that serverInfo is "self-reported by the server and is not verified by the protocol", telling clients they SHOULD NOT rely on it for security decisions.

So the second meaning, the one this page is about, is the enterprise census: the population of agents acting on the company's behalf, assembled from evidence rather than from self-description.

What Counts as an Agent

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

Agent discovery tracks something that does not sit still. The thing on the other end is an actor: a system that reads data, calls tools, and acts 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.

Apply the test before building anything out. Not every automated script is an agent, and treating a deterministic cron job like something that decides its own next step burns the scrutiny you need elsewhere.

Figure 1 — What puts a system in scope. Reach and autonomy decide it, not how the thing was built.

We would rather a team over-count here than under-count. Reviewing a script that turns out to be harmless costs an afternoon. Missing the one that was not costs more, which is why 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 on demand about any agent:

• Which agents exist? The complete population, not the ones one team remembers.
• Who created them? The team or person that brought the agent into existence.
• Who owns them? The accountable party today, 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 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? 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.

Two of those questions now carry a deadline. The EU AI Act requires high-risk systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system" under Article 12, and Article 26(6) puts a duty on deployers to keep those logs "for a period appropriate to the intended purpose" of at least six months. The published implementation timeline places the Annex III high-risk obligations at 2 December 2027. An agent nobody found is an agent whose logs nobody is retaining.

Where Agents Hide

Discovery is hard because agents do not arrive through one governed front door. They show up through ordinary, well-intentioned work:

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

Each is reasonable alone. The problem is the aggregate. No two arrived the same way, none was registered centrally, and most are unknown to security and IT. They are not malicious. They are unseen, and an agent nobody can see is one nobody can govern, audit or switch off.

The last item on that list is the one worth dwelling on, because it is the cheapest path to standing access in any enterprise and it leaves a precise trace. Google Workspace's admin audit log has a token event set whose authorize event fires when "a user authorized access to an application for their data", rendered in the console as "{actor} authorized access to {app_name} for {scope} scopes". The same event family carries activity, deny, request and revoke, with parameters including client_id, client_type, scope, api_name and method_name. One click, fully logged, and almost never read.

Discovery in Practice

Because agents enter through many channels, discovery works by correlating signals that already exist and resolving them into one picture per agent. The useful shift over the past year is that identity providers started modelling agents as first-class, which turns a heuristic into a query.

Microsoft Entra is the clearest example. Its sign-in logs come in four types, interactive user, non-interactive user, service principal and managed identity, and agent activity is now stamped on top of them. An agentSignIn event type carries properties about the agent, and because agents can sign in with user-delegated or app-only permissions, "their sign-ins might appear across each of the four sign-in log types". In the audit log, agent activity is logged under the base identity type it originates from, and an agentType property marks it: notAgentic, agenticApp for a blueprint, agenticAppInstance for a running instance, agentIdentityBlueprintPrincipal, and agentIDuser for an agent's own user account. The rule is a one-liner: "A value other than notAgentic indicates agent involvement." A blueprintId correlates an instance back to its template, the way a service principal relates to an app registration. That blueprint-versus-instance split is the one the Agent Access Control Taxonomy draws between aact:identity-model/per-agent-identity and aact:identity-model/per-instance-identity, so a discovery record should say which of the two it found.

GET https://graph.microsoft.com/beta/auditLogs/signIns
  ?$filter=signInEventTypes/any(t: t eq 'servicePrincipal')
    and agent/agentType eq 'AgentIdentity'

Two operational notes on that query, both from the documentation. It runs on the /beta endpoint. And to get the agentIdentityBlueprintPrincipal and agentIDuser values back at all you have to send Prefer: include-unknown-enum-members, because they are members of an evolvable enumeration. A discovery job that omits the header silently under-reports a whole class of agent.

Table 1 — Six signals, what each one is evidence of, and the gap each one leaves.

GitHub's own listing is a good reminder that permissions are part of the record rather than a separate lookup. The documentation for listing installations for the authenticated app notes that "the permissions the installation has are included under the permissions key" and that "you must use a JWT to access this endpoint". Per-organization and per-repository variants exist for narrowing.

Consider a concrete reconciliation. An operations team notices a service principal calling the ticketing system at odd hours. Alone, that is anomalous traffic. Filter the sign-in log for agentType other than notAgentic, pull the blueprintId, match it against an agent definition in an internal builder, and correlate with the consent recorded in the token log, and it resolves into an entity: an internal triage agent, created by one engineer, currently unowned, still active, connected to the full ticket queue.

correlate on client ID / blueprint / GitHub /app/installations (permissions) ------/ service account Builders, registries, repositories ----------/ | v identified agent: owner, reach, status, reviewed yes/no -->

Figure 2 — Discovery output is not an alert. It is a named agent with an owner, a scope and a status.

What Discovery Cannot See

Being honest about the blind spots is what keeps a discovery program credible, and the largest one is architectural rather than a matter of effort.

An MCP server running over stdio on a developer's machine produces no identity record anywhere. The authorization specification is explicit that implementations using stdio "SHOULD NOT follow this specification, and instead retrieve credentials from the environment". No token is minted by your authorization server, no consent is recorded, and nothing appears in a sign-in log. The credential is an environment variable, a aact:credential-model/static-secret-in-agent arrangement that leaves nothing to query. The only signals left are endpoint telemetry and whatever the developer checked into a repository.

Three smaller gaps are worth planning around. Self-description cannot be trusted, because serverInfo is unverified by the protocol and tool annotations are, in the specification's words, to be treated as untrusted unless they come from trusted servers. Retroactive visibility is limited, since a grant made before you started collecting the token log leaves only its consequences. And enumerations move: the Entra values above sit behind a beta endpoint and a request header today.

None of this argues against the census. It argues for stating coverage as a number. "We can see every agent that authenticates through the tenant, and we cannot see locally-run MCP servers" is a defensible position. "We have full visibility" is not.

The First Layer of Agent Operations

Discovery is foundational because every later capability assumes it. You cannot restrict permissions on an agent you have not found, rotate credentials for one you cannot name, or maintain an audit trail, assign accountability and decommission cleanly without knowing the agent is there. It is 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 do not think discovery should work as a gate teams clear before they are allowed to build. It is a lens that makes whatever they are already building visible and governable, so the organization can encourage adoption with confidence rather than learning its exposure after an incident.

Where Fabriq Fits

Agentic Fabriq is not a discovery scanner, and a post on discovery should say so. What it changes is what there is to discover. Connections and credentials are held per user in a vault and attached server-side at the moment of the call, so an agent never holds the secret. Every call carries two identities, the agent and the acting user, and an agent's effective tool list is the intersection of the user's scopes and the agent's. Calls land in an audit record you can filter, which is the difference between an agent you found and an agent you can account for.

The honest limit, since discovery often ends in a request to cut something off: clearing a vault copy of a credential is not the same act as revoking the grant upstream. That call still has to be made at the provider.

Frequently Asked Questions

What is agent discovery? The process of identifying every AI agent acting on an organization's behalf, whatever built it and however it got there. It is distinct from protocol-level discovery such as an A2A agent card or an MCP server/discover call, which only surface endpoints that publish themselves.

How do I find the AI agents already running in my company? Start with logs you keep. Filter Entra sign-in and audit records for an agentType other than notAgentic, read the Google Workspace token audit log for authorize events and the scopes each one granted, list your GitHub App installations with their permissions key, then walk SaaS admin consoles for assistants switched on by default.

Is agent discovery the same as an agent inventory? No. Discovery finds agents; the inventory is the maintained record it feeds. Registry and inventory distinctions are covered separately in this series.

Can discovery be done from logs alone? Mostly, for anything that authenticates centrally. It cannot see an MCP server run over stdio on a laptop, because the authorization spec directs those to take credentials from the environment rather than from your authorization server.

How often should discovery run? Continuously for the log-derived signals, since a new OAuth grant is a single click, and on a review cadence for the correlation and ownership work. A quarterly audit will be stale the week after it finishes.

Does the EU AI Act require an agent inventory? It does not use that word. It requires automatic event logging over a high-risk system's lifetime under Article 12 and at least six months of log retention by deployers under Article 26(6), which you cannot satisfy for systems you have not identified. NIST's AI RMF is more direct, making inventory mechanisms a governance subcategory.

What does discovery find that SaaS management tools miss? Reach. A licence record says a tool is paid for. A discovery record says which agent inside it can read the customer table and whose authority it uses to do so.

Conclusion

Agents are spreading through enterprises faster than most governance programs were designed to handle. They arrive through HR portals, finance workflows, procurement tools, data pipelines and one employee's OAuth click. Each is reasonable alone; together they form a population nobody has counted.

Agent discovery is how that population becomes knowable. The protocol layer helps with the cooperative part, publishing a card at a well-known path or answering a discovery call. The census is yours to assemble from the records you already hold, and the fields to query are documented: an agentType on an Entra record, a scope list on a Workspace authorization, a permissions key on a GitHub installation. Resolve those into named agents with owners, state your coverage honestly, and you have the starting point for everything else in agent operations.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — stable ids for the facts a discovery record has to carry, including the identity-model terms that separate an agent definition from a running instance.
• Microsoft Entra Agent ID logs — the agentSignIn event type, the agentType enumeration, blueprintId correlation, the Graph beta filter query, and the Prefer: include-unknown-enum-members requirement.
• Sign-in logs in Microsoft Entra ID — the four sign-in log types and the note that log entries are system generated and cannot be changed or deleted.
• Token audit activity events, Google Workspace Admin SDK — the authorize, activity, deny, request and revoke events and the client_id, scope, api_name and method_name parameters.
• GitHub REST API, Apps — GET /app/installations and the per-organization and per-repository variants, with permissions returned under the permissions key.
• A2A Protocol: Agent Discovery — the /.well-known/agent-card.json path, curated registries in enterprise environments, and direct configuration.
• A2A Protocol: Specification — what an Agent Card carries, and authenticated extended cards returning capabilities absent from the public card.
• RFC 8615: Well-Known Uniform Resource Identifiers — the reserved /.well-known/ prefix and the caution that clients should not expect a resource to exist there.
• MCP specification, Discovery (2026-07-28) — server/discover as a mandatory RPC, and the warning that serverInfo is self-reported and unverified.
• MCP specification, Authorization (2026-07-28) — the direction that stdio implementations should retrieve credentials from the environment instead of following the authorization flow.
• Official MCP Registry — a metadata catalog with verified namespaces such as io.github.owner/name.
• NIST AI RMF Playbook, GOVERN 1.6 — inventory mechanisms as a governance subcategory, and the portfolio questions an inventory should answer.
• EU AI Act Article 12, Record-Keeping — automatic recording of events over the system's lifetime.
• EU AI Act Article 26, Obligations of Deployers — the six-month minimum log retention and the Annex III timeline.