Why does MCP increase risk even when zero trust and IAM are in place?

Why MCP Raises Risk Beyond Access Control

MCP increases risk because it adds a layer where the real security decision is not just who may connect, but what the connected agent can choose to do through exposed tools. zero trust and IAM still matter, but they primarily govern access boundaries. An MCP workflow can remain formally authenticated and authorised while still producing an unsafe action because the dangerous step happens after access has already been granted.

That distinction is the core issue: MCP expands the number of tool surfaces, the amount of runtime context the agent can interpret, and the chances that a malicious prompt or poisoned tool description changes behaviour. The relevant control question becomes whether each action is bounded, attributable, and policy checked, not only whether the caller has a valid identity.

MCP also weakens the old assumption that a trusted integration is a safe integration. Once tools are discovered dynamically, an agent may encounter capabilities that were not part of the original design review, and identity controls will not necessarily see the semantic jump from "allowed to call" to "allowed to do this specific thing."

Where Zero Trust and IAM Stop Helping Enough

Zero trust is still the right baseline for transport, segmentation, and continuous verification, and NHIMG’s Zero Trust for AI Agents is useful for that model. The limit is that zero trust does not by itself evaluate whether the current tool invocation is appropriate, high impact, or manipulated by adversarial input.

IAM has a similar ceiling. It answers whether the principal is known, whether a token is valid, and whether an identity has some permission set. It does not automatically answer whether the agent should be allowed to combine tools, escalate from one contextual cue to another, or complete a harmful sequence that still fits inside the granted permissions.

This is why MCP security needs action-level controls as well as identity-level controls. The protocol creates a mediation point between authentication and execution, so the real control objective is to narrow what the agent can do per request, per tool, and per context. NHIMG’s MCP Security Guide and the MCP authorization specification both reflect that shift toward audience-bound tokens, no token passthrough, and clearer server-side authorisation boundaries.

What Practitioners Should Treat as the Real Control Problem

The practical control problem is action governance under dynamic tool discovery. A secure design has to assume the agent may be influenced at runtime, may encounter unfamiliar tools, and may follow instructions that are syntactically valid but operationally unsafe. That means review and policy must focus on tool scope, command shape, data reach, and blast radius, not only login success or network trust.

• Prefer explicit per-tool and per-action policy over broad delegated access.
• Keep high-risk tools behind human approval or separate execution paths.
• Limit token scope so a compromise in one tool cannot be reused elsewhere.
• Log the prompt, tool selection, and resulting action together so review is possible.

For agentic systems, NHIMG’s Zero Trust for AI Agents and OWASP Agentic Applications Top 10 are especially relevant because they frame privilege abuse, tool misuse, and agent trust as runtime security problems, not just identity problems. The OWASP Agentic AI Top 10 also reinforces that identity and privilege abuse inside agentic workflows is a separate risk class from ordinary access control.

Risk and Threat Considerations

MCP raises the odds of control bypass through trust abuse, prompt injection, and tool confusion because the agent is often acting on instructions that look legitimate to infrastructure controls but are semantically malicious. The danger is not that IAM fails outright, but that it succeeds for the wrong transaction while the agent performs a harmful action inside its granted envelope.

Failure mechanism: An attacker influences the agent’s input, tool discovery, or tool selection so that a permitted identity is used to trigger an unsafe tool call, a sensitive data flow, or an unintended side effect.

Impact: Organisations can see unauthorised data exposure, destructive actions, privilege misuse, or chained abuse across tools even though authentication, network policy, and baseline zero trust checks all appear to pass.

Practitioner Guidance

What to prioritise: Focus first on the action layer, not the identity layer. If the MCP server or agent can trigger high-impact effects, treat that as a separate control boundary and require explicit policy around each sensitive tool.

What to verify: Confirm that every tool has a defined purpose, scope, and denial path. If a tool can reach production data, systems of record, or external side effects, verify that the agent cannot invoke it on the basis of untrusted context alone.

Common mistake: Teams often assume that a valid token and a locked-down network path are enough. In MCP environments, that assumption fails when the agent itself becomes the decision surface and the attacker can shape the request that reaches the tool.

Practitioner takeaway: Treat MCP as a policy and execution problem as much as an access problem, because the highest-risk failures happen after identity has already been accepted.

Related resources from NHI Mgmt Group

• Why do agentic systems increase identity security risk even when IAM is already in place?
• Why do non-human identities increase zero trust risk?
• When does zero trust IAM create more friction than risk reduction?
• Why do AI agents and MCP integrations increase IAM risk?