When AI agents connect to untrusted MCP servers, the organization can inherit supply chain risk through the integration path. That can expose tools, credentials, or data to misuse, and it can create a route for malicious or vulnerable components to influence agent behavior. Security teams should treat server trust, isolation, and approval as explicit controls.
Why Untrusted MCP Servers Change the Risk Profile
When an AI agent talks to an MCP server, the server is not just a passive integration point. It can shape what tools are exposed, what context is returned, and how the agent behaves next. That means an untrusted server can become a supply chain dependency for decisions, not only for data transport. In practice, the concern is less about “using MCP” in the abstract and more about whether the server is allowed to influence actions, permissions, or secrets with enough trust to cause harm.
That risk becomes sharper because MCP deployments can carry sensitive material in configuration and tool definitions. NHIMG research on The State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which shows how quickly an integration path can turn into an exposure path when trust is assumed too early.
Security teams often underestimate that the server’s output can be operationally consequential even when it looks like ordinary protocol data. In practice, many failures surface only after the agent has already been allowed to act on unvetted server responses.
How It Works in Practice
An AI agent connected to an untrusted MCP server usually inherits three classes of exposure. First, the server may enumerate or proxy tools that the agent then invokes with excessive scope. Second, the server may return manipulated context, metadata, or instructions that steer the agent toward unsafe actions. Third, if the integration is poorly designed, the server may gain a path to tokens, secrets, or other sensitive material that the agent can access during its workflow.
This is why the control question is not merely “Is the server reachable?” but “What authority does it gain through the agent?” Best practice is evolving toward explicit approval of servers, narrow tool allowlists, short-lived access, and isolation between the agent runtime and any external plugin boundary. For background on the broader agentic threat model, the OWASP Top 10 for Agentic Applications 2026 is useful because it frames how tool use, instruction handling, and autonomy interact when an agent is allowed to act on external inputs.
A practical implementation pattern is to treat each MCP server like an untrusted dependency until it passes review, then constrain it further:
- Separate discovery, approval, and production use so a server cannot move straight from test to trusted execution.
- Scope tools to the smallest viable action set, rather than exposing a broad connector and hoping policy will compensate later.
- Use ephemeral credentials and rotate any secret that the agent can reach through that server path.
- Log tool calls, returned context, and downstream actions so you can reconstruct whether the server influenced a harmful decision.
Where teams need a governance lens for autonomous behaviour, the NIST AI Risk Management Framework helps structure the discussion around measurement, oversight, and accountability rather than treating the integration as a simple API connection. These controls tend to break down when a server is allowed to supply both context and execution paths in a highly automated workflow, because the agent can amplify a small trust failure into a broad action failure.
Common Variations and Edge Cases
Tighter server approval often increases friction for developers and operators, so teams have to balance agility against blast-radius control. Not every MCP server is equally dangerous: a read-only knowledge source is different from a server that can trigger actions, mutate records, or surface secrets. Current guidance suggests treating the latter category as materially higher risk, especially where the agent can chain multiple tools into a single autonomous workflow.
One important edge case is prompt-style manipulation through server-provided content. Even if a server never directly handles secrets, it can still shape the agent’s next move by presenting misleading context, stale data, or hidden instructions. Another edge case is indirect privilege escalation: a seemingly minor connector can become dangerous when the agent has broad ambient access elsewhere in the environment. In those cases, the security issue is not the server alone, but the combination of server trust and agent authority.
For practitioners, the rule is to classify MCP servers by what they can influence, not just by who operates them. When the server can affect execution, it should be governed like a privileged dependency rather than a convenience integration.
Risk and Threat Considerations
Untrusted MCP servers create a compound exposure: supply chain dependency, tool abuse, and data leakage can all occur through the same integration path. The main danger is that the server may be able to alter agent decisions while also expanding the set of reachable tools and sensitive context.
Failure mechanism: A malicious or compromised server can return manipulated context, expose overbroad tools, or entice the agent into actions that exceed intended scope. If secrets or tokens are available in that workflow, the server path can also become a credential exposure route.
Impact: The agent may execute unsafe actions, disclose sensitive data, or perform operations outside policy, which undermines trust in the whole automation chain and makes incident reconstruction harder.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Tool and Plugin Abuse | Untrusted MCP servers can abuse tool exposure and steer agent actions. |
| Recommendation — Restrict exposed tools and validate every external server before agent execution. | ||
| NIST AI RMF | GOV-2 — Governance and Accountability | Server trust and approval are governance decisions for autonomous systems. |
| Recommendation — Define ownership, approval, and auditability for every agent-server integration. | ||
| CSA MAESTRO | TR-2 — Third-Party and Supply Chain Trust | MCP servers are external dependencies that can introduce supply-chain risk. |
| Recommendation — Classify external agent dependencies and isolate them before granting production trust. | ||
| CIS Controls v8 | 6 — Access Control Management | MCP server trust affects tool scope, secrets exposure, and access boundaries. |
| Recommendation — Limit access scope and revoke any excessive credentials tied to server integrations. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorization Management | Agent-server links need least-privilege authorization and controlled access. |
| Recommendation — Enforce least privilege on agent-linked services and review permissions regularly. | ||
Practitioner Guidance
What to prioritise: Treat server trust and tool scope as separate decisions. A server may be acceptable for low-risk context retrieval but still be inappropriate for any workflow that can trigger write actions, credential use, or cross-system propagation.
Decision rule: If the server can influence what the agent does, what it can reach, or what secrets it can see, require explicit approval, isolation, and revocation paths before production use.
What to verify: Confirm the server’s provenance, the exact tools exposed, the credential boundaries, and whether logging captures both the server response and the agent’s downstream action. If you cannot reconstruct influence, you do not really have control.
Practitioner takeaway: The real control objective is not to make every MCP server “trusted”; it is to ensure that untrusted servers cannot expand the agent’s authority faster than the organisation can observe, constrain, and revoke it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
