Where do MCP platforms usually fail in practice?

They fail when they expose shared runtime surfaces, weakly scoped tool permissions, or vendor dependencies in the critical path. Those gaps expand lateral movement risk and make it harder to prove who or what accessed which tool. The result is a larger identity blast radius than most teams expect.

Why This Matters for Security Teams

MCP platforms usually fail for the same reason many identity programs fail: they concentrate too much capability behind a shared runtime and then assume trust can be managed later. In practice, that creates a broad blast radius when tool access, connector permissions, or model-to-tool invocation are not tightly isolated. The issue is not just uptime or integration quality; it is whether an attacker can turn one compromised agent, token, or plugin into access across the whole environment.

This is why guidance from OWASP Top 10 for Agentic Applications 2026 and NHIMG research such as LLMjacking: How Attackers Hijack AI Using Compromised NHIs both point to the same operational risk: shared access paths are easy to overextend and hard to audit after the fact. The same pattern shows up in agent programs too, where AI Agents: The New Attack Surface report found that many organisations still cannot fully track what their agents access.

In practice, many security teams only discover the scope problem after an assistant, connector, or service token has already touched data or tools it was never meant to reach.

How It Works in Practice

MCP itself is not the failure point. The failure usually happens in the platform design wrapped around it: one broker, many tools, weak tenant separation, and permissions that are broader than the task requires. If a platform treats every agent or client as a reusable trusted caller, an attacker who gains one foothold can often reuse that trust across multiple tools, data sources, or environments.

The practical fix is to stop thinking in static role terms and start thinking in task terms. That means workload identity for the calling entity, short-lived credentials for each session or action, and policy evaluation at request time rather than pre-approved tool access lists. Current best practice is evolving toward intent-aware authorisation, but there is no universal standard for this yet. A useful reference point is the NIST SP 800-53 Rev 5 Security and Privacy Controls, which supports stronger access governance even if it does not define MCP-specific patterns.

• Issue per-task credentials with a short TTL, then revoke them automatically when the task ends.
• Bind tool access to workload identity, not to a shared platform token reused across agents.
• Separate read, write, and admin capabilities so one tool cannot silently become a pivot into others.
• Log every tool invocation with principal, context, and outcome so access can be reconstructed later.

NHIMG analysis in the Ultimate Guide to NHIs – The NHI Market reinforces that identity sprawl is not just a human IAM issue; it becomes more dangerous when machine identities are allowed to accumulate standing access. These controls tend to break down when MCP brokers sit behind legacy service accounts because the platform inherits the weakest credentialing model in the stack.

Common Variations and Edge Cases

Tighter MCP control often increases operational overhead, requiring organisations to balance lower blast radius against slower integration and more complex policy management. That tradeoff becomes visible in environments with many plugins, rapid experimentation, or vendor-managed connectors where teams want fast onboarding more than strict isolation.

Some teams try to compensate with perimeter controls, but that only partially helps because MCP failures are often internal trust failures. If a connector can call multiple tools under one identity, network segmentation does little once the request is already authenticated. Similarly, if the runtime depends on a third-party control plane, availability and authorization can become coupled in a way that makes incident response harder than expected. The Analysis of Claude Code Security illustrates how tool-assisted AI workflows can expand risk when execution authority is broader than intended.

In mature environments, the answer is usually not to ban MCP, but to constrain it: isolate tenants, minimize standing trust, and treat every tool call as a privileged action. Where the runtime must support many autonomous agents and shared connectors, current guidance suggests pairing policy-as-code with continuous audit, because static allowlists become stale as soon as tool catalogs or agent behaviour change.

Related resources from NHI Mgmt Group

• How can organizations secure their MCP server credentials?
• Why is OAuth considered a better alternative for MCP servers?
• Why is it crucial to adopt new authentication methods in MCP usage?
• Why do complex IAM platforms often fail in practice?