Every agent registry has the same weakness: it contains the agents somebody told it about. The agent quietly filing tickets from a Salesforce sandbox, the Bedrock prototype that graduated to production without a name — those are the entries that matter most and volunteer least.
Agent discovery is the craft of finding them. Not as a one-time audit, but as a standing capability that keeps the AI agent registry honest. In practice it runs on three signals, in descending order of yield, followed by one reconciliation step that turns raw findings into a governed inventory.
Signal one: the platforms' own registries
The highest-yield discovery move is also the least glamorous: read the registries that already exist. Azure AI Foundry, AWS Bedrock, Google Vertex AI, Salesforce and ServiceNow each keep a list of the agents built on them. The platform knows — it has to, it runs them. What the enterprise lacks is not the data but the aggregation.
That is a connector job. The Kosmoy Agents Master Registry attaches to each of those five platforms, reads that platform's own registry, and pulls every agent into one master list — provider, model, owner and type on each record, kept in sync within what the platform exposes, alongside the agents built and run in Kosmoy itself. Platforms with no usable API get their agents registered manually and tagged as manual, so the blind spot is at least a labeled blind spot.
One habit worth stealing: diff the harvest. The interesting result is not the list — it is the delta between this week's list and last week's, because that delta is your agent creation rate, and it tells you how often discovery needs to run.
Signal two: gateway traffic
Platform registries show you agents where agents are supposed to live. Gateway traffic shows you agents where work actually happens.
If your LLM, MCP and agent-to-agent calls route through a gateway, every caller identifies itself to get service — which makes the gateway log a census. An application ID nobody recognizes, making model calls with tool invocations in the pattern, is not noise. It is an agent someone built, announcing itself on every request.
The same log answers the follow-up questions a registry entry needs: which models the unknown caller uses, which tools it invokes, roughly what it spends. Half the agent card writes itself from traffic you were already logging.
Be honest about the boundary of this signal: a gateway sees only what routes through it. An agent calling a model provider directly, from a laptop or a hyperscaler runtime, is invisible here — which is exactly why gateway traffic is a signal in a discovery program and not the whole program.
Signal three: SSO and application logs
The third signal finds agents before they are agents. Your identity provider logs every sign-in to every sanctioned tool — including the agent builders. A cluster of sign-ins from one finance team to an agent-building studio is a leading indicator: somebody is building, and nothing with that team's name is in the registry yet.
Application and admin logs on the SaaS side tell the same story from the other end — who created what, in which workspace, connected to which data. None of this requires new surveillance; it is reading logs you already retain, with a new question in mind.
Treat this signal as a conversation starter, not a citation. "We saw the team trying the agent studio — want help registering what you're building?" lands very differently from a compliance ticket, and it recruits the next self-report instead of preventing it.
Reconciliation: the match that makes it discovery
Three signals produce a pile of findings. Reconciliation turns the pile into an answer.
The comparison is two lists. On one side, the approved use-case registry: the AI that went through your approval flow. On the other, the harvested reality: every agent the signals surfaced, across every connected platform. Agents that match are recorded and monitored. Agents that do not match are your shadow AI — flagged and routed to review.
Run the match continuously, not annually. Shadow AI is not a scandal to be exposed once; it is a steady byproduct of teams moving fast, and the registry's job is to keep the unmatched queue short.
What to do with a found agent
The found agent is where discovery programs either mature or poison themselves.
The wrong move is the reflexive takedown. Most shadow agents are legitimate work that skipped a step — a business unit solving a real problem on a sanctioned platform, minus the paperwork. Kill it on sight and you have taught every team in the company to build quieter.
The right move: the agent becomes a registry entry under review, and it enters the same operating loop as everything built in-house — at step one, register and classify. Assign an owner. Classify the risk. Register the use case it actually serves — or retire the agent if nobody will stand behind it. The business unit keeps the platform it chose; the enterprise gets the accountability it was missing.
From there the found agent is just an agent: classified, assessed, monitored, and producing the same audit evidence as its officially sanctioned siblings. Discovery's success metric is not how many agents it catches — it is how boring the catch becomes.
Discovery never finishes
New platforms ship agent builders every quarter, and every new builder is a new place for agents to appear unannounced. That is why discovery is a capability, not a project: connectors harvesting on a schedule, gateway and SSO signals reviewed on a cadence, the unmatched queue triaged weekly.
If you are standing this up from zero, sequence it inside a broader first month — the week-by-week version is in AI Agent Inventory: How to Build One in 30 Days. Registries begin with what people remember. Discovery is what makes them converge on what is true.
Frequently asked questions
What is agent discovery? Agent discovery is the process of finding every AI agent running in an organization, including the ones nobody registered. It combines reading the agent registries of the platforms where agents are built, watching gateway traffic for callers that are not on the list, and mining SSO and application logs — then reconciling what it finds against approved AI use cases.
What signals reveal unregistered AI agents? Three, in order of yield. Platform registries: Azure AI Foundry, AWS Bedrock, Google Vertex AI, Salesforce and ServiceNow each keep a list of the agents built on them. Gateway traffic: unknown applications making model or tool calls through your gateway are agents someone built. SSO and app logs: sign-ins to agent-building tools reveal teams building before they register.
Should you shut down a shadow agent when you find it? Not by default. Most shadow agents are legitimate work that skipped a step, and takedowns teach teams to hide better. A found agent becomes a registry entry under review: assign an owner, classify the risk, register the use case — or retire it if nobody will own it. It enters the same governed lifecycle as everything built in-house.