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.
Editorial analysis by NHI Mgmt Group, based on content published by WitnessAI: “7 MCP Server Security Risks Every Enterprise AI Leader Needs to Address”.
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.
Key questions
Q: What is the biggest governance failure when MCP servers are added to enterprise AI workflows?
A: The biggest failure is assuming that a standard protocol creates safe access by itself.
Q: Why do MCP servers increase risk even when the underlying model is not compromised?
A: Because risk often sits in the access path, not the model.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose.
Practitioner guidance
- Inventory every MCP server connection Build a complete register of all MCP servers, including those created by engineering teams or embedded in developer tooling, and keep it current as part of identity governance.
- Bind every agent action to a human identity Require immutable attribution for each tool call and store enough runtime context to trace multi-agent chains back to the initiating person.
- Enforce runtime blocking for unsafe tool calls Inspect tool-call sequences, parameters and server responses in-line so privilege escalation or unauthorised actions can be stopped before execution.
Bottom line: MCP servers extend enterprise AI from text generation into direct system access, which makes them an identity and governance problem as much as a platform choice.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
MCP creates an identity governance problem, not just an AI integration problem. The article is right to frame MCP servers as the connective layer for enterprise agentic AI because that is where permissions, auditability and accountability converge. Once an agent can invoke tools directly, the control question is no longer whether the model is safe to prompt but whether the access path itself is governed as a production identity surface. Practitioners should treat MCP as part of the identity plane, not a peripheral developer convenience.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
A question worth separating out:
Q: How should security teams decide whether to allow third-party MCP servers?
A: Treat them like privileged integrations rather than ordinary plugins. Teams should review what systems the server can reach, whether its code has been assessed, how access can be revoked, and what audit evidence will exist if the server is used in a consequential workflow.
👉 Read our full editorial: MCP server security gaps are widening as agent adoption grows