Because the policy decision happens where the LLM interprets tool descriptions and selects actions, not just where HTTP traffic enters the system. API gateways and WAFs can inspect transport, but they cannot reliably judge tool intent, hidden instructions, or session state. That is why MCP requires tool-level authorisation, logging, and approval.
Why MCP Needs Tool-Specific Controls, Not Just Perimeter Controls
mcp server sit at a boundary that is different from a normal web application. The critical decision is not only whether a request is syntactically valid, it is whether the model is allowed to act on a tool description, a prompt, or a conversation state. That makes tool invocation, not just HTTP ingress, part of the security decision.
API gateways and WAFs still matter, because they can reduce obvious transport-layer abuse and block some malformed or high-volume traffic. But they do not understand the semantic gap between a legitimate-looking request and a harmful tool action. If the trust decision is made downstream, controls also have to exist downstream.
That is why MCP security has to account for authorisation context, session continuity, and tool intent. In practice, the server needs to know whether a client is authorised to call a tool, whether the tool call matches the expected audience and scope, and whether the request is operating under a valid session rather than borrowing trust from another one. See the Model Context Protocol: Authorization specification for the protocol-level model, and OWASP API Security Top 10 for the API-side failure modes that perimeter controls still miss.
What API Gateways and WAFs Can Enforce, and What They Cannot
A gateway is good at access shaping, rate limiting, token validation, and coarse routing. A WAF is good at filtering known malicious patterns, blocking obvious injection payloads, and reducing noisy attack traffic. Those functions are useful, but they are still transport-centric.
They do not reliably answer questions such as: should this tool be called at all, should this user or agent be allowed to invoke that capability, does the current session still deserve the same privileges, and is the tool response safe to hand back into an LLM workflow. Those are policy and context questions, not just packet-filtering questions.
This is why MCP servers need controls that operate on the tool boundary itself. The server should verify authorisation at the point of invocation, log the tool call and decision, and preserve enough context to reconstruct which tool, which session, and which action were involved. For protocol design, the MCP authorization specification is the clearest reference. For practical application and broader agent risk patterns, the OWASP Agentic AI Top 10 captures identity and privilege abuse, tool misuse, and related runtime failures.
What Good MCP Control Design Looks Like
Good design separates three layers: transport control, tool control, and auditability. The gateway can remain the first line of defence, but the MCP server must still enforce least privilege at the tool level, reject token passthrough that expands trust improperly, and keep tool approval logic close to the action being taken.
That design matters most when tools reach sensitive systems or can trigger side effects. In those cases, a generic allow-list at the edge is not enough, because the real security question is whether the tool operation itself is appropriate for the current principal, session, and scope. If the action has irreversible effects, human approval or a narrower delegated path may be the right control.
Operationally, teams should treat MCP tools like privileged interfaces, not just like ordinary API endpoints. That is especially important in deployments that blend agents, long-lived sessions, or reused credentials. NHIMG’s MCP Security Guide and NHI Authentication Guide both reinforce the need to bind authorisation to the actual actor and workload, not to the network path alone. For attack patterns involving malicious or abused MCP servers, postmark-mcp malicious MCP server 2025 shows why tool-level trust boundaries matter.
Risk and Threat Considerations
The main risk is false confidence: teams believe the perimeter is controlling the system while the real decision surface sits inside the MCP interaction. That creates room for tool misuse, confused-deputy behaviour, hidden instruction abuse, and privilege expansion through valid-looking sessions or tokens.
Failure mechanism: An attacker, or a compromised agent workflow, uses an allowed connection to trigger a tool action that the gateway cannot meaningfully judge, then leverages the server’s own trust in the session, token, or tool description to reach data or side effects that should have been blocked.
Impact: The result can be unauthorised data access, command execution through tools, misuse of downstream APIs, and difficult-to-detect abuse because the traffic still appears to come through approved infrastructure.
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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP tool selection can be abused through agent privileges and delegated authority. |
| Recommendation — Bind tool invocation to explicit authority and scope, then log every privileged action. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | API gateways and MCP transports still rely on correct authentication and token handling. |
| API5 — Broken Function Level Authorization | MCP requires tool-level authorisation beyond endpoint reachability. | |
| Recommendation — Enforce audience-bound authentication and reject token passthrough that weakens trust. Authorize each tool action explicitly before the server executes it. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The server must enforce access at the tool boundary, not only at ingress. |
| AU-2 — Event Logging | Tool calls need auditable records to reconstruct action, actor and session context. | |
| Recommendation — Enforce tool-level access decisions where the action is executed. Log tool invocation context and approval decisions for each sensitive action. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | MCP tool access needs defined control rules beyond network filtering. |
| Recommendation — Define and apply access rules for each tool and privileged interaction. | ||
Practitioner Guidance
What to prioritise: Put the authorisation decision at the MCP server and tool layer first, then use the gateway and WAF as supporting controls. If the edge control cannot explain why a specific tool call is safe, it is not the control that should be trusted for that decision.
What to verify: Confirm that each tool has an explicit access rule, that sessions are bound to the right actor and scope, and that logs capture the tool name, request context, and approval decision. If you cannot reconstruct who authorised the action and why, the control design is too weak for production use.
Practitioner takeaway: Treat MCP as an action-authorisation problem, not a traffic-filtering problem; the nearer the control sits to the tool invocation, the less likely it is to be bypassed by valid-looking transport.