Why do poorly controlled MCP integrations increase the risk of data leakage and lateral movement?

Why This Matters for Security Teams

Poorly controlled MCP integrations are risky because they make a tool boundary look safe when it is actually a data path and an execution path. If an agent can query internal systems through MCP, the main failure is rarely the protocol itself. The failure is weak scoping, weak output filtering, and overly broad trust in what the agent is allowed to retrieve and forward.

That matters because agents do not behave like fixed applications. Their requests change with context, prompts, and downstream tool results, so static IAM assumptions break quickly. Guidance from the OWASP Agentic AI Top 10 and NHIMG research such as the 52 NHI Breaches Analysis both point to the same operational reality: once a tool can retrieve sensitive context, the exposure risk depends on how tightly that context is governed at runtime.

NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results reports that 72% of organisations have experienced or suspect a breach of non-human identities, which helps explain why MCP is now treated as an access-control problem, not just an integration pattern. In practice, many security teams encounter leakage only after a tool response has already been copied into logs, tickets, or chat history rather than through intentional review.

How It Works in Practice

MCP becomes dangerous when the agent receives more data than it needs to complete a task, or when the tool response is passed through without validation. A secure pattern starts with workload identity for the agent, then tight authorisation at the tool level, and finally response shaping before anything is returned to the model or user. The objective is not only to stop direct exfiltration, but also to prevent the agent from using one tool’s output to discover the next.

Current best practice is evolving toward runtime policy evaluation, where the request is judged in context rather than by a fixed role alone. That means the system should consider what the agent is trying to do, which data source it is touching, and whether the output contains secrets, internal identifiers, or infrastructure details. Frameworks like the NIST Cybersecurity Framework 2.0 support this kind of layered control, while the OWASP NHI Top 10 highlights the need to constrain non-human access paths with least privilege.

• Issue short-lived credentials per task instead of sharing long-lived tokens across tools.
• Restrict each MCP server to a narrow data scope and a narrow action scope.
• Redact or classify tool output before it reaches the agent context window.
• Log tool calls, returned fields, and downstream propagation to support investigation.

This approach works best when the MCP server, the model, and the downstream application are all under the same policy envelope. These controls tend to break down in loosely coupled environments where multiple teams publish tools independently because the authorization boundary becomes inconsistent across services.

Common Variations and Edge Cases

Tighter MCP controls often increase integration overhead, requiring organisations to balance safety against developer speed and tool usability. That tradeoff becomes especially visible when agents need to chain several internal systems in one workflow, because each added hop creates another place where sensitive context can be exposed or misused.

There is no universal standard for how much context an agent should retain, so current guidance suggests limiting persistence wherever possible and using just-in-time access for higher-risk tools. The Guide to the Secret Sprawl Challenge is relevant here because MCP often inherits the same failure mode as secrets sprawl: too many credentials, too many places to inspect, and too many opportunities to reuse privilege.

Edge cases include read-only tools that still leak enough metadata to support lateral movement, and “safe” administrative tools that return environment details an attacker can use later. The Anthropic AI-orchestrated cyber espionage campaign report is a reminder that automated workflows can amplify reconnaissance and chaining even when no single action looks catastrophic.

For that reason, security teams should treat MCP responses as potentially sensitive data, not neutral transport. In practice, the hardest failures appear when internal tooling is trusted as harmless and only the agent layer is scrutinised after data has already moved sideways.

Related resources from NHI Mgmt Group

• Why do autonomous agents create more lateral movement risk?
• Why do poorly governed NHIs increase lateral movement risk?
• Why do MCP servers increase lateral movement risk?
• Why do cross-vendor integrations increase lateral movement risk?