Discovery still works, but access control, credential governance, and auditability do not. Teams end up with visibility into what exists while missing proof of who accessed which tool, under what permissions, and whether the action was policy compliant. That leaves production deployments exposed even when the registry looks well managed.
What an MCP registry can and cannot control
An MCP registry is good at discovery and inventory, but it is not the enforcement point. If it is treated as the only control layer, the organisation can know that a server or tool exists without proving who may use it, how a token is handled, or whether the request was authorised at runtime. The gap is not visibility, it is control.
A registry-only model usually fails where the security decision must happen at request time, not at registration time. Tool access, scope, audience, token handling, and policy enforcement need to live in the path that actually brokers the call, which is why the MCP Security Guide focuses on authorisation, token passthrough, gateways, and practical server-side controls rather than registry metadata alone.
This is also why protocol-level authorisation matters. The Model Context Protocol: Authorization specification makes the server a resource server, which means the decision must be bound to the protected resource and the presented token, not merely to a registry entry.
Why access control, credentials, and auditability fail first
When the registry is the only layer, teams often mistake inventory for governance. That breaks down as soon as a client can reach a tool through a different path, reuse a credential, or present a token that the registry never evaluates. The result is a catalogue of available tools without a trustworthy answer to which identity used which tool under which permissions.
The same weakness appears in credential governance. A registry may list the tool, owner, or environment, but it does not rotate secrets, constrain token scope, or prevent long-lived credentials from being reused outside the intended boundary. Practical control has to cover the credential-bearing path, not just the published listing, and the NHI Authentication Guide is useful here because it frames machine and agent authentication as a control problem, not a naming problem.
Auditability fails for the same reason. If the registry is the only control plane, logs may show that a tool exists or was registered, but not whether a specific call was authorised, whether the actor was entitled to use it, or whether the action matched policy. That leaves gaps in accountability, especially when multiple clients, agents, or service paths can invoke the same backend capability.
How to avoid treating the registry as the security boundary
A registry should be treated as a discovery source, then paired with enforcement, token validation, and logging at the broker, gateway, or server layer. In practice, the question is not whether the registry is accurate, but whether every live request still has to pass a policy decision that can be enforced, logged, and reviewed.
For MCP deployments, the practical pattern is to separate catalogue data from runtime trust. The registry can describe what is available, but it should not be the place where authorisation, secret handling, or per-request approval ends. That is why gateway enforcement, audience-bound tokens, and server-side checks matter more than a clean inventory when production exposure is the concern.
Where agent or tool delegation is involved, using OWASP Agentic AI Top 10 helps frame the broader failure mode: tool misuse and identity or privilege abuse often happen after discovery is already solved.
Risk and Threat Considerations
A registry-only control model creates a false sense of security because it preserves discoverability while leaving the real trust decision weak. Attackers do not need the registry to be wrong, they only need a separate path, a reused token, or an overbroad credential that the registry never evaluates.
Failure mechanism: Access decisions are made outside the runtime path, so inventory data cannot stop unauthorised tool use, token replay, or privilege drift. Once that happens, the organisation can see the asset but not the abuse.
Impact: Production systems remain exposed, audit trails become incomplete, and teams may be unable to prove which identity performed which action or whether the action was policy compliant.
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 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 API Security Top 10 | API2 — Broken Authentication | MCP access depends on validated runtime authentication, not registry metadata. |
| Recommendation — Validate every MCP call with strong authentication before allowing tool access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Registry-only control leaves token and credential lifecycle unmanaged. |
| AU-2 — Audit Events | The question centers on missing proof of who accessed which tool and whether policy was followed. | |
| AC-6 — Least Privilege | Registry visibility does not prevent overbroad tool permissions or excess access. | |
| Recommendation — Manage, rotate, and revoke MCP credentials and tokens under controlled lifecycle rules. Define MCP tool-use events for logging so access and policy decisions are attributable. Restrict MCP tool permissions to the minimum needed for each identity or agent. | ||
Practitioner Guidance
What to verify: Confirm that every live MCP request is checked by a control that can enforce authorisation, validate the presented token, and emit an auditable decision. If the registry is the only place where policy exists, the design is incomplete.
Decision rule: If a control cannot answer who accessed the tool, with what credential, and under what policy, it is not the control layer, it is only the directory layer. Put the enforcement point where the request is actually made.
Practitioner takeaway: Use the registry for discovery, but treat runtime authorisation, credential governance, and audit logging as separate controls that must exist even if the registry is perfect.