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.
Editorial analysis by NHI Mgmt Group, based on content published by Lasso Security: “Top MCP Security Risks: Critical Vulnerabilities in GenAI-Powered Apps”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: MCP environments create a shared trust plane where tool identity, orchestration privilege, and execution boundaries can fail together.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 hours ago by NHI Mgmt Group
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
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.
A few things that frame the 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.
- Generative AI use specifically increased from 33% in 2023 to 79% in 2025, according to McKinsey’s Global Surveys on the State of AI.
A question worth separating out:
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.
👉 Read our full editorial: MCP server security risks expose weak identity and privilege controls
This post was modified 3 hours ago by NHI Mgmt Group