Notifications
Clear all
Topic starter
10/06/2026 12:56 am
TL;DR: MCP-based apps expose supply chain, tool poisoning, spoofing, prompt injection, privilege concentration, and context bleeding risks that traditional security models miss, according to Lasso Security. The underlying problem is that shared tools and orchestrators turn identity, trust, and execution boundaries into a single failure domain.
NHIMG editorial — based on content published by Lasso Security: Top MCP Security Risks: Critical Vulnerabilities in GenAI-Powered Apps
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Isolate orchestration from downstream execution Run tools in separate execution environments and prevent a single orchestrator from becoming the default authority across unrelated systems.
- Validate tool provenance and package integrity Require signed packages, controlled repositories, and review of dependency chains for every MCP component.
What's in the full article
Lasso Security's full article covers the operational detail this post intentionally leaves for the source:
- Threat-by-threat breakdown of the ten MCP security risks and how each one manifests in GenAI-native apps
- Detailed examples of supply chain, prompt injection, and context bleeding failures inside MCP-based workflows
- The source article's own mitigation framing for tool verification, prompt sanitisation, memory isolation, and orchestration governance
- The vendor's explanation of how Denial of Wallet attacks translate cost exhaustion into service disruption
👉 Read Lasso Security's analysis of top MCP security risks in GenAI apps →
MCP security risks: what identity teams need to fix now?
Explore further
11/06/2026 2:32 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server security risks expose weak identity and privilege controls
12/06/2026 4:06 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server security risks expose weak identity and privilege controls
