Large catalogs increase the chance that an agent can discover more than it should, combine permissions across services, or consume so much context that operators lose clarity over what was actually invoked. The risk is not just scale. It is uncontrolled composition of delegated access across multiple tools and systems.
Why This Matters for Security Teams
Large MCP tool catalogs turn identity risk into an authorization and observability problem at the same time. The catalog itself becomes a discovery surface, and each new tool expands the set of delegated actions an agent can chain together at runtime. That is why static allowlists and broad service-account permissions so often fail in practice: the agent is not a person with a stable workflow, but an autonomous executor that can choose paths operators did not anticipate.
Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research such as Ultimate Guide to NHIs points to the same pattern: excessive privilege, weak inventory discipline, and poor visibility are what make identity sprawl exploitable. The more tools an MCP server exposes, the harder it is to prove that a given invocation was necessary, authorized, and bounded to a single task. In practice, many security teams encounter tool-catalog abuse only after an agent has already combined permissions across systems, rather than through intentional design.
How It Works in Practice
An MCP catalog should be treated as a live authorization boundary, not as a convenience menu. The main risk is not just that an agent can see more tools. It is that tool metadata, response content, and chained calls can create a path from low-risk access to high-impact actions. Once an agent can discover a tool, it may infer adjacent capabilities, request supporting data, or invoke a second service that was never intended to be available in the same context.
Practical controls usually combine several layers:
- Issue OWASP Agentic AI Top 10-aligned runtime policies so access is decided per request, not per catalog listing.
- Use workload identity for the agent and for each tool-backed execution path, so operators know what the agent is and what it is allowed to do.
- Prefer just-in-time, short-lived credentials over reusable tokens, especially when the tool can reach data stores, ticketing systems, or deployment planes.
- Log each tool selection and downstream action with enough context to reconstruct whether the call was necessary and proportional.
- Keep the catalog segmented by function, data sensitivity, and trust domain rather than exposing one broad surface to every agent.
NHIMG’s 52 NHI Breaches Analysis shows how often identity failures become incident chains when access is overextended or poorly observed. That is why catalog governance matters as much as secret rotation or vault hygiene: a well-protected token can still be dangerous if the tool behind it is too powerful. These controls tend to break down when the MCP environment is shared across many teams because catalog growth outpaces policy review and ownership becomes ambiguous.
Common Variations and Edge Cases
Tighter catalog controls often increase operational overhead, requiring organisations to balance agent productivity against review burden and support friction. There is no universal standard for this yet, so guidance is still evolving around how much tool exposure is acceptable for different agent classes.
Some environments need broad catalogs because the agent is acting as a dispatcher, but that does not remove the need for boundaries. In those cases, best practice is to split discovery from execution, so the agent can inspect available capabilities without inheriting the power to invoke all of them. Other edge cases include high-churn development systems, where new tools appear daily, and regulated environments, where every additional tool may trigger change control or access review.
Teams should also be careful not to confuse “fewer tools” with “safer.” A small catalog can still create severe risk if one tool fans out into multiple back-end systems or if a single connector has broad write access. The practical test is whether the agent can combine permissions in ways the operator cannot easily explain. For governance mapping, the NIST Cybersecurity Framework 2.0 supports inventory, access control, and monitoring expectations that fit this problem well, while Top 10 NHI Issues captures the recurring failure modes seen in real deployments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AA-03 | Large MCP catalogs create agentic tool-discovery and chaining risk. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Catalog sprawl often hides excessive privilege and weak identity boundaries. |
| NIST AI RMF | Agent autonomy makes runtime governance and accountability essential. |
Inventory every NHI-backed tool, trim standing access, and map each token to one purpose.
