Unvetted MCP servers can inherit broad tool reach while hiding what data they read, what they transmit, and what decisions they influence. Unlike a conventional integration with clear boundaries, they sit inside an agent workflow that can browse, write, and act in sequence. That makes the risk cumulative, because one connection can expand the agent’s authority across multiple systems.
Why This Matters for Security Teams
Unvetted MCP servers are risky because they do not behave like ordinary point-to-point integrations. A conventional integration usually has a defined purpose, a narrow data path, and a known trust boundary. By contrast, an MCP server can expose tools that an agent calls dynamically, which makes scope, authority, and data handling harder to reason about during review. That is why governance has to focus on tool exposure, not just API connectivity.
Security teams often miss that the main failure is not a single malicious action, but the accumulation of ordinary actions across a workflow. An agent may read a record, enrich it, and then trigger a downstream system without a human ever seeing the full chain. Guidance from the OWASP Agentic AI Top 10 reinforces that agentic systems need explicit controls around tool access, instruction handling, and output validation. In practice, many security teams encounter the real problem only after an agent has already used a poorly governed server to touch data or systems outside the original intent of the integration.
How It Works in Practice
MCP servers increase risk when they are introduced without a strong approval process for tools, scopes, and data handling. The protocol can make integrations faster to build, but speed also reduces the natural friction that normally forces architecture review. A normal integration might be reviewed as a single application-to-application link. An MCP-enabled workflow may instead allow an agent to discover tools at runtime, select them based on prompts, and chain them in ways that were not explicitly modelled during security design.
Practitioners should treat each MCP server as an authority-bearing component. That means verifying what it can read, write, invoke, and return, then mapping those actions to business approval and logging requirements. Useful controls include:
- Inventory every server and every tool it exposes.
- Restrict tool scopes to the minimum required for the use case.
- Separate read, write, and execute functions where possible.
- Log prompts, tool calls, returned data, and downstream actions.
- Require provenance and change control for third-party or community servers.
Security review should also consider prompt injection, data exfiltration, and indirect command execution, because an agent may follow instructions embedded in content retrieved through a tool. The OWASP Top 10 for Agentic Applications 2026 is useful here because it frames the problem as an agent governance issue, not just an API security issue. For broader operational control mapping, the NIST Cybersecurity Framework 2.0 helps teams tie these controls to asset management, access management, logging, and response.
In mature environments, the most effective pattern is to approve MCP servers only after they are assigned to a named business purpose, a named owner, and a defined set of allowed tools. These controls tend to break down when servers are self-registered by developers or third parties because their authority grows faster than the review process can track.
Common Variations and Edge Cases
Tighter MCP governance often increases friction for developers and can slow experimentation, so organisations have to balance innovation against the need to contain agent authority. That tradeoff is real, especially when the use case is internal productivity automation and teams want rapid rollout.
Best practice is evolving on how much isolation is enough for low-risk servers, and there is no universal standard for this yet. Some environments can tolerate low-impact read-only tools with limited data sensitivity, but the risk changes quickly when a server can write records, trigger workflows, or access secrets. The difference between a safe pilot and an unsafe deployment is often not the protocol itself, but the absence of a control plane that can revoke access, review tool behaviour, and detect misuse.
Edge cases also appear when an MCP server is technically legitimate but operationally overpowered. For example, a finance or support workflow may need access to multiple systems, yet every additional permission widens the blast radius if the agent is manipulated or the server is compromised. In these cases, the right question is not whether the server is approved in principle, but whether its tool set still matches the minimum authority needed for the current business function. Organisations that skip that check often discover the issue only after a harmless-looking automation has crossed a boundary it was never meant to cross.
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, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | TBD | Agentic tool exposure and instruction handling are central to MCP server risk. |
| NIST CSF 2.0 | PR.AA, PR.AC, DE.CM | Maps MCP governance to asset, access, and monitoring controls. |
| NIST AI RMF | Risk governance is needed when AI systems can select and chain external tools. | |
| MITRE ATLAS | AML.TA0002 | Prompt injection and tool abuse map to adversarial manipulation of AI workflows. |
| CSA MAESTRO | MAESTRO helps structure agentic control placement across tools and orchestration layers. |
Model MCP abuse paths and test for prompt injection, exfiltration, and unauthorized action chaining.
Related resources from NHI Mgmt Group
- Why do MCP servers create more NHI risk than ordinary service integrations?
- Why do MCP servers create more NHI risk than ordinary API integrations?
- Why do remote MCP servers create more identity governance risk than local ones?
- Why do MCP deployments create NHI risk beyond normal application security?
