Notifications
Clear all
Topic starter
20/08/2026 5:49 pm
TL;DR: MCP has become a primary integration layer for AI agents while legacy DLP cannot see the protocol, leaving secrets, corporate IP, and overbroad tool use largely ungoverned, according to Nightfall. The core problem is not just visibility but the mismatch between agent-driven tool calls and controls built for files, browsers, and emails.
NHIMG editorial — based on content published by Nightfall: MCP Security in 2026: 5 Risks Hiding in Your AI Agent Stack
By the numbers:
- 81% of organisations saw a year-over-year surge in, AI-service credential leaks.
- 18% of MCP server deployments implement any form, form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: Why do MCP-based agents create more risk than ordinary API integrations?
A: Because the agent is choosing actions, chaining tools, and preserving context across steps.
Q: What breaks when organisations rely on legacy DLP for MCP traffic?
A: Legacy DLP misses the protocol because MCP traffic is assembled by the agent and sent as tool calls rather than files or browser uploads.
Practitioner guidance
- Inventory every MCP server and connector Build an authoritative list of all approved MCP servers, the tools they expose, and the identities they inherit.
- Enforce per-tool allow and deny rules Allow a connector broadly only when you can still block high-risk actions such as branch creation, record deletion, or message posting.
- Inspect and redact protocol payloads Move content inspection to the MCP transport layer so secrets, source code, and business documents are screened before the request leaves the endpoint.
What's in the full article
Nightfall's full report covers the operational detail this post intentionally leaves for the source:
- Detailed breakdowns of each MCP risk category and how the vendor maps them to OWASP MCP guidance
- Examples of protocol-level observability and content inspection controls for agent traffic
- Operational commentary on how Nightfall positions MCP security within its broader data protection platform
- The report's framing of the five risks as they apply to enterprise data security teams
👉 Read Nightfall's analysis of MCP security risks in agentic data environments →
MCP security risks are widening: what should IAM teams do now?
Explore further
20/08/2026 6:29 pm
MCP security is now an identity governance problem, not only a data loss problem. The critical risk is that a non-human identity can move from authorised access to unauthorised data movement inside the same protocol session. That collapses the distinction between identity control and exfiltration control, because the tool call itself becomes the transport. Practitioners should treat MCP as an identity-bearing control plane, not a peripheral integration detail.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: What should teams do when an MCP server gains new tools after review?
A: Reassess the approval state immediately and treat the added capability as a new entitlement, not a routine update. A tool addition can change the effective blast radius of the connected identity, so the server should be quarantined until the new surface is reviewed and re-authorised.
👉 Read our full editorial: MCP security risks in 2026 expose a DLP visibility gap
