It breaks at the authorisation boundary. Tool filtering can reject obvious categories, but it cannot reliably evaluate the final effect of raw command strings, query languages, or batched operations. The downstream system still owns the real privilege model, so gateway-only rules create a false sense of control instead of enforcing actual access decisions.
When MCP filtering is treated as the access decision, what fails?
The failure is not just technical, it is conceptual. MCP tool filtering can narrow what an agent is allowed to call, but it does not replace the downstream authorization model that decides whether a specific action, query, or batch should succeed. Once the agent can express intent in a tool-accepted form, the real control point has to live where the protected resource evaluates access.
That distinction matters because “blocked tool” and “denied operation” are not the same thing. A tool gateway may screen obvious categories, but it does not reliably understand command composition, database semantics, or the side effects of a seemingly safe request.
For MCP itself, the authoritative model is the protocol’s authorization path, not ad hoc filtering at the edge. The same principle applies in practice to the MCP authorization specification: tokens, audience restriction, and resource-server enforcement are what make access decisions enforceable.
Why tool filtering cannot stand in for privilege control
Tool filtering works at the label or shape level, which means it can reject a suspicious tool name, a banned keyword, or an obviously dangerous category. It cannot reliably determine whether an accepted SQL statement performs a destructive update, whether a shell command expands into something harmful, or whether a batched call crosses a boundary that matters to the target system. That is an authorization problem, not a classification problem.
In other words, the gateway sees intent tokens, while the resource sees effect. A model or policy layer that never evaluates the final object, row, record, scope, or action leaves a gap that attackers and misconfigured agents can exploit through argument smuggling, chaining, or harmless-looking wrappers.
This is why AI Agent Authorisation Guide is useful here, because it frames agent access as per-action authorisation, least privilege, and delegated authority instead of broad tool access. The control objective is not “which tools can be named”, it is “which effects can be authorised”.
It also aligns with the broader zero-trust principle that the request, not the channel, must be verified. Zero Trust for AI Agents captures the practical point: do not treat gateway acceptance as proof of entitlement, and do not let standing access accumulate behind a filtered interface.
What practitioners should treat as the real control boundary
The real boundary is the protected system’s own privilege model, including its object-level, function-level, and transaction-level rules. If an agent needs database access, the database or service API must enforce which objects can be read or changed, under which conditions, and with what scope. If it needs workflow actions, the workflow engine must decide whether that action is permitted for that principal and that context.
That is also why agent identity and scope need to be explicit. A filtered MCP gateway may be a useful choke point, but it should only forward requests that are already limited by identity, audience, purpose, and action scope. Where the agent is acting on behalf of a user, the downstream service should still distinguish delegated authority from blanket tool use.
Agentic AI Identity Guide is relevant because it shows how identity, delegation, registration, and retirement change the control model. If those pieces are missing, a tool filter is just an inspection layer wrapped around an uncontrolled principal.
MCP Security Guide is also a good reference point because it treats gateways, token passthrough, and OAuth-based authorisation as parts of a larger trust design, not as a substitute for enforcement at the resource.
Risk and Threat Considerations
When organisations use MCP filtering as if it were access control, they create a false negative: harmful actions may still execute because the gateway approved a superficially safe request. The main risk is privilege inflation by indirection, where raw command strings, chained tool calls, or batched operations achieve outcomes that the filter never evaluated.
Failure mechanism: The gateway applies coarse content or tool-name rules, but the target system still interprets the request and enforces the real privilege model. Attackers and faulty agents can route around the filter by changing syntax, splitting operations, or embedding dangerous effects inside approved calls.
Impact: The likely result is unauthorized data access, unintended modification, destructive actions, or a misleading control posture that delays detection and response. If operators believe the gateway is the security boundary, they may also miss where logging, approval, or revocation actually needs to occur.
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, OWASP ASVS and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent tools can be abused when access is over-scoped or wrongly trusted. |
| Recommendation — Enforce per-action authorization and least privilege for every agent request. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Gateway filtering can miss whether an allowed call is functionally authorized. |
| Recommendation — Verify the target service authorizes each function, not just the API entry point. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The answer hinges on privilege being enforced at the real control point. |
| IA-5 — Authenticator Management | Tool gateways and downstream services still depend on controlled credentials and tokens. | |
| Recommendation — Restrict each agent and service account to the minimum permissions needed. Manage credentials and tokens so the downstream system can enforce authenticated access. | ||
| OWASP ASVS | V8 — Authorization | The question is about where authorization must actually happen in the request path. |
| Recommendation — Require authorization checks at the protected resource before any state-changing action. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Identity-Based Access Control | Zero trust requires access decisions at the resource based on identity and context. |
| Recommendation — Base every access decision on verified identity and current context at the resource. | ||
Practitioner Guidance
What to verify: Confirm that the downstream system independently enforces object, function, and scope restrictions, and do not trust a gateway unless you can show the target will reject the same request without the agent’s filter in front of it.
Decision rule: If a request can change state, read protected data, or trigger external side effects, treat the agent as untrusted until the receiving service authorises the specific effect, not just the tool call.
Common mistake: Teams often test whether “bad” tools are blocked and stop there. The better test is whether an accepted request still fails safely when it is malformed, over-scoped, or replayed against the downstream resource without gateway mediation.
Practitioner takeaway: MCP filtering is a routing and hygiene layer, not the privilege system; if the protected system does not make the final access decision, you do not have access control, you have policy theatre.
Related resources from NHI Mgmt Group
- What breaks when observability is used instead of access control for AI agents?
- What breaks when organisations rely on access control alone for MCP-connected AI agents?
- Why do AI agents and MCP tool calls increase the need for centralized identity and access control?
- When is it crucial to implement least-privilege access for AI agents?