Subscribe to the Non-Human & AI Identity Journal
Home FAQ Architecture & Implementation Patterns What breaks when MCP discovery is not scoped…
Architecture & Implementation Patterns

What breaks when MCP discovery is not scoped to entitlement?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 24, 2026 Domain: Architecture & Implementation Patterns

Agents can enumerate actions they should never have seen, which exposes operational intent and creates a wider misuse surface even before execution begins. In practice, uncontrolled discovery undermines least privilege because visibility and use are separated. Discovery itself must be treated as an access event.

Why This Matters for Security Teams

When MCP discovery is not scoped to entitlement, the control plane stops reflecting the actual permission boundary. That means an agent can enumerate tools, endpoints, and actions before any execution control is applied, which turns discovery into a reconnaissance channel. This is especially dangerous in agentic systems because intent changes at runtime, and visibility often expands faster than governance.

The practical issue is not just exposure of tool names. Unscoped discovery can reveal internal workflows, privileged operations, and sensitive integrations that should remain undiscoverable to a given workload. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks treats overexposure as a lifecycle problem, not a one-time configuration mistake, and the same logic applies here. OWASP’s OWASP Agentic AI Top 10 also highlights how agent capability expansion creates abuse paths that traditional IAM does not model well.

In practice, many security teams discover the real blast radius only after an agent has already cataloged the tools it should never have seen.

How It Works in Practice

Entitlement-scoped discovery means the agent only sees the MCP servers, tools, and metadata that its current identity, session context, and task justification permit. The key change is that discovery itself becomes an access event, not a neutral read operation. Current guidance suggests treating tool catalog visibility the same way you treat API invocation: both need runtime checks, auditability, and revocation paths.

In mature implementations, discovery is filtered through workload identity and policy evaluation before the agent receives a usable tool list. That often combines short-lived credentials, context-aware authorisation, and policy-as-code so the system can decide, at request time, whether the agent is entitled to learn that a tool exists. Standards and research from the OWASP Non-Human Identity Top 10 and the AI Agents: The New Attack Surface report are aligned on a practical point: identity must constrain both use and visibility.

  • Scope discovery by task, environment, and approval state, not by broad role membership alone.
  • Use ephemeral tokens so discovery permissions expire with the session or job.
  • Log discovery events separately from tool execution so investigators can see what the agent learned.
  • Apply deny-by-default to any tool metadata that would expose privileged workflows or sensitive systems.

This matters because agents can chain newly discovered capabilities with other tools, creating lateral movement paths that were never part of the original request. These controls tend to break down when MCP gateways expose a shared catalog to many agents because the catalog becomes a universal recon source instead of a governed boundary.

Common Variations and Edge Cases

Tighter discovery controls often increase integration overhead, requiring organisations to balance operational speed against visibility reduction. That tradeoff is real, especially where teams want seamless tool onboarding or broad developer access during testing. Best practice is evolving, and there is no universal standard for how fine-grained MCP discovery scoping must be, but the direction is clear: entitlement should shape what is discoverable, not just what is executable.

Edge cases usually appear in shared sandboxes, multi-tenant platforms, and delegated admin environments. In those settings, teams may allow broader discovery for debugging, but that exception should be time-bound and audited. The Top 10 NHI Issues and the OWASP Top 10 for Agentic Applications 2026 both reinforce the same operational lesson: if discovery is broader than entitlement, the system is effectively publishing attack surface to the workload.

Where governance is weakest is in environments that treat MCP server directories as documentation rather than policy-controlled resources, because disclosure then happens long before a formal access decision.

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.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10N/ADiscovery exposure expands agent attack surface before execution.
OWASP Non-Human Identity Top 10NHI-04Unscoped discovery leaks NHI capability and metadata beyond least privilege.
NIST AI RMFRuntime governance of agent behaviour depends on contextual access decisions.

Use AI RMF governance to require auditable, context-aware control of agent discovery.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org