MCP server security risks expose weak identity and privilege controls

At a glance

What this is: This is an analysis of critical MCP server security risks, showing that tool trust, privilege concentration, and context isolation are the main failure points in GenAI-native apps.

Why it matters: It matters because IAM, NHI, and platform teams must govern tool identities, access scoping, and execution boundaries before MCP-style orchestration becomes the default control plane for AI-enabled workflows.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Lasso Security's analysis of top MCP security risks in GenAI apps

Context

MCP security is the problem of governing how tools, models, and agents are allowed to discover and use data and actions inside GenAI applications. The article argues that traditional security controls fall short because they assume stable applications, while MCP environments create dynamic tool chains with shifting trust and privilege boundaries.

For identity teams, the core issue is not just application hardening. It is controlling non-human identities, tool registration, and orchestrator authority so that a compromised component cannot inherit broad access across the workflow.

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 architectures increase the risk of privilege sprawl?

A: MCP architectures increase privilege sprawl because a central orchestrator can accumulate access, context, and execution authority across multiple tools. That broad trust boundary makes one compromised component able to influence many others. Security teams should limit downstream permissions, isolate execution, and avoid designing the orchestrator as a universal authority.

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.

Q: How should organisations respond to shadow capabilities in MCP tools?

A: Organisations should assume that declared tool purpose may not reflect full tool behaviour. Hidden functions can create unreviewed network access, privileged actions, or delayed malicious activation. The right response is behavioural testing, dependency review, and stricter offboarding for tools whose runtime actions exceed their approved scope.

Technical breakdown

Supply chain compromise in MCP server stacks

MCP stacks inherit the same software supply chain exposure seen in other distributed systems, but the impact is sharper because plugins, dependencies, and servers can all participate in tool execution. Masquerading, typosquatting, dependency confusion, and trojan packages are relevant here because the attacker does not need to break the model itself. They only need to land malicious code in a component that the orchestrator treats as trusted. Once that happens, the component can execute with inherited privileges and persist inside normal workflows.

Practical implication: verify package provenance, isolate tool runtimes, and treat MCP components as privileged software dependencies, not harmless extensions.

Single point of privilege in the orchestrator

A central MCP orchestrator can simplify automation, but it also concentrates access, context, and execution authority in one control plane. That makes it a high-value identity object, not just an integration layer. If the orchestrator can call multiple tools and pass context between them, then compromise of one attached tool can expand into broader workflow control. The architecture turns delegated trust into a blast-radius problem because privilege boundaries are enforced by design quality rather than by default isolation.

Practical implication: separate tool execution environments and scope orchestrator permissions so one compromised tool cannot inherit unrelated access.

Context bleeding across sessions and users

Persistent memory, embeddings, and shared vector stores create a stateful layer that can outlive the session that created it. In MCP-based apps, that state can leak from one user or workflow into another if isolation is weak. The security issue is not just confidentiality. It is that cross-session context can alter model behaviour, steer tool selection, and surface data that never should have been in scope for the next interaction. This is an identity and data boundary problem at the same time.

Practical implication: isolate memory stores per tenant or session and test for cross-user context reuse before production rollout.

Threat narrative

Attacker objective: The attacker aims to control GenAI workflow execution while exfiltrating data, abusing inherited privilege, or disrupting service through cost exhaustion.

1. Entry occurs when a malicious package, poisoned tool, or spoofed tool name is accepted into the MCP stack as a trusted component.
2. Credential access or abuse follows when the compromised component inherits orchestrator privileges, reads embedded secrets, or invokes downstream tools with broad context.
3. Impact lands when the attacker extracts sensitive data, manipulates workflow execution, or exhausts budget through denial-of-wallet abuse.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool trust collapses when MCP components become identity-bearing execution points. MCP security is not only about code hygiene or prompt safety. Once a tool can be registered, invoked, and passed context by an orchestrator, it behaves like a non-human identity with operational authority. That means trust can no longer be inferred from a tool's declared purpose alone. Practitioners should treat tool identity as a governed asset, not a convenience layer.

Single point of privilege is the most dangerous governance assumption in MCP architectures. The article shows that central orchestration concentrates access and context in one place, which is exactly where traditional least-privilege thinking becomes brittle. If one trusted component can expand into multiple downstream actions, then the failure mode is not one account being abused, but one authority boundary being too wide. The implication is that blast radius must be designed into the architecture, not assumed from policy.

Shadow capabilities create an identity blind spot because declared tool purpose and actual behaviour diverge. A tool that contains hidden functions or delayed malicious behaviour undermines registration-based trust models and static review processes. This is a governance problem, not just a detection problem, because approval was granted on incomplete behavioural knowledge. Practitioners need to recognise that MCP control states can drift after onboarding, so inventory alone is not enough.

Context isolation is becoming an identity control, not just a privacy control. When memory persists across users or sessions, the next actor may inherit data and behavioural cues that were never intended for it. That breaks both confidentiality and authorisation boundaries in GenAI-native apps. The practical conclusion is that session context must be governed with the same seriousness as credentials and permissions.

OWASP NHI Top 10 style thinking applies here because MCP tools are non-human identities in practice. Even when a component is not a classic service account, it still carries identity, privilege, and lifecycle risk. The field should stop treating AI toolchains as a separate category and start governing them through NHI principles: scoping, isolation, provenance, and revocation.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly configuration files become a secret sprawl problem when MCP tooling is adopted at scale.
• For the wider identity picture, see Ultimate Guide to NHIs , Regulatory and Audit Perspectives for how governance and audit requirements change when non-human credentials become the control point.

What this signals

Shadow capability governance is emerging as a practical control gap for GenAI-native environments because declared tool purpose is no longer a reliable proxy for runtime behaviour. That means inventory, approval, and lifecycle records must be paired with behavioural validation if teams want to keep tool identities within boundary.

With 92% of organisations saying governing AI agents is critical and only 44% having policies in place, per AI Agents: The New Attack Surface report, the market signal is clear: teams are still underbuilding governance around dynamic non-human execution. MCP is one of the places that gap will surface first.

The next phase of programme maturity is not only tighter secrets handling. It is proving that tool identity, context, and execution scope are continuously aligned, because MCP systems fail when those three drift apart.

For practitioners

• Scope every MCP tool permission Define the smallest workable permission set for each tool, then validate that the orchestrator cannot inherit broader access than the task requires. Review whether tool permissions are documented and enforced at registration time, not just during runtime checks.
• Isolate orchestration from downstream execution Run tools in separate execution environments and prevent a single orchestrator from becoming the default authority across unrelated systems. The goal is to stop one compromised component from inheriting access to every connected service.
• Validate tool provenance and package integrity Require signed packages, controlled repositories, and review of dependency chains for every MCP component. Pay special attention to typosquatting, dependency confusion, and disguised tool names that can enter trusted workflows unnoticed.
• Separate memory by tenant and session Do not allow shared vector stores or global buffers to persist sensitive context across users. Test for context bleeding before production and treat memory isolation as a control that limits both disclosure and behavioural contamination.

Key takeaways

• MCP security failures are identity failures as much as application failures, because tools and orchestrators now carry privilege, context, and execution authority.
• The scale of the problem is already visible in secret exposure and missing access scoping, which means many deployments are operating with weak default trust assumptions.
• Practitioners should govern tool provenance, privilege boundaries, and memory isolation together, because treating any one of them as separate leaves the attack surface intact.

Key terms

• Model Context Protocol: A standard that lets models, agents, and applications connect to tools and data sources in a structured way. In practice, it creates a governed execution layer where tool identity, access scope, and context flow must be managed together to prevent privilege sprawl and data leakage.
• 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.
• Context bleeding: The unintended transfer of prompts, embeddings, memory, or session state between users or workflows. It is both a privacy and governance failure because the next session can inherit data or behavioural cues that were never authorised for it, especially in shared GenAI infrastructure.
• Shadow capabilities: Undocumented or hidden functions inside a tool that go beyond its declared purpose. These capabilities create governance blind spots because approval decisions are based on incomplete behaviour, making post-approval testing and runtime validation essential for controlling real-world risk.

Deepen your knowledge

MCP server security risks and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for GenAI-native applications, it is a practical place to start.

This post draws on content published by Lasso Security: Top MCP Security Risks: Critical Vulnerabilities in GenAI-Powered Apps. Read the original.