agent discovery
Agent discovery continuously finds AI agents in use and turns each finding into an inventory record with an owner and a disposition. It covers coding agents on endpoints, SaaS copilots, internal orchestrators, and unsanctioned MCP configurations.
Most organizations already keep device, software, and SaaS registers, but none describes an agent’s actual access. A software register may show that Cursor is installed on a managed laptop. The same laptop can have a GitHub Model Context Protocol (MCP) server configured in ~/.cursor/mcp.json, using a personal access token to reach repositories. That configuration may not appear in any record the security team can query.
In a 2026 survey of 235 large-enterprise CISOs and CIOs, 92% said they lacked full visibility into their AI agent identities. An agent inventory gives the organization a record of those agents. Procurement and admin records identify known SaaS agents. Discovery finds the endpoint configurations, internal orchestrators, and unsanctioned connections that those systems miss.
Why can’t MDM, a CMDB, or a SaaS admin console find AI agents?
Mobile device management (MDM) tracks managed laptops and their software. A configuration management database (CMDB) records the assets an organization owns, while a SaaS admin console records accounts in one product. Each system captures useful information, but none has the full view of an agent.
- MDM and software asset scans show installed applications such as Cursor and Claude Code. An agent’s access often lives in configuration: an MCP server can be a few lines of JSON in
~/.cursor/mcp.json, and a skill can be a Markdown file in a project directory. A software scan can confirm that the client exists, but it cannot show which MCP servers it is wired to, which identity the session uses, or whether the setup was approved. - The CMDB records assets the organization possesses. An agent acts under a digital identity and takes actions on the organization’s behalf, which is why it needs a dedicated agent inventory.
- SaaS admin consoles show the users in their own tenant. The ChatGPT Enterprise console and Microsoft Copilot dashboard do not show each other’s users, endpoint agents, or agents inside an internal orchestrator.
Three signals feed agent discovery: endpoint hooks, gateway traffic, and detection of servers outside the sanctioned path.
Is agent discovery the same as shadow AI?
Shadow AI is AI in use that the security team has not seen. Agent discovery surfaces those agents, but it also records sanctioned agents found through MDM enrollment or an identity provider. Every finding needs a record and an owner before the organization can govern it.
Our guide on shadow AI explains the detection architecture, from endpoint hooks to MDM provisioning. Agent discovery turns those signals into inventory records. An MCP inventory records the related tool layer: the MCP servers in use and the tools they expose. An MCP gateway keeps the sanctioned part of that record current.
How do agent hooks discover agents on the endpoint?
Supported coding agents can run agent hooks, user-defined handlers configured for lifecycle events such as before or after a prompt or tool call. A hook can block a dangerous command, remove a secret, or report the MCP servers, skills, and identity a session is using.
This is especially useful for local stdio servers. A stdio MCP server runs as a child process of the agent, with MCP messages moving through stdin and stdout on the endpoint. Network controls may not see that client-server connection, although the server can still make its own outbound calls. An endpoint hook can observe the local configuration and connection.
How does an MCP gateway support agent discovery?
When agents reach tools through an MCP gateway, the gateway can record every session and tool call. An agent and the servers it connects to enter the inventory as they are used, and traffic keeps each record’s last-seen field current.
A gateway only sees the path it fronts. It discovers sanctioned agents and keeps the tools register current, while endpoint and detection feeds find unsanctioned connections.
How does shadow MCP detection find the servers nobody approved?
When agents are instrumented through hooks or a managed client, a connection to an MCP server outside the sanctioned setup appears in the same feed as governed traffic. Each sighting can include the server’s URL, its host, and the identity the session ran as. Shadow MCP refers to these unapproved servers operating outside formal security governance.
This feed provides discovery for shadow AI. Our guide on shadow AI explains how endpoint hooks, a control plane, and MDM work together across a fleet.
Can identity providers and SaaS admin consoles feed discovery?
Identity providers and SaaS admin consoles identify known SaaS agents. An identity provider records which users authenticated to ChatGPT Enterprise, Microsoft Copilot, or Gemini, while each product’s admin console lists its seats. Adding those records to the inventory captures approved SaaS agents without asking teams to submit them manually.
These records arrive as user lists rather than agent records, so each agent still needs an owner and a disposition. They also cover only products the organization already knows about. Endpoint and traffic feeds remain necessary to find internal agents and unsanctioned connections.
What does a discovery finding become?
A discovery finding becomes an agent inventory record. The record captures the identity the agent runs as, its human owner, the tools and data it reaches, and its sanctioned status.
A human owner assigns a disposition: sanction the agent and move it onto the governed path, reduce its access, or revoke it. For an unreviewed server, the MCP approval workflow records the evidence, scope, and rationale behind that disposition. The same handoff applies to sanctioned findings. An agent found through MDM enrollment or an identity-provider feed still needs a record and owner. Employee-built apps need the same treatment; vibe coding security applies the discovery pattern to applications that live outside the normal software review path.
Why doesn’t a quarterly survey keep the agent inventory current?
The agent 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 may not remember it by the next questionnaire. A survey-built register is accurate when it closes and stale by the time it is read. Hooks, traffic, and detection feeds update records continuously as agents run.
How does the Speakeasy AI Control Plane do discovery?
An organization can assemble these feeds from its existing systems. The Speakeasy AI Control Plane provides them as one system, so discovery happens as agents reach tools:
- Hooks on coding agents. Hook configurations ship as Claude Code and Cursor plugins. They observe each session’s MCP servers and skills, and MDM can provision them across the fleet.
- Shadow MCP detection. When an agent connects to a server outside the sanctioned setup, the platform records the server’s URL, host, or resolved identity. Allow and deny rules, with an access request that requires admin approval, determine what happens next. The shadow MCP detection release shows the workflow.
- The gateway on the sanctioned path. Agents reach tools through the platform’s MCP gateway. The platform records each sanctioned agent, the servers it connects to, and every call it makes, then keeps the last-seen field current.
- Identity from the directory. Sessions authenticate through the organization’s identity provider, including Okta, Microsoft Entra ID, and SAML or OIDC providers. A discovered agent that moves onto the governed path then connects to a person rather than an anonymous key.
An agent inventory provides the record the organization needs during an audit or incident. Discovery keeps that record current between reviews. To see what discovery turns up in your organization, talk to us.