It fails when any user with a connection path can discover and reach servers without explicit entitlement mapping. In MCP environments, discovery is itself an access decision, so broad defaults create unnecessary exposure. Teams should design for least visibility first, then allow only the servers required for a role or group.
Why Open-By-Default Discovery Breaks MCP Security
In MCP, discovery is not just navigation, it is part of the access decision. If servers are broadly visible to anyone with a connection path, users can enumerate capabilities before any entitlement check constrains what they should see. That creates an exposure problem even when the server itself still requires some form of downstream authorization.
Open-by-default discovery weakens security because the control boundary moves from “who may use this server” to “who can see and reach it.” In practice, that makes visibility the first privilege to manage, especially when servers expose sensitive tools, data sources, or operational actions.
Well-designed MCP access should therefore start from least visibility, then expand only what a role or group actually needs. If every connected user can discover every server, the platform is already granting too much trust before any action is attempted.
How Discovery Becomes an Access Decision
MCP environments often feel safe when actual tool execution is gated, but the earlier phase matters too. Discovery reveals what exists, what it can do, and where a client can attempt interaction. That means exposure begins before execution, especially if server listings, metadata, or routing paths are available without explicit entitlement mapping.
When discovery is open, security teams lose a clean separation between inventory and authorization. A user does not need full execution rights to create risk if they can identify high-value servers, sensitive workflows, or internal-only capabilities. In other words, broad discovery can function as an information leak and a precondition for later misuse.
MCP Security Guide is the best starting point for the underlying authorization model, because it treats access as something that must be deliberately bounded rather than assumed from connectivity alone. For broader agent and tool risk context, OWASP Agentic Applications Top 10 helps frame why tool reachability and privilege abuse belong in the same conversation.
Least Visibility, Least Privilege, and the Practical Control Pattern
The practical control pattern is to treat server discoverability as a privilege tier, not as a default product feature. That means exposing only the servers needed for a given role, group, tenant, or environment, and keeping everything else undiscoverable by default. Where possible, discovery should be aligned to the same authorization source that governs tool use.
This is especially important for MCP because broad server visibility can create accidental coupling between low-risk and high-risk operations. A user who can see a server may try to infer internal structure, automate probing, or target the most sensitive tool surfaces first. Minimizing visibility reduces both accidental overexposure and opportunistic abuse.
Model Context Protocol: Authorization specification is relevant because it reinforces audience-bound access and avoids careless token handling. For the adjacent machine-authentication layer that often supports MCP deployments, NHI Authentication Guide is useful when server access depends on client credentials, mTLS, or other non-human authentication mechanisms.
Risk and Threat Considerations
Open discovery increases both exposure and attack surface. It gives unauthorized users an inventory of what exists, which servers are valuable, and which paths are worth probing, even if they cannot complete every action immediately.
Failure mechanism: Discovery is left open by default, so any user with a connection path can enumerate servers and reach metadata or endpoints without an explicit entitlement check. That breaks least visibility and can turn a simple listing function into a reconnaissance channel.
Impact: The result is unnecessary exposure of sensitive servers, easier targeting of privileged tools, and a higher chance that misrouted clients, overbroad tokens, or weak downstream controls lead to unauthorized access or misuse.
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, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Open MCP discovery enables privilege exposure before action is taken. |
| Recommendation — Restrict tool and server discovery to the minimum role-based set. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Broad discovery and reachability create overbroad machine access paths. |
| Recommendation — Limit NHI-visible servers to role-specific audiences. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The issue is excessive default visibility and access scope. |
| AC-3 — Access Enforcement | MCP needs enforced entitlement mapping before users can reach servers. | |
| Recommendation — Apply least privilege to discovery and server reachability. Enforce entitlements before exposing MCP servers. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Open discovery can expose functions that should not be reachable. |
| Recommendation — Map each server function to explicit authorization checks. | ||
Practitioner Guidance
What to prioritise: Make server visibility intentional. If a user or workload does not need to know a server exists, do not publish it broadly, and do not rely on later-stage authorization to compensate for an overexposed discovery plane.
What to verify: Check whether discovery, routing, and execution all use the same entitlement source. If discovery is broader than execution, confirm there is a documented reason and a compensating control for the added exposure.
Decision rule: If a server carries sensitive tools, data, or operational actions, default it to role-based discoverability rather than global visibility. Treat “can see it” as a meaningful access outcome, not a harmless convenience.
Practitioner takeaway: In MCP, the safest default is not open discovery with later filtering, it is constrained discovery with explicit entitlement mapping from the start.
Related resources from NHI Mgmt Group
- How should security teams handle MCP authentication failures so they do not open access by default?
- How can organizations secure their MCP server credentials?
- How should security teams authenticate AI agents in enterprise environments?
- Why do ephemeral credentials still leave risk in machine access models?