MCP server security risks expose weak identity and privilege controls

At a glance

What this is: This is an analysis of MCP-specific security risks in GenAI-powered applications, with the central finding that orchestration and shared tool access collapse several identity and privilege boundaries into one failure domain.

Why it matters: It matters because IAM, PAM, and NHI programmes need to govern tool access, orchestration privilege, and session context as a single control problem, not as separate application concerns.

Context

Model Context Protocol, or MCP, standardises how tools, agents, and models connect inside GenAI-native applications. That standardisation also creates a new identity problem, because the same orchestration layer can carry trust, privilege, and execution across multiple tools.

The security gap is not just in the model or the tool catalogue. It is in the way MCP environments concentrate authority, accept tools as trusted by default, and allow compromised components to influence downstream execution and data handling.

Key questions

Q: What breaks when MCP tools are treated as trusted by default?

A: When MCP tools are trusted by default, a poisoned or spoofed component can inherit privileged access, manipulate outputs, or expose secrets without crossing a traditional perimeter. The failure is not only technical compromise. It is the assumption that registration equals trust. Teams should verify provenance, scope permissions tightly, and review tool behaviour continuously.

Q: Why do MCP orchestration layers increase blast radius?

A: They increase blast radius because one orchestrator can carry access to many tools, contexts, and data sources. If the orchestrator or one attached tool is compromised, the attacker may pivot across the workflow instead of needing separate compromise paths for each system.

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: What do security teams get wrong about context isolation in GenAI apps?

A: Teams often treat context isolation as a data-handling issue only, but in GenAI apps it is also an identity boundary. Shared memory, embeddings, and session state can leak data and influence behaviour across users. Organisations should isolate memory per tenant or session and test for cross-session reuse before deployment.

Technical breakdown

Supply chain compromise in MCP servers and plugins

MCP servers, plugins, and dependencies extend the attack surface beyond the application runtime into build, distribution, and deployment. If a package is masqueraded, typosquatted, confused against a public repository, or otherwise trojanised, the malicious component can enter the environment before any runtime policy sees it. In MCP-based systems, that matters because the server is often treated as a trusted tool source rather than a governed identity boundary. Once that trust is granted, the compromised component can inherit execution paths, data access, and downstream influence.

Practical implication: treat MCP server acquisition and dependency provenance as part of the identity perimeter, not just software supply chain hygiene.

Tool poisoning and name spoofing inside orchestration flows

Tool poisoning changes a registered tool so it behaves maliciously only under certain conditions, which makes test-time validation unreliable. Name spoofing exploits loose matching or semantic similarity so an agent or orchestrator invokes the wrong tool while believing it selected the right one. In both cases, the failure is not simply malware delivery. It is identity ambiguity at the tool layer, where invocation trust is too broad and the system cannot prove the exact tool instance it meant to call.

Practical implication: enforce exact tool identity, explicit allowlists, and stronger registration controls for every tool exposed to an MCP orchestrator.

Single point of privilege in MCP orchestration

A central orchestrator that can manage access, context, and execution across multiple environments creates a dense privilege concentration point. If one tool in that chain is compromised, the attacker may pivot through the orchestrator to other tools and inherit broad access without having to breach each target separately. The architecture turns a local compromise into workflow-level impact because privilege is shared across the orchestration fabric instead of being isolated per tool, per session, or per task.

Practical implication: split orchestration privilege into narrower execution zones so one compromised tool cannot inherit control over the rest of the workflow.

Threat narrative

Attacker objective: The attacker wants to turn a trusted MCP component or orchestrator into a privileged execution path that enables data theft, workflow manipulation, or persistent control.

1. Entry occurs through supply chain compromise, tool tampering, or registration of a spoofed MCP component that appears trusted enough to enter the workflow.
2. Credential and privilege abuse follow when the compromised tool inherits the orchestrator's access to context, data, or downstream tools and can operate beyond its intended scope.
3. Impact arrives as silent data extraction, workflow compromise, hidden backdoors, or cost-driven disruption through repeated expensive operations.

Breaches seen in the wild

• Hugging Face API tokens exposed 2023: Lasso Security found 1,681 live Hugging Face tokens in public code, 655 with write access, reaching 723 organisations including Meta; all were revoked.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP turns tool trust into identity trust. The article's core lesson is that once tools are invoked through a shared orchestration layer, tool identity becomes access identity. That creates a control problem that looks like application integration on the surface but behaves like delegated privilege in practice. Practitioners should stop treating MCP registration as metadata and start treating it as an authorisation boundary.

Single-point orchestration creates privilege concentration that traditional IAM does not model well. Centralised control makes it easy to route work, but it also makes compromise far more expensive because one trusted component can reach many others. The article shows why least privilege is not just about the tool itself, but about how much downstream authority the orchestrator can inherit. The practitioner implication is to reduce blast radius before expanding automation.

Tool poisoning and name spoofing expose a governance gap, not just a detection gap. If the platform cannot prove which exact tool instance was invoked, then matching, registration, and review controls are too loose for the operational risk. This is where NHI governance and agentic workflow control start to converge: identity at the tool layer must be exact, not approximate. Teams should rework tool approval, inventory, and invocation policy around verifiable identity, not human-readable similarity.

Context bleeding shows that session boundaries are now security boundaries. Persistent memory, shared buffers, and global context stores can move sensitive data between users or tasks even when the original application logic seems isolated. That means privacy, identity, and execution governance all fail together when context is reused without strong isolation. Practitioners should treat memory segregation as part of access control, not a separate model issue.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Generative AI use specifically increased from 33% in 2023 to 79% in 2025, according to McKinsey’s Global Surveys on the State of AI.
• Read next: MCP Security Guide

What this signals

MCP-specific identity risk is now an orchestration problem, not a narrow application problem. When tools, memory, and execution all sit inside the same trust boundary, the control point moves from model safety to identity governance. That is why MCP security should be evaluated alongside NHI inventory, privilege scope, and delegated execution policy rather than as a standalone GenAI issue.

Tool provenance and exact invocation need to become operational requirements. Loose matching, undocumented capabilities, and delayed activation all create conditions where a tool is trusted before it is understood. The governance lesson is straightforward: if a workflow cannot prove the exact tool instance it invoked, it does not have enough control for production use.

Secret exposure in protocol configurations is already measurable at scale. 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. That figure suggests the first priority is not theoretical policy design but rapid inventory, inspection, and containment of live MCP secrets.

For practitioners

• Verify MCP server provenance Require signed or otherwise verifiable provenance for MCP servers, plugins, and dependencies before they are allowed into production orchestration paths.
• Enforce exact tool identity Replace fuzzy or semantic tool matching with explicit tool identifiers, strict allowlists, and approval rules for every sensitive invocation path.
• Separate orchestrator privilege from tool privilege Break central orchestration authority into narrower execution scopes so one compromised tool cannot inherit access to unrelated tools or environments.
• Isolate session memory and context stores Segregate prompt history, embeddings, and shared buffers by user, task, or trust domain so one session cannot bleed into another.
• Audit shadow capabilities before rollout Test tools for undocumented behaviours, hidden functions, and delayed activation patterns before they are trusted in live workflows.

Key takeaways

• MCP environments create a shared trust plane where tool identity, orchestration privilege, and execution boundaries can fail together.
• The article points to supply chain compromise, tool spoofing, prompt injection, context bleeding, and privilege concentration as the main risk patterns.
• Security teams need tighter tool provenance, exact invocation controls, and memory isolation before broadening MCP deployment.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Context bleed: The unintentional movement of sensitive information or trust from one step in a workflow into another step that should not receive it. In MCP and agentic systems, context bleed often appears when static access rules fail to notice that the request has become more sensitive.
• Single point of privilege: A design pattern where one orchestrator or control component holds enough authority to act across many systems. In MCP environments, that concentration can turn one compromise into broad workflow control, so privilege boundaries must be enforced across the full tool chain rather than assumed centrally.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.