By Nolan Sullivan, Founding Growth Engineeragent discovery
Agent discovery is the continuous process of finding every AI agent in an organization that is not yet in the inventory: the coding agents on endpoints, the SaaS copilots signed in with corporate identity, the internal orchestrators, and the unsanctioned MCP wiring none of those registers know about. Each finding becomes an inventory record with an owner and a disposition.
Agent discovery exists because every register the organization already keeps stops one layer short of the agent. The device register and the software list agree that Alice has Cursor installed on a company MacBook. Neither says that her session talks to a local GitHub Model Context Protocol (MCP) server authenticated with a personal access token, or that a payments intern stood up a Claude project that can call create_refund against production. Both of those agents hold credentials and reach, and neither appears in anything the security team can query.
The Cloud Security Alliance built its April 2026 research note, The AI Agent Governance Gap: What CISOs Need Now, on the observation that organizations cannot govern what they cannot see, and made establishing an agent inventory its first immediate action for CISOs. The same note cites the Cybersecurity Insiders 2026 CISO AI Risk Report, in which 92% of 235 large-enterprise CISOs and CIOs said they lack full visibility into their AI agent identities. The sanctioned half of that inventory can be assembled from procurement records and admin consoles. Discovery is the process that fills in the other half, and it is the part of the program that existing tooling does not already do.
Why can’t MDM, a CMDB, or a SaaS admin console find AI agents?
Each of those systems sees a real slice of the picture, and the agent falls between the slices.
- MDM and the software asset scan see installed applications, so Cursor and Claude Code show up. But what gives an agent reach lives in configuration rather than in software: an MCP server is a few lines of JSON in a dotfile such as
~/.cursor/mcp.json, and a skill is a markdown file in a project directory. MDM confirms the harness exists and says nothing about which MCP servers that harness is wired to, which identity the session runs as, or whether anyone approved the result. - The CMDB records things the organization possesses. An agent is a principal, an actor that authenticates and takes actions, and a principal is the kind of object a CMDB was never designed to hold. What is an agent inventory covers that mismatch in full.
- The SaaS admin console sees seats in its own tenant. The ChatGPT Enterprise console lists its users and the Copilot dashboard lists its own. Neither sees the other, and neither sees anything running on an endpoint or inside a homegrown orchestrator.
Discovery is the process that works across those blind spots, and three signal sources do most of the work: hooks on the endpoint, traffic on the gateway path, and detection of the servers outside both.
Is agent discovery the same as shadow AI?
No. Shadow AI is the population: the AI in use inside an organization that no one with a security mandate has seen. Agent discovery is the method that surfaces it, and the method covers more than the shadow population, because sanctioned agents found through MDM enrollment or an identity provider are discoveries too, until each has a record and an owner. What is shadow AI owns the detection architecture end to end, from hooks at the client to MDM provisioning, and this section will not repeat it. Discovery is the narrower job of producing findings, wherever they come from, and routing each one into the register. The related register of tools, which MCP servers exist and what each exposes, is an MCP inventory, typically maintained by an MCP gateway rather than by discovery.
How do agent hooks discover agents on the endpoint?
Agent hooks are user-defined handlers that coding agents such as Claude Code and Cursor fire on every prompt and tool call. They were adopted as a control point, a place to block a dangerous command or strip a secret before it leaves the machine, but they double as a discovery instrument, because a hook runs inside the session and can report what that session is actually wired to: the MCP servers in the config, the skills that are loaded, and the identity the agent is running as.
That position matters most for local stdio servers. A stdio MCP server runs as a child process of the agent and never touches a corporate network, so no firewall log, proxy, or SaaS audit feed will ever record it. The hook is the one sensor that sits where that class of server lives.
How does an MCP gateway turn ordinary traffic into discovery?
When agents reach tools through an MCP gateway, every session and every tool call passes a point that can record it. Nobody runs a census of the sanctioned population: an agent registers as a side effect of being used, the servers it connects to register with it, and the last-seen field on each record maintains itself from traffic instead of from a survey.
The limit is scope. A gateway sees the traffic on the path it fronts, so it discovers the sanctioned half of the population and keeps the tools register current. The unsanctioned half is, by definition, not routing through it, which is what the endpoint and detection feeds are for.
How does shadow MCP detection find the servers nobody approved?
When the agents themselves are instrumented, through hooks or a managed client, a connection to an MCP server outside the sanctioned setup shows up in the same feed as the governed traffic, and each sighting carries enough to act on: the server’s URL, its host, and the identity the session ran as. OWASP tracks the underlying risk as MCP09:2025, Shadow MCP Servers, unapproved deployments of MCP servers operating outside formal security governance.
This feed is the discovery half of the shadow AI problem. The full architecture behind it, hooks at the client, a control plane for the events to land in, and MDM to provision the sensors across a fleet, is described in what is shadow AI.
Can identity providers and SaaS admin consoles feed discovery?
They can, as a complementary feed for the sanctioned SaaS agents. The identity provider knows which users have authenticated to the ChatGPT Enterprise tenant, to Microsoft Copilot, or to Gemini, and the admin console of each of those products lists its seats. Pulled into the same pipeline, those records give the inventory its sanctioned SaaS population without anyone filing a form.
Two caveats keep this feed in its place. The records arrive as user lists rather than agent records, so each one still needs an owner and a disposition assigned as it lands. And the feed only covers products the organization already knows about, which is why it complements the endpoint and traffic feeds rather than replacing them. This is architecture an organization can assemble from systems it already runs; the feeds that require agent-side instrumentation, hooks, gateway traffic, and shadow MCP detection, are the harder part to build yourself.
What does a discovery finding become?
A finding that stays an alert is discovery wasted. The handoff that gives it value is into the agent inventory: each discovered agent becomes a record carrying the identity it runs as, a human owner, the tools and data it reaches, and a sanctioned status. The full field list, drawn from the CSA note, is on the inventory page.
The disposition is the step that makes discovery a governance process rather than a monitoring feed. Someone accountable decides what happens to the finding: sanction the agent and move it onto the governed path, scope it down, or revoke it. The same handoff applies to sanctioned findings. An agent that arrived through MDM enrollment or the IdP feed is still only a discovery until it has a record and an owner.
Why isn’t a quarterly survey agent discovery?
Because the population changes faster than any survey cycle. Wiring a new MCP server into a coding agent is a config-file edit that takes under a minute, and the engineer who makes it will not remember it by the time the next questionnaire arrives. A survey-built register is accurate on the day it closes and describes what the organization believed last quarter by the time anyone reads it. Discovery has to be a property of how agents run, a feed from hooks, traffic, and detections that updates records continuously, or the register decays into the spreadsheet it was supposed to replace.
How does the Speakeasy AI Control Plane do discovery?
Everything above is architecture an organization could assemble itself. The Speakeasy AI Control Plane ships the instrumented feeds as one system, so discovery runs as a property of how agents reach tools:
- Hooks on coding agents. The platform ships hook configurations as Claude Code and Cursor plugins, so the sensor that observes each session’s MCP servers and skills arrives through the plugin systems those agents already have and can be provisioned fleet-wide through MDM.
- Shadow MCP detection. When an agent connects to a server outside the sanctioned setup, the call is surfaced by the server’s URL, its host, or its resolved identity, and allow and deny rules with an admin-gated request-access flow decide what happens next. The shadow MCP detection release walks through the workflow.
- The gateway as the sanctioned path. Agents reach tools through the platform’s MCP gateway, so every sanctioned agent, the servers it connects to, and every call it makes are recorded in the moment they happen, and the last-seen field maintains itself.
- Identity from the directory. Sessions authenticate through the identity provider the organization already runs, whether Okta, Microsoft Entra ID, or any SAML or OIDC provider, so a discovered agent that moves onto the governed path binds to a person rather than to an anonymous key.
The CSA note calls the inventory the artifact an organization will present when agent-specific regulatory examination arrives. Discovery is what keeps that artifact true between audits. To see what discovery turns up in your own organization, talk to us.