Endpoint filters decide what the agent can discover at build time, while runtime policy decides whether a specific call is allowed in the current context. Filters reduce obvious exposure, but only policy can account for delegator identity, resource scope, intent, and approval requirements. Teams need both, but they are not interchangeable.
How endpoint filters and runtime policy split the MCP decision
Endpoint filters and runtime policy sit at different points in the control plane. Filters shape the tool surface an agent can see, which is useful for reducing noise and obvious exposure. Runtime policy evaluates the specific request that is being made, so it can incorporate current context, scope, and approval state before access is granted.
That distinction matters because MCP tools are not just “available” or “unavailable”, they are invoked by a particular actor against a particular resource. A filter can hide a risky tool from discovery, but it cannot tell whether the current caller is allowed to use it right now. Runtime policy is the control that decides whether a live action should proceed.
When teams blur the two, they often overtrust static configuration. A narrow endpoint list may look safe, but the real question is whether the call is authorised in the present session, for the current delegator, with the right scope and intent. That is why endpoint filtering is an exposure-reduction measure, not a substitute for enforcement.
Why build-time visibility and live authorisation are not interchangeable
Endpoint filters are best understood as a discovery and curation mechanism. They answer the question, “Which MCP tools should the agent be aware of when it is assembled or configured?” That helps reduce accidental access to irrelevant or obviously sensitive capabilities, and it can simplify agent behaviour.
Runtime policy answers a harder question: “Given the current request, should this call be allowed now?” That decision may depend on who delegated the action, whether the target resource is in scope, whether the request matches the declared intent, whether the session is still valid, and whether extra approval is required. Those inputs change over time, so they belong in policy, not in a static filter.
In practice, this is similar to the difference between presenting an interface and permitting an operation. A filtered endpoint list can limit the attack surface, but only runtime control can stop an otherwise visible tool from being misused through stale context, overbroad delegation, or a change in user approval.
What goes wrong when you rely on only one layer
Relying only on filters creates a false sense of safety. A tool that is hidden during setup may still be callable later if the runtime path is not checked carefully, especially when tokens, delegated authority, or cached context are reused across steps. That is how “looks unavailable” turns into “still usable”.
Relying only on runtime policy leaves the agent with a broad and sometimes confusing tool surface. Even if every call is checked, unnecessary exposure increases the chance of misuse, operator error, and accidental interaction with the wrong capability. The result is more burden on policy logic and less containment if an upstream configuration mistake occurs.
The stronger pattern is layered control: filters narrow what is exposed, and policy enforces what is permitted. Model Context Protocol: Authorization specification reflects this separation by treating servers as OAuth 2.1 resource servers with audience-bound tokens instead of assuming discovery control alone is enough.
Risk and Threat Considerations
Because MCP tools often bridge an agent to sensitive systems, weak separation between filtering and runtime policy can create privilege drift, confused-deputy behaviour, and unintended tool use. The practical risk is not just exposure at setup time, but abuse of a valid-looking action after context, scope, or approval has changed.
Failure mechanism: A tool is suppressed or displayed correctly at build time, but the live request path does not enforce delegator identity, resource scope, or approval constraints, so a later call succeeds with broader authority than intended.
Impact: Attackers or overly broad automation can reach data, actions, or downstream systems that the initial endpoint surface suggested were out of bounds, increasing the blast radius of a compromised or misused agent session.
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, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tool calls need live authorisation, not just surface filtering. |
| Recommendation — Enforce function-level checks on every tool invocation, not only on discovery. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runtime policy depends on controlling credentials, tokens, and their lifecycle. |
| AC-6 — Least Privilege | Filtering and policy both aim to reduce excess access to tools and resources. | |
| AC-3 — Access Enforcement | Runtime policy is the enforcement layer that decides whether a live action is allowed. | |
| Recommendation — Manage tokens and secrets so runtime checks can trust the current caller. Limit each MCP actor to the minimum tool and resource access it needs. Enforce each MCP request at the point of use with current-context checks. | ||
| NIST Zero Trust (SP 800-207) | Never trust, verify | The answer is about verifying each action in context rather than trusting exposure controls. |
| Recommendation — Verify each tool request in context before allowing access. | ||
| OWASP ASVS | V8 — Authorization | The distinction maps to exposed functionality versus request-time authorisation. |
| Recommendation — Verify that every sensitive action has request-time authorization, not just UI or endpoint hiding. | ||
Practitioner Guidance
What to verify: Confirm that filters only shape tool exposure and that every sensitive MCP action is re-authorised at runtime against the current caller, current resource, and current approval state. If the runtime check cannot explain why a specific call was allowed, the control is too weak to trust.
Decision rule: If the security question is “should users know this tool exists?”, handle it with filtering; if it is “may this specific invocation proceed?”, handle it with policy. Treat any design that tries to make one control do both jobs as a control gap, not a simplification.
Practitioner takeaway: The safest MCP design assumes discovery and authorisation fail differently, so both must be correct for different reasons, at different times, and with different evidence.