TL;DR: MCP servers sit between AI agents and enterprise systems, governing tool use, data retrieval, and action execution at runtime, according to LEVO. That makes the control layer itself the security problem: without visibility, policy enforcement, and governance designed for agent-driven execution, access paths expand faster than traditional infrastructure tools can follow.
Editorial analysis by NHI Mgmt Group, based on content published by LEVO: “What Is MCP Server in API and AI Security”.
Key questions
Q: What breaks when organisations rely on access control alone for MCP-connected AI agents?
A: Access control alone cannot see what comes back in a tool response.
Q: Why do insecure MCP servers create such a high-risk path for AI agent abuse?
A: Insecure MCP servers can turn a browser session into a bridge into local tools, files, and commands.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Practitioner guidance
- Define the MCP server as a governed control plane Map every agent-to-system path through the MCP layer and require policy enforcement, logging, and exception handling there rather than in downstream applications.
- Tighten delegated access scope for agent workflows Limit each MCP-connected agent to the smallest set of APIs, databases, and actions needed for the specific workflow it is allowed to perform.
- Inspect runtime requests before execution Add validation for the tool requested, the data object targeted, and the action outcome expected before the MCP server executes the call.
Bottom line: MCP servers shift security attention to the runtime layer where AI agents actually request tools, data, and actions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
MCP is becoming the policy boundary for machine-initiated work: Once AI agents are allowed to select tools and trigger actions at runtime, the security problem moves from application access to execution governance. The enterprise no longer needs only an API gateway or a network control, it needs a place where the request itself can be judged before action occurs. That makes MCP the control point identity teams must understand, because it concentrates both access and accountability in one runtime layer.
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.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations treat MCP servers as part of NHI governance or as an AI integration issue?
A: They should treat MCP servers as part of NHI governance because they mediate machine-driven access, delegated execution, and credentialed system interaction. The AI label describes the actor's reasoning, but the security problem is the non-human identity path into enterprise systems. Governance should follow the access path, not the product category.
👉 Read our full editorial: MCP servers are becoming the control point for AI agent access