Agent Capability Discovery and Its Security Risks

What Agent Capability Discovery Means

In agent systems built on protocols such as MCP or similar tool-calling frameworks, an agent rarely has a fixed, hardcoded list of everything it can do. Instead, it queries a registry or protocol endpoint at runtime and receives back a description of available tools, APIs, or other agents it may invoke. This is capability discovery: the mechanism by which an agent learns what it is capable of doing, at the moment it needs to act, rather than at the moment it was built.

This dynamic model is what makes modern agent architectures flexible. New tools can be added to a registry without redeploying the agent. Agents can be composed from other agents. Capabilities can be scoped to context, task, or environment. But this same flexibility means the set of things an agent can do is not fully known in advance, and is not necessarily reviewed by a human before it is acted upon.

Why This Matters for Enterprise Security Teams

Traditional application security assumes a relatively fixed attack surface: a known set of endpoints, permissions, and integrations that can be reviewed, tested, and signed off before deployment. Agent capability discovery breaks that assumption. The list of things an agent can invoke may change between one session and the next, depending on what a registry returns, what other agents are reachable, or what tools have been recently registered.

For security and platform teams, this means the traditional question "what can this system do" is no longer answered once at design time. It has to be answered continuously, at runtime, for every agent, every session, and every identity making a discovery request.

Attack Surface Introduced by Dynamic Discovery

Several distinct risks emerge specifically because discovery happens dynamically and without static review:

• Over-exposure: a discovery response may return more tools or capabilities than the requesting agent actually needs for its task, widening the effective attack surface unnecessarily.
• Untrusted enumeration: if discovery is not scoped to authenticated identity, any agent that can reach the endpoint may enumerate the full set of available tools, including ones it should never be authorized to see.
• Unauthorized invocation: a tool appearing in a discovery response is not the same as that tool being authorized for use by that agent; without a separate check at invocation time, discovery results can be treated as implicit permission.
• Capability chaining: output from one tool can be used to trigger discovery and invocation of another, creating multi-step paths that were never explicitly reviewed or approved as a sequence.

Governance and Least-Privilege Enforcement

Mitigating these risks does not require abandoning dynamic discovery; it requires governing it. Three controls form the core of a workable approach:

• Scoping discovery results to the authenticated identity of the requesting agent, so different agents see different, appropriately limited capability sets.
• Enforcing least-privilege authorization at the moment of invocation, independent of what was returned during discovery, so appearing in a list is never sufficient for access.
• Logging discovery events separately from invocation events, so audit trails can distinguish between an agent learning about a capability and an agent actually using it.

Tradeoffs Between Flexibility and Control

There is an inherent tension between the flexibility that makes dynamic discovery valuable and the control that security teams need. Restricting discovery too tightly reduces the composability that makes agent systems useful. Leaving it unrestricted creates the risks described above. The practical resolution is not to pick one extreme, but to apply governance at the right layer: identity-scoped discovery, invocation-time authorization, and complete audit logging, so that flexibility is preserved for legitimate use while unauthorized paths are constrained and visible.