Because risk often sits in the access path, not the model. An agent using an overprivileged or third-party MCP server can read data, trigger workflows or modify records through a path that looks legitimate at the protocol level. That makes permission scope and server trust the practical control points.
Why MCP Servers Change the Risk Model
MCP servers are not just integration plumbing. They sit between an agent and the tools, data, and actions the agent can reach, so they become a control point for what the agent can see and do. If that server is overly broad, poorly governed, or trusted by default, the risk comes from delegated access, not model compromise.
The practical issue is that protocol-level legitimacy can hide operational risk. A request may look valid to the MCP layer while still enabling data access, record changes, or workflow execution that the underlying model itself was never meant to have.
That is why server scope, trust boundaries, and authorization design matter more than the model brand or model integrity alone. In practice, the server becomes part of the attack surface as soon as it can proxy authority into systems that hold sensitive data or business logic.
Where the Exposure Actually Sits
An MCP server can increase exposure through overprivilege, token forwarding, or weak separation between the agent and the downstream resource. When the server can act as a trusted intermediary, it may inherit permissions that are far wider than the agent’s task requires.
This is especially important when a server is third-party or remotely hosted. A server that appears to be a normal integration point may still read sensitive content, invoke privileged operations, or expand access across multiple systems if its credentials and authorization model are not tightly constrained. The MCP Security Guide is useful because it covers the authorization model, token passthrough, confused deputy risk, and the trust decisions that shape real exposure.
The other hidden risk is composability. Once an MCP server can call tools on behalf of an agent, the blast radius is no longer limited to one prompt or one model response. It includes whatever the server can reach, which can be far broader than the originating user intended.
What Practitioners Should Check Before Trusting an MCP Server
Use the access path as the unit of review, not the model. If the server can observe, retrieve, or mutate data, verify exactly which resources it can reach, which credentials it uses, and whether its permissions are narrowed to a specific task, tenant, or environment.
- Confirm whether the server exchanges scoped tokens or simply relays bearer tokens downstream.
- Check whether the server can enumerate resources beyond the user’s immediate request.
- Review whether tool actions are bounded by explicit authorization rather than implied trust.
- Separate production, staging, and local integrations so one server cannot bridge environments without a deliberate control decision.
For authentication and delegated access patterns, the NHI Authentication Guide helps frame the credential and trust model, while the MCP authorization specification shows the direction current protocol guidance is taking around audience-bound tokens and no token passthrough.
If the server is supplied by a third party or distributed through a registry, treat supply-chain trust as part of the access decision. A compromised or malicious server can behave correctly at the protocol layer and still exfiltrate data or trigger unsafe actions once it receives legitimate credentials. The distinction between model compromise and server compromise is operationally important because the latter can be enough to cause real loss.
Risk and Threat Considerations
MCP servers increase risk because they concentrate authority in an intermediary that may be easier to abuse than the model itself. An attacker does not need to break the model if they can influence the server, the server’s credentials, or the data path it controls.
Failure mechanism: Excessive server permissions, token passthrough, or weak trust boundaries allow the server to act with broader authority than the request truly requires, turning a normal integration into a high-value abuse path.
Impact: The result can be unauthorized data disclosure, silent workflow manipulation, record changes, or lateral movement into downstream systems even when the model remains uncompromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, 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 Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP servers rely on delegated auth and scoped tokens to control access. |
| NHI-05 — Overprivileged NHI | The risk comes from servers that can do more than the task requires. | |
| NHI-03 — Vulnerable Third-Party NHI | Third-party MCP servers can become the abuse path even if the model is sound. | |
| Recommendation — Use scoped, audience-bound auth and reject token passthrough for MCP servers. Reduce MCP server permissions to the minimum actions and resources required. Assess hosted MCP servers as third-party trust dependencies before granting access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | An MCP server can amplify delegated authority into unauthorized actions. |
| ASI02 — Tool Misuse | MCP servers expose tool execution paths that can be abused for harmful actions. | |
| Recommendation — Constrain agent-server authority so tool use cannot exceed approved privilege. Restrict tool exposure and validate each action before execution. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | MCP servers should only hold the access needed for each tool action. |
| IA-5 — Authenticator Management | Server-held tokens and secrets are the mechanism that makes the access path risky. | |
| Recommendation — Apply least privilege to every MCP server credential and downstream permission. Rotate and protect MCP server credentials with strict lifecycle controls. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | MCP trust should be continuously verified rather than assumed by protocol position. |
| Recommendation — Treat each MCP request as untrusted until policy validates the path and action. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP tools can expose functions that must be individually authorized. |
| API8 — Security Misconfiguration | Weak server configuration can expose broader access than intended. | |
| Recommendation — Authorize each MCP tool call by function, not by generic server trust. Harden MCP server configuration and disable unnecessary capabilities. | ||
Practitioner Guidance
What to prioritise: Review the MCP server as a privileged integration endpoint, not as a harmless transport layer. The first question is whether its effective authority matches the smallest task it must perform.
What to verify: Confirm that every server credential is scoped, rotated, and isolated from unrelated systems, and that any third-party server is treated as an external trust dependency rather than an extension of the model.
Common mistake: Teams often harden the model while leaving the server path overprivileged. That reverses the real risk order, because the delegated access path is what can create impact first.
Practitioner takeaway: For MCP, the security question is not whether the model was hacked, it is whether the server can be trusted to hold and spend authority without exceeding the task it was given.
Related resources from NHI Mgmt Group
- Why do AI applications create access control risk even when the underlying model is not compromised?
- Why do MCP deployments create security risk even when the agent model itself is not compromised?
- Why do autonomous agents increase identity risk even when the model is not compromised?
- Why do non-human identities increase zero trust risk?