Notifications
Clear all
Topic starter
06/06/2026 11:08 am
TL;DR: MCP servers are becoming the connective layer for enterprise agentic AI, yet the security model has not kept pace: WitnessAI says more than 10,000 public servers are active, 40% of enterprise apps will feature task-specific AI agents in 2026, and 30% of vendors are expected to ship MCP servers. The gap is no longer theoretical because visibility, attribution, and runtime control are still missing where agents can already act.
NHIMG editorial — based on content published by WitnessAI: Model Context Protocol (MCP) servers and enterprise AI security risks
By the numbers:
- 40% of enterprise apps are expected to feature task-specific AI agents in 2026.
- 30% of vendors are expected to launch their own MCP servers.
Questions worth separating out
Q: How should security teams govern MCP server access in enterprise AI environments?
A: Start with discovery, then scope, then enforcement.
Q: Why do MCP servers create risk for NHI and IAM programmes?
A: Because they turn agent connectivity into a reusable access layer that can expose databases, APIs, and internal systems through a single protocol.
Q: What breaks when AI agents use MCP without strong scope enforcement?
A: Least privilege breaks in practice because the agent can execute far more than the business task requires.
Practitioner guidance
- Build a complete MCP inventory first Catalog every MCP server, every connected agent, and every backend system they can touch.
- Map tool scope to task scope Review each MCP server for read, write, and admin exposure, then remove any capability that is not required for the agent's actual business purpose.
- Require runtime attribution for every agent action Preserve the initiating human identity, tool-call sequence, and final action outcome in immutable logs so security and compliance teams can reconstruct what happened without relying on post-hoc inference.
What's in the full article
WitnessAI's full article covers the operational detail this post intentionally leaves for the source:
- Specific breakdown of the seven MCP server security risks and how each appears in agent workflows
- Implementation details for discovery, runtime enforcement, and immutable audit logging across MCP traffic
- Examples of how a unified policy layer can classify and control both human and autonomous agent activity
- WitnessAI's product architecture for observe, control, protect, and witness attack capabilities
👉 Read WitnessAI's analysis of MCP server security risks for enterprise AI agents →
MCP server security: what enterprise IAM teams need to know?
Explore further
06/06/2026 11:46 am
Visibility debt is the core MCP governance failure: MCP risk starts before any exploit because enterprises often cannot see which servers exist, which agents use them, or which identities initiated the action. That is not a monitoring nuisance, it is a governance failure that prevents scoping, review, and attribution from functioning as designed. In OWASP NHI terms, the environment has already lost the ability to govern the non-human identity surface. Practitioners should treat undiscovered MCP connections as unmanaged identity infrastructure, not as a tooling side issue.
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.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the same research.
A question worth separating out:
Q: Who is accountable when an AI agent takes action through an MCP server?
A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.
👉 Read our full editorial: MCP server security gaps are widening as agent adoption grows
