Directory curation tells you whether a server appears trustworthy enough to consider. Runtime authorisation tells you whether a connected client is allowed to invoke specific tools, touch specific data, or trigger specific actions. They solve different problems, and only the second one limits blast radius once the session is active.
How the two controls differ in practice
Directory curation is a pre-session trust filter. It answers whether a server belongs in the set you are willing to consider by checking reputation, metadata quality, governance, and basic compatibility. runtime authorisation starts after the session exists and answers a narrower question: what this connected client may do right now, for this request, against this tool or resource.
The practical difference is that curation narrows the pool of candidates, while authorisation constrains active capability. A directory can make a server visible and discoverable without granting any operational permission. Runtime authorisation is the control that turns a connection into bounded action, so it is the one that actually limits blast radius once trust has been established.
That split is central to MCP Security Guide, which treats MCP authorisation as a live decision boundary rather than a directory-quality problem. The same distinction also appears in the MCP specification itself, where the authorisation model defines how a client presents and uses access at runtime.
What directory curation can and cannot guarantee
Directory curation is useful for reducing obvious noise. It can remove stale entries, low-quality publishers, duplicate listings, and clearly untrusted endpoints before a user or agent spends time connecting. That makes discovery safer and easier to govern, but it is still only an allow-listing and triage step, not proof that future actions are safe.
Because curation happens before the session, it does not inspect the exact operation the client will attempt later. A well-curated directory can still contain a server that exposes a dangerous tool, returns overbroad data, or behaves differently once invoked. MCP authorization for HTTP transports exists to control that later stage, where the real security decision must be made against the active request.
In other words, curation supports trust selection, but it does not enforce least privilege. If you treat directory quality as a substitute for runtime policy, you will miss the point where access should be narrowed by tool, scope, action, or data class.
Why runtime authorisation is the control that limits blast radius
Runtime authorisation governs what a connected client may invoke after authentication or session establishment. In MCP, that means deciding whether the client can call a specific tool, touch a particular resource, or trigger an action with side effects. This is where policy becomes operational and where a compromised session should be contained.
The best way to think about it is that runtime authorisation is the enforcement layer for least privilege. It can deny a request even when the server is known, the connection is valid, and the session is active. For agentic workflows, that matters because the risk is rarely “can the client connect?” but “how far can a connected client go once it starts chaining tools and data access.” See also the AI Agent Authorisation Guide for the same per-action control pattern applied to autonomous agents.
Runtime authorisation should also be richer than a single yes or no gate. Good designs differentiate read versus write, sensitive versus nonsensitive data, destructive versus nondestructive actions, and low-risk versus high-risk tools. That is the control that meaningfully contains misuse, delegation errors, and confused-deputy behaviour.
Risk and Threat Considerations
The main risk is over-trusting discovery signals and under-investing in live policy. A curated directory can create a false sense of safety if teams assume that “approved to list” means “safe to use,” especially when tools can reach sensitive systems or return high-value data.
Failure mechanism: An attacker, malicious plugin, or over-privileged client can exploit the gap between static trust and active permission, then use a valid session to invoke tools or access data that were never meant to be broadly available. If runtime checks are weak, the directory becomes a trust advertisement rather than a control.
Impact: The result is excessive blast radius, unexpected data exposure, and easier lateral movement through tool chaining. The stronger the connected client’s reach, the more a single compromised session can amplify into broader compromise.
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 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 | MCP runtime authorisation must stop overbroad agent privilege use. |
| Recommendation — Enforce per-action policy checks and least privilege for every tool call. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Runtime authorisation is access enforcement for specific tools and data. |
| AC-6 — Least Privilege | The question contrasts static trust with bounded runtime capability. | |
| Recommendation — Enforce access decisions at request time for each protected MCP action. Limit each connected client to the minimum tool and data access required. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tool invocation is function-level access that must be authorised. |
| API1 — Broken Object Level Authorization | Runtime checks must prevent clients reaching objects or data beyond scope. | |
| Recommendation — Authorize each sensitive function explicitly before execution. Verify object-level access on every MCP request that touches data. | ||
Practitioner Guidance
What to prioritise: Use directory curation to improve discoverability and quality, but make runtime authorisation the primary enforcement control for every sensitive tool or resource. If a request can change state, expose data, or trigger downstream actions, it needs live policy, not just a trusted listing.
What to verify: Confirm that the authorisation decision is evaluated at request time, with enough context to distinguish tool, resource, action, and scope. A directory entry should never be the evidence you rely on to approve a high-impact operation.
Practitioner takeaway: Curation helps you decide what is worth considering; runtime authorisation decides what is actually allowed, and that is the control that limits damage when trust turns out to be misplaced.
Related resources from NHI Mgmt Group
- What is the difference between directory trust signals and runtime control for MCP?
- What is the difference between directory registration and runtime authorisation for agents?
- What is the difference between an API-management-first MCP strategy and an AI-runtime-first control plane?
- What is the difference between API gateway controls and runtime MCP enforcement?