TL;DR: AI agent and MCP workflows now move sensitive data at machine speed, and legacy DLP, alert-only controls, and network-centric inspection leave exposure windows open across SaaS, endpoints, browsers, and agent traffic, according to Nightfall’s 2026 analysis. The core issue is not visibility alone but whether security teams can block, redact, and govern data in runtime as agents act.
NHIMG editorial — based on content published by Nightfall: Best AI Agent Security and MCP Security Platforms for AI Agent Red Teaming in 2026
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 agentic AI as it moves into production?
A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature.
Q: Why do public MCP servers create risk for enterprise identity programmes?
A: Because they extend trust into third-party tool endpoints that may be poorly maintained, over-permissioned, or carrying embedded secrets.
Q: What do security teams get wrong about agent red teaming?
A: The biggest mistake is assuming a one-time prompt test gives meaningful coverage.
Practitioner guidance
- Implement runtime enforcement for agent data flows Prioritise controls that can block, redact, quarantine, or revoke data while the AI agent is still in-session, especially across prompts, file transfers, and browser actions.
- Scope MCP tool permissions to least privilege Review every MCP server connection for explicit tool scoping, and remove broad or inherited permissions that allow agents to reach systems beyond their intended task.
- Separate corporate and personal sessions Detect and enforce account-boundary rules so that uploads, downloads, and prompt activity in personal sessions cannot reach managed storage or approved enterprise workflows.
What's in the full article
Nightfall's full research covers the operational detail this post intentionally leaves for the source:
- Product-specific deployment guidance for SaaS, endpoint, browser, and MCP coverage.
- Control examples for block, redact, revoke, quarantine, and encrypt actions in live workflows.
- Implementation notes on AI-native detection, session differentiation, and policy tuning.
- Customer-facing workflow coverage details for Copilot, Claude, Gemini, and other AI tools.
👉 Read Nightfall's full analysis of AI agent and MCP security platforms →
AI agent and MCP security: are your data controls keeping up?
Explore further
Runtime enforcement is now the decisive control plane for AI agent data security. The article correctly places the emphasis on what happens during the transaction, not after the fact. Agentic workflows compress decision, retrieval, and transfer into one execution path, so a delayed response is often a failed response. For IAM and NHI programmes, that means policy has to follow the session, the tool call, and the data movement together.
A question worth separating out:
Q: How can organisations prove their AI controls are actually working?
A: Look for evidence that policy decisions are logged, sensitive prompts are being redacted or blocked when required, and approved AI interactions are traceable by identity and business context. Effective programmes produce audit-ready records, not just policy text. If the control cannot explain what happened in a session, it is not operational enough.
👉 Read our full editorial: AI agent and MCP security need runtime data controls, not legacy DLP