AI agents inherit the same catalog visibility as the user or service identity acting on their behalf, so any weakness in registry filtering also becomes an agent access problem. Teams should govern the catalog as an authorization surface, because discoverable tools are available to both humans and agents unless the API blocks them.
What changes when AI agents enter the MCP catalog
MCP catalog access stops being a simple discovery problem and becomes an authorization problem. If an agent can see the catalog, it can usually attempt the same tools a user or service identity can see, so registry filtering, audience scoping and per-tool policy determine the real blast radius.
The practical shift is that catalog visibility is now part of the control plane. A weak registry, loose search endpoint or over-broad gateway can expose tools to both humans and agents, which means “who can browse” and “who can invoke” must be treated as separate decisions.
In other words, the catalog is no longer just documentation. It is an access surface, and access surfaces need policy boundaries, not only good naming and organisation.
Why catalog visibility becomes an access decision
An MCP catalog can leak capability even when the tool itself is protected. A discoverable tool name, description or schema can reveal business functions, internal services or high-value actions, and an agent can use that information to choose the next request path. For that reason, catalog entries should be filtered by the same authorization logic that governs the underlying tools, not by convenience alone.
This is especially important when the agent acts on behalf of a user or service identity. The catalog should expose only what that identity is allowed to know and do, because any mismatch between registry visibility and invocation policy creates a confused-deputy style gap: the agent sees something it should not, then tries to use it through a path that looks legitimate.
Where MCP uses HTTP transports, the authorisation model should be explicit and resource-bound. The MCP authorization specification is relevant here because it frames servers as OAuth resource servers and discourages token passthrough, which helps keep catalog discovery and tool invocation tied to the intended audience.
What good control looks like for humans and agents
Good control starts with separating three questions: who may discover the catalog, who may inspect a tool, and who may invoke it. Those checks should not collapse into one broad “logged in means visible” rule, because AI agents often operate with delegated identity, repeated requests and automation speed that make overexposure more damaging.
Access should be scoped at the smallest useful unit, usually the individual tool, action or capability group. If the catalog is shared across tenants, teams or environments, the registry must also enforce environment isolation, because an agent given broad search rights in one context can infer or reuse patterns in another.
The strongest implementation pattern is to treat catalog entries as policy objects. That means each entry should carry an allow decision, a denial decision or a conditional decision based on the calling principal, the target resource and the action requested. NHIMG’s AI Agent Authorisation Guide is useful here because it focuses on least privilege, task-scoped access and per-action decisions for agents. For a broader identity model, the Agentic AI Identity Guide explains how delegation, registration and retirement affect what an agent should be allowed to see and use.
Why this becomes a governance and threat issue
The threat is not only unauthorized invocation. A poorly controlled catalog can also support tool enumeration, trust abuse and lateral movement across adjacent services. Once a catalog becomes searchable by an agent, it can function as an attack map, especially if descriptions reveal endpoints, scopes, environments or administrative actions.
That risk grows when catalog access is broader than execution rights. An agent that can discover many tools but may only use a few creates a monitoring problem as well as an authorization problem, because the organisation must distinguish harmless exploration from pre-attack recon or mis-scoped automation. The result is that catalog governance needs logging, review and revocation paths, not just static allowlists.
AI agents also change the consequences of registry mistakes. A human might notice that a tool listing is too broad, but an agent will immediately act on the exposed surface. NHIMG’s AI Agent Observability, Audit and Incident Response Guide is relevant because catalog control only works if discovery, attribution and kill-switch decisions can be tested and verified when an agent behaves unexpectedly.
Risk and Threat Considerations
Catalog exposure becomes risky when discovery and invocation are not governed with the same precision. If an agent can enumerate tools more widely than it can use them, the catalog can disclose sensitive internal capability, support privilege chasing, or make a later abuse step much easier.
Failure mechanism: Weak registry filtering, over-broad search, or missing audience checks lets an agent see tools that exceed its delegated authority, then turns that visibility into attempted use or unintended disclosure.
Impact: The likely outcomes are overexposure of internal capabilities, greater blast radius for compromised or misconfigured agents, and harder-to-detect misuse because the access path appears to come from an authorized principal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP catalogs expose functions, so visibility and invocation need function-level authorization. |
| Recommendation — Enforce per-tool function authorization so agents cannot discover or invoke capabilities beyond their rights. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Catalog filtering is an access enforcement problem for discoverable tools and actions. |
| IA-9 — Identification and Authentication (Service Accounts and APIs) | Agent-mediated catalog access depends on authenticated non-human principals and delegated requests. | |
| Recommendation — Apply access enforcement at the catalog and tool layers, not only at execution time. Authenticate agent and service principals before allowing catalog discovery or tool use. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | MCP catalog governance is fundamentally about controlling who may discover and use capabilities. |
| Recommendation — Define catalog visibility and tool access rules as formal access-control policy. | ||
| OWASP ASVS | V8 — Authorization | The question turns on authorization boundaries between discovery and permitted actions. |
| Recommendation — Separate discovery rights from execution rights and verify both in authorization testing. | ||
Practitioner Guidance
What to verify: Confirm that catalog visibility, tool inspection and tool execution are separately enforced, and test them with both human and agent principals. If the agent can see a tool it cannot legitimately use, the registry is already too permissive.
Decision rule: If a catalog entry would be sensitive if exposed in a dashboard, treat it as sensitive when exposed to an agent. Agents do not reduce the need for authorization, they increase the need for precise authorization because they can act faster and more consistently than humans.
What good looks like: A well-controlled MCP catalog shows each caller only the tools it is allowed to discover, with denied entries omitted or masked, per-action policy attached to each exposed capability, and logs that make discovery attempts attributable.
Practitioner takeaway: The right control model is not “can the agent reach the catalog?”, but “what exactly may this principal discover, under what policy, and does discovery itself reveal more than the principal should know?”