What breaks when MCP tools are approved at the server level but not at the tool level?

Server-level approval hides major differences in tool risk. A single MCP server can include read, write, delete, or even code-execution capabilities, and each tool changes the blast radius. Without tool-level control, teams may approve a server that still allows data exfiltration, repository deletion, or untrusted input to reach an agent’s context.

Why This Matters for Security Teams

Server-level approval treats an mcp server as a single trust decision, but the risk lives in the individual tools it exposes. That matters because one server can bundle harmless read-only functions with write, delete, or execution paths that change the blast radius immediately. In agentic environments, the agent will use whatever the server exposes if the context and policy allow it, which makes coarse approval a governance blind spot rather than a control.

This is exactly why current guidance in OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 emphasizes tool-scoped evaluation, not just server enrollment. The practical issue is that security teams often sign off on the integration boundary and assume tool safety follows automatically. It does not.

Astrix Security’s The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how common this gap already is. In practice, many security teams encounter data exfiltration or repository damage only after an approved server has already been used in production.

How It Works in Practice

Tool-level control means every MCP capability is evaluated on its own risk, not inherited from the server wrapper. A server should be viewed as a container for distinct operations such as search, read, write, delete, or command execution. If an agent only needs read access, then approval should not silently include mutation or execution tools. This is the core difference between coarse trust and meaningful least privilege.

Effective implementations usually combine three layers:

• Tool inventory that classifies each function by data sensitivity and action type.
• Policy checks at request time so the agent’s intent, context, and target resource are evaluated before the tool runs.
• Separate approval paths for higher-risk tools such as delete, export, or code execution.

That approach aligns with the threat model described in NHIMG’s Analysis of Claude Code Security, where a tool’s real risk depends on what it can reach, modify, or reveal once an agent is active. It also matches the direction of the OWASP Top 10 for Agentic Applications 2026, which treats unbounded agent actions as a primary control problem.

For teams building governance, the operative question is not “Is this server approved?” but “Which exact tools are allowed for this task, under what context, and with what revocation path?” These controls tend to break down when teams proxy many tools through a single gateway because the gateway often collapses distinct permissions into one broad allow decision.

Common Variations and Edge Cases

Tighter tool-level approval often increases operational overhead, requiring organisations to balance lower blast radius against more review work and slower onboarding. That tradeoff is real, especially when MCP servers are shared across many agents or departments.

Best practice is evolving for multi-tenant or fast-moving environments. Some teams start with server-level approval for discovery, then move high-risk tools into separate policies once usage patterns are understood. Others apply allowlists only to destructive or egress-capable tools while leaving read-only tools broadly available. The key is to avoid treating “low risk” as a property of the server name instead of the tool behavior.

Edge cases appear when a single tool is safe in one context and dangerous in another. For example, a file-read tool may be acceptable for public documentation but not for regulated data stores, and an export tool may be permissible only with logging and human review. The current guidance suggests context-aware approval is more durable than static server trust, but there is no universal standard for this yet. The strongest programs pair explicit tool classification with continuous monitoring so an approved server cannot quietly expand its effective privileges over time.

Related resources from NHI Mgmt Group

• What breaks when MCP tools are exposed through one shared server?
• What breaks when MCP tools rely on the UI instead of server-side authorization?
• What breaks when an MCP server's tool descriptions do not match its actual actions?
• Why do collaboration tools create such a large secrets risk?