Notifications
Clear all
Topic starter
06/09/2026 3:44 pm
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.
NHIMG editorial — based on content published by LEVO: MCP server security and the runtime control layer for AI agents
By the numbers:
- 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.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What fails when MCP servers are treated like ordinary API gateways?
A: The failure is governance, not connectivity.
Q: Why do MCP-based AI systems complicate access control and governance?
A: MCP-based systems complicate governance because they connect models to tools and data sources dynamically, often across multiple providers and environments.
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
- Map every MCP tool to a named business purpose Require each tool, API, and data source exposed through the MCP layer to have an explicit business purpose, owner, and approved data scope.
- Log the full agent-to-tool transaction path Capture the originating prompt or request, the MCP decision, the exact tool invoked, the target system, and the returned payload.
- Enforce runtime request validation at the MCP boundary Check each request against policy at execution time, not only when the agent is onboarded.
What's in the full article
LEVO's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of MCP request flow from agent prompt to enterprise execution
- Runtime governance and monitoring capabilities described for MCP-driven interactions
- Threat detection and execution protection details for unauthorized tool use and data access
- Operational examples of how the platform enforces policy at the MCP boundary
👉 Read LEVO's analysis of MCP server security and AI agent governance →
MCP servers and AI agent access control: are your runtime controls ready?
Explore further
06/09/2026 3:45 pm
MCP server governance is now identity governance, not just application plumbing. When an AI agent reaches enterprise systems only through a governed execution layer, the control question shifts from interface design to delegated authority. That makes runtime access, tool permissioning, and auditability part of the identity programme, not a separate AI ops concern. Practitioners should treat MCP access as a governed identity path with real accountability.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, which leaves a large compliance and investigation gap.
A question worth separating out:
Q: How should security teams govern MCP model-agent interactions?
A: Security teams should govern MCP by treating the model-to-agent boundary as an authorization point, not just an integration point. That means strict schemas, validation gateways, scoped credentials, freshness checks, and logging on every privileged request. If the agent can touch production systems, the model must never be able to turn raw text directly into action.
👉 Read our full editorial: MCP servers are becoming the control point for AI agent access
