A server-level model hides important differences between harmless and sensitive actions. Agents may discover tools they should not use, or keep access to one dangerous capability because the whole server was approved. Per-tool checks prevent that mismatch, let permissions map to real tasks, and make it possible to remove a single risky action without blocking the rest of the workflow.
Why a server-level permission model breaks down in MCP gateways
A server-level model treats every tool inside an MCP server as if it deserved the same approval, but the real risk is uneven capability. One tool may only read benign context while another can expose secrets, mutate records, or trigger external side effects. When the gateway collapses those differences, it creates overbroad trust, weak task boundaries, and hidden privilege.
The core breakage is not just convenience, it is authorization mismatch. If the gateway can only approve or deny an entire server, it cannot express that one tool is safe for broad use while a sibling tool should be restricted to narrow, verified tasks. That makes the approval decision too coarse for the actual blast radius of the tools it fronts.
This is why per-tool authorization matters in practice: it lets the gateway align permission to the specific action, not to the hosting container. In an MCP environment, the right control boundary is the tool or action the agent invokes, because that is where harmful misuse, accidental disclosure, or unsafe side effects actually occur.
What per-tool authorization preserves that server-wide approval loses
Per-tool checks preserve separation between discovery and use. An agent can know a tool exists without automatically being allowed to invoke it, and approval for one capability does not silently inherit to the rest of the server. That distinction is important when a server bundles read-only, administrative, and write-capable tools in the same interface.
Per-tool authorization also supports least privilege in a way server-level approval cannot. It allows a security team to permit routine actions while blocking one risky operation, rather than forcing an all-or-nothing decision that either overexposes the environment or breaks legitimate workflows. For MCP gateways, that is the difference between a manageable control plane and a hidden privilege bundle.
This is the same design logic behind Authorisation Models Guide and AI Agent Authorisation Guide: permissions should map to the real unit of authority, not to a broader wrapper that contains mixed-risk actions. In MCP, the wrapper is the server, but the authority that matters is the tool.
How to design MCP permissions so one risky tool does not govern everything
The gateway should evaluate tool-level policy before execution, then bind that decision to the specific tool name, arguments, and context of use. That lets you distinguish harmless inspection from sensitive mutation, and it prevents a single approved server from becoming a proxy for unrestricted agent action. A server may still be the distribution point, but it should not be the authorization unit.
Practical implementations usually need three checks together: tool inventory, policy expression, and enforcement at invocation time. Without the inventory, you cannot know what is exposed. Without policy expression, you cannot say which tool is allowed under which conditions. Without per-invocation enforcement, the approval only exists on paper.
For MCP-specific guidance, MCP Security Guide explains the authorization model, while the official Model Context Protocol: Authorization specification shows how servers should behave as resource servers rather than trust-all endpoints. That combination is what keeps a gateway from turning approval of one tool into implied trust for the whole server.
Risk and Threat Considerations
Server-level approval creates a broad blast radius, so compromise or misuse of one tool can expose capabilities that were never intended for that task. It also encourages confused-deputy behavior, where an agent or gateway uses a broadly approved server to reach a sensitive action that should have required a separate decision.
Failure mechanism: the gateway cannot distinguish between low-risk and high-risk tools, so a single allow decision inherits across unrelated actions and hides privilege creep until a dangerous call is made.
Impact: sensitive tools become easier to discover, easier to misuse, and harder to revoke selectively, which increases the chance of data exposure, destructive actions, or lateral privilege expansion.
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 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 | Per-tool auth prevents agents inheriting broad server approval into risky capabilities. |
| Recommendation — Enforce tool-scoped authorization so an agent cannot reuse one approved server to reach sensitive actions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Server-wide approval fails when different tools expose different privilege levels. |
| Recommendation — Authorize each function or tool independently so one approved endpoint cannot expose unrelated capabilities. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about avoiding overbroad permission inheritance across tools. |
| Recommendation — Apply least privilege at the tool level and remove access to any capability not needed for the task. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Per-tool verification aligns with never trust, always verify at each action boundary. |
| Recommendation — Verify each tool invocation instead of trusting the server once for all subsequent actions. | ||
Practitioner Guidance
What to verify: confirm that each MCP tool has its own authorization rule or policy branch, and that the enforcement point checks the tool at call time rather than only during server registration. If the policy cannot distinguish one tool from another, the model is still too coarse.
Decision rule: if a server contains both benign and sensitive tools, treat server-wide approval as a design smell and move to tool-scoped authorization before production use. Keep the broader server available only when the entire bundle truly shares the same risk level.
Practitioner takeaway: the right control boundary is the action the agent can actually perform, not the server that happens to expose it.
Related resources from NHI Mgmt Group
- What breaks when MCP tools rely on the UI instead of server-side authorization?
- What breaks when pagination is flattened into a single MCP tool call instead of being designed explicitly?
- What breaks when teams treat MCP like a complete security model instead of a tool coordination standard?
- What breaks when MCP tools are approved at the server level but not at the tool level?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
