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.
At a glance
What this is: This analysis argues that MCP servers are the governance layer for AI agent access because they mediate tool use, data retrieval, and action execution at runtime.
Why it matters: It matters because IAM, PAM, and AI governance teams need controls that inspect and constrain runtime agent behaviour, not just pre-authorised integrations.
Context
MCP servers are the runtime integration layer that sits between AI agents and enterprise systems. In practical terms, they determine how an agent reaches APIs, databases, and internal services, and whether that interaction is governed, logged, and constrained.
The governance gap is straightforward: static infrastructure controls were built for predefined application flows, not for agents that select actions at runtime. Once the control point moves into the MCP layer, identity, authorisation, and monitoring all have to operate on the agent's execution path rather than the surrounding infrastructure.
For teams building AI-enabled workflows, the question is no longer whether agents can connect to tools. The real issue is whether that connection is mediated by an execution layer that can enforce policy before data is retrieved or an action is taken.
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. An agent may be allowed to query a page or database, yet still receive sensitive values, embedded files, or comments that should not enter the model. Without content inspection, teams lose the ability to redact, block, or prove what data was exposed during the interaction.
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. Because MCP often connects agents to business systems over long-lived sessions, a rebinding attack can silently redirect trusted traffic to localhost. If authentication, origin checks, and session binding are weak, attackers can execute commands or exfiltrate sensitive data without needing a full system compromise.
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. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.
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.
Technical breakdown
Why MCP servers become the execution control point
An MCP server implements the Model Context Protocol by sitting between an AI agent and the enterprise systems it needs to use. Instead of allowing the agent to call APIs or databases directly, the server receives a structured request, evaluates it, and executes the system action on the agent's behalf. That separation matters because the decision to act, the tool used, and the timing of execution all happen at runtime. The MCP layer therefore becomes the place where access policy, logging, and request validation either exist or fail. In identity terms, the server is not just plumbing. It is the policy boundary for machine-initiated work.
Practical implication: treat the MCP server as a governed execution tier, not a passive integration component.
Why static security controls miss agent-driven interaction
Traditional infrastructure security assumes stable application behaviour, known pathways, and relatively predictable transaction patterns. MCP-driven interaction breaks that assumption because the agent decides which tool to invoke after interpreting runtime context. That means the same user request can produce different downstream system calls, data access patterns, or action sequences. Static allowlists and perimeter controls can still be useful, but they do not explain why an individual call occurred or whether the request was appropriate for the agent's current task. The control problem shifts from protecting the system edge to inspecting the runtime request itself.
Practical implication: build controls that inspect and approve runtime agent requests, not just network or application entry points.
How delegated execution changes identity and data risk
When an MCP server executes actions on behalf of an agent, it becomes a delegated authority layer. That creates a concentrated identity risk because the server can inherit broad access across multiple systems while the agent's actual intent changes from task to task. The result is an amplified blast radius if the server is mis-scoped, over-permissioned, or allowed to retrieve data without clear purpose binding. In practice, the security issue is not only authentication. It is how much authority the delegated execution layer can exercise before the enterprise loses meaningful control over what was accessed and why.
Practical implication: scope delegated execution by task and enforce purpose-bound access at the MCP layer.
Breaches seen in the wild
- Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group 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.
Traditional access models assume the actor is known before the action begins: Least privilege is usually defined at provisioning time, but agent-driven execution is dynamic and context-sensitive. The article's core point is that static entitlements do not explain which system call will happen next, or why. Practitioners should treat that as a governance mismatch, not a tooling gap alone.
Runtime visibility is now an identity requirement, not a monitoring nice-to-have: If the organisation cannot see what the agent asked for, what the MCP server executed, and which data was returned, it cannot enforce meaningful control. That shifts AI security from perimeter enforcement to request-level governance, which is where identity, authorisation, and audit all converge.
Potential over-privilege in delegated execution is the real scaling risk: MCP servers can centralise access across APIs, databases, and internal services, which is useful operationally but dangerous when the delegated layer is broader than the task. The result is identity concentration inside the runtime tier, a pattern that deserves the same scrutiny PAM teams apply to human privileged access.
Runtime governance for MCP is an NHI discipline, not a generic AI theme: The subject here is not model intelligence but non-human access to enterprise systems through a governed execution path. That means the right questions are inventory, scope, logging, and revocation for machine-driven access paths. Practitioners should assess MCP as part of the NHI control plane, not as an isolated AI feature set.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Runtime control is the category shift: MCP forces security teams to treat the execution layer as the new policy boundary for AI agents. That means identity governance, approval logic, and auditability need to attach to the request path, not just the surrounding infrastructure.
Ephemeral agent access changes the review model: Access review processes were built to certify privileges that persist long enough to be inspected. When agent-to-system interaction is mediated by MCP, the more relevant question is whether the request was appropriate before execution and whether the returned data was authorised for that task.
Levo's 2026 statistics show why over-permissioned AI access is already a programme-level issue: Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. That gap is large enough to make runtime scoping and logging board-level controls, not optional hardening.
For practitioners
- 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.
- Log purpose and outcome for every agent action Capture why the agent requested access, what the MCP server executed, and which response data was returned so reviewers can trace the full transaction.
- Treat MCP credentials as non-human identities Inventory any keys, tokens, or certificates used by MCP infrastructure and place them under the same ownership, rotation, and offboarding discipline as other NHI secrets.
Key takeaways
- MCP servers shift security attention to the runtime layer where AI agents actually request tools, data, and actions.
- The main risk is delegated execution without sufficient visibility, which makes static infrastructure controls incomplete for agent-driven access.
- Treat MCP governance as an identity and access problem, with scope, logging, and ownership enforced at the point of execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP server access depends on machine authentication and delegated trust at runtime. |
| NHI-05 — Overprivileged NHI | The article centres on delegated execution becoming too broadly scoped across enterprise systems. | |
| NHI-10 — Human Use of NHI | AI agents are operating through non-human identity paths that require explicit governance and ownership. | |
| Recommendation — Harden authentication for MCP-connected identities and validate every machine-to-machine request path. Reduce MCP-connected privilege scope to the minimum set of actions needed for each workflow. Assign ownership and revocation discipline to every MCP-facing non-human identity. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The core risk is agent-driven runtime execution using delegated privileges beyond intended scope. |
| Recommendation — Map MCP execution paths to privilege-abuse scenarios and inspect agent requests before action. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MCP infrastructure relies on credentials, tokens, and certificates that need lifecycle control. |
| Recommendation — Apply authenticator management to rotate and revoke MCP-related credentials on a defined schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about authorising and constraining machine access to enterprise systems. |
| Recommendation — Align MCP policies to least-privilege entitlements and review effective access regularly. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles — Never trust, always verify | Runtime agent access requires continuous verification of each action, not implicit trust in the integration layer. |
| Recommendation — Verify each MCP request as if it were untrusted and enforce policy at the point of execution. | ||
Key terms
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
- Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
- Agent-to-System Interaction: Agent-to-system interaction is the exchange in which an AI agent requests tools, data, or actions from enterprise systems. The security concern is not the conversation itself, but whether each request is authorised, visible, and attributable before execution occurs.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org