Because the server often executes with its own credentials and network reach, not the caller’s. If the server can invoke downstream systems on behalf of a request, it becomes an authority-bearing mediator rather than a passive connector. That changes governance from simple access control to delegated authority control over credentials, destinations, and request methods.
Why MCP servers become a broker instead of a dumb pipe
An MCP tool server is risky because it often sits between the agent and the target system with its own standing credentials, network path, and protocol permissions. Once the server can choose destinations or methods, it is no longer just relaying requests. It is making access decisions, which means its authorization boundary must be treated like delegated authority, not simple connectivity.
That distinction matters when teams assume the caller’s intent is the same as the server’s authority. The broker can expand, transform, or replay a request in ways the caller never directly sees. In MCP authorization guidance, the design goal is to keep tokens scoped to the protected resource and avoid token passthrough that turns the server into an uncontrolled intermediary.
The practical result is that governance shifts from “can this client reach the server?” to “what can this server do on the client’s behalf, and under what constraints?” That is why broker risk shows up in credentials, downstream reach, request routing, and action authority at the same time. NHIMG’s MCP Security Guide and the AI Agent Identity Security: The 2026 Deployment Guide both frame this as delegated access control, not mere transport design.
Where the broker risk comes from in practice
The risk usually appears when the server holds broader credentials than the calling agent, especially if those credentials can touch email, storage, ticketing, databases, or internal APIs. If the server can invoke multiple tools or downstream systems, it can become a confused deputy: technically acting on a request, but operationally wielding its own privilege set. That is exactly why hosted MCP platforms and shared servers deserve scrutiny.
Broker risk also increases when the server accepts a request and then decides how to satisfy it with its own local state, cached tokens, or preconfigured integrations. A caller may only ask for one action, but the server may perform several. The gap between request intent and execution authority is where overreach, replay, and unintended data movement emerge. NHIMG’s MCP Security Guide covers this pattern alongside token passthrough, gateways, and protected resource metadata.
At the system level, the server is also a concentration point for trust. If one broker is compromised, misconfigured, or overly permissive, multiple downstream systems can be exposed through a single integration path. That is why the problem is not just authentication at the edge. It is authority management across every hop the server can reach.
How to scope MCP tool servers safely
Safe design starts by asking whether the server should ever hold reusable authority at all. If the answer is yes, scope that authority as tightly as possible to one purpose, one environment, and one class of operations. Where possible, use audience-bound or resource-bound credentials instead of general-purpose tokens, and keep the server from forwarding raw caller tokens downstream.
It also helps to separate “connectivity” from “delegation.” A server that can call out to a backend should have explicit destination allow-lists, method restrictions, and clear audit trails for each downstream action. If the server can read and write on behalf of different tools, treat each tool boundary as an authorization boundary. The safer pattern is to make the server accountable for the exact operations it can perform, not for the caller’s broader intent.
For teams building agent integrations, the most useful architecture question is whether the MCP server can be replaced with a narrower gateway or a resource-specific adapter. If not, then the server needs the same scrutiny you would apply to any privileged intermediary: least privilege, short-lived credentials, action logging, and clear revocation paths. RFC 9728 and the MCP authorization specification are useful anchors for that design model.
Risk and Threat Considerations
MCP servers create broker risk because a compromise or misconfiguration can convert one integration into broad downstream abuse. An attacker does not need to break every target system if the server already has reach, reusable tokens, or permissive methods. The danger is privilege amplification through an apparently ordinary tool server.
Failure mechanism: The server’s own authority, token handling, or routing logic is abused to perform actions the caller should not have been able to trigger directly. That can expose secrets, alter records, or relay requests to unintended destinations.
Impact: A single broker flaw can produce cross-system compromise, data exfiltration, unauthorized transactions, or persistence through trusted automation paths. The blast radius is often larger than teams expect because the server is treated as infrastructure, even though it is acting with delegated power.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP servers can overstep delegated authority and misuse tool access. |
| ASI02 — Tool Misuse | MCP tool servers mediate actions and can misuse connected tools or methods. | |
| Recommendation — Constrain tool and downstream privileges so servers cannot exceed delegated intent. Restrict tool invocation paths and validate each action against policy. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Servers choosing downstream methods create function-level authorization risk. |
| Recommendation — Enforce function-level authorization for every downstream operation. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Broker servers need narrowly scoped authority to reduce delegated reach. |
| IA-5 — Authenticator Management | MCP brokers often rely on reusable credentials that need lifecycle control. | |
| Recommendation — Limit each server to the minimum downstream privileges it truly needs. Rotate and protect server credentials to prevent token reuse and abuse. | ||
Practitioner Guidance
What to verify: Confirm which identity the server actually uses for downstream calls, whether it reuses a long-lived token, and whether each backend action is auditable back to a specific request. If you cannot answer those three questions, the server is not yet safe to treat as a neutral middleware component.
Decision rule: If the server can invoke anything more sensitive than read-only lookup, require explicit downstream scoping, short-lived credentials, and destination constraints before production approval. If those controls are not feasible, redesign the integration so the server cannot act as an authority-bearing mediator.
Practitioner takeaway: The core question is not whether the MCP server is trusted, but whether its trust is bounded tightly enough that delegated authority cannot silently become organizational authority.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org