Notifications
Clear all
Topic starter
20/08/2026 5:50 pm
TL;DR: Model Context Protocol traffic bypasses legacy DLP, IAM, and SIEM because it looks like legitimate API activity, transforms sensitive data semantically, and moves exfiltration into tool calls, according to Nightfall. The control gap is not visibility at the perimeter but protocol-aware governance that preserves identity, context, and policy at the agent boundary.
NHIMG editorial — based on content published by Nightfall: How does MCP bypass traditional security tools?
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern MCP access in agentic workflows?
A: Security teams should govern MCP access as delegated identity, not simple application connectivity.
Q: Why do traditional DLP tools miss data movement in MCP sessions?
A: Traditional DLP expects visible files, obvious uploads, or stable data patterns.
Q: What breaks when identity systems stay stateful in agent environments?
A: Stateful identity creates pressure to retain sessions, reuse tokens, and centralise decisions.
Practitioner guidance
- Inventory every MCP connection path Continuously discover MCP servers across desktop tools, IDEs, internal agents, and local extensions, then map each one to an owner, data class, and approved purpose.
- Bind agent actions to human initiators Log which user invoked which agent, which tool was called, what data came back, and whether the agent acted under a static service account, a delegated token, or a scoped session.
- Enforce policy at tool-call time Block or redact sensitive responses when the tool output would violate classification rules, even if the request itself looked legitimate or the destination was trusted.
What's in the full article
Nightfall's full research covers the operational detail this post intentionally leaves for the source:
- Protocol-level inspection examples for MCP tool calls, prompts, and responses in live environments
- Discovery patterns for finding shadow MCP servers across desktops, IDEs, and custom agent platforms
- Policy enforcement approaches for blocking or redacting sensitive content at the tool-call boundary
- Audit trail design guidance for linking human initiators to agent actions and downstream data exposure
👉 Read Nightfall's analysis of how MCP bypasses traditional security tools →
MCP security and the governance gap traditional controls miss?
Explore further
20/08/2026 6:29 pm
Identity has become the missing control plane in MCP security. The central problem is not only that MCP creates new data paths, but that it breaks attribution between the human requester and the tool-executing agent. When access logs record only a service account, IAM and PAM lose the evidence needed for review, investigation, and revocation. Practitioners should treat agent identity as a governed asset, not a transport detail.
A question worth separating out:
Q: How do organisations reduce shadow MCP server risk?
A: By inventorying every MCP server, including local and developer-run instances, and tying each one to a known owner and approved identity source. If a server can be created outside central governance, it should be treated as an unmanaged NHI path until proven otherwise.
👉 Read our full editorial: MCP bypasses legacy DLP and IAM because identity breaks
