MCP governance gaps widen as AI agents scale across enterprises

At a glance

What this is: MintMCP's market analysis says MCP governance is becoming an enterprise identity problem as AI agents, tools, and credentials spread faster than security teams can track them.

Why it matters: IAM, PAM, and NHI teams need to treat MCP connectivity as governed access infrastructure, not just a routing layer, because auditability and privilege scope are now part of the control problem.

Context

Model Context Protocol gives AI clients a standard way to reach enterprise tools, but that standardisation also exposes a governance gap: security teams often cannot see which tools are called, which credentials are used, or what actions an agent takes. For enterprise identity programmes, the problem is no longer just access to an application, but access exercised by software that can move across tools and environments faster than manual review cycles can keep up.

MintMCP frames the market around that gap: AI agents are already spreading across employee laptops and development workflows, while governance models still assume named users, stable tool lists, and centrally visible sessions. That assumption breaks when the same agent can act through multiple connectors, multiple credentials, and multiple deployment paths in one operating model.

Key questions

Q: What breaks when MCP access is not centrally enforced?

A: When MCP access is not centrally enforced, agents can bypass the sanctioned protocol and reach the same data through alternative connectors or direct application paths. That breaks policy consistency, weakens auditability, and leaves security teams with multiple uncontrolled routes to the same backend system.

Q: Why do AI agents change the identity model for enterprise tools?

A: AI agents can choose tools, issue requests, and continue execution without a human sitting in the loop for every action. That means identity has to follow the agent as a governed principal, not just the employee who deployed it. Otherwise, access reviews, approvals, and accountability all collapse into indirect inference.

Q: Should security teams use API gateways alone to control MCP access?

A: No. API gateways can still validate schemas and rate-limit calls, but they do not judge agent intent, blended authority, or context integrity. MCP needs identity-first enforcement at runtime, with policy decisions tied to the agent, the human-derived attributes it carries, and the specific tool invocation.

Q: What operational controls do enterprises need before scaling autonomous agents?

A: Enterprises need scoped credentials, attributable audit trails, approved tool sets, and a defined revocation path before they expand agent use. Without those controls, growth simply increases the number of unmanaged access paths. The safer test is whether governance still works when the number of agents moves from a handful to dozens or more.

Technical breakdown

Why MCP routing alone does not solve governance

MCP standardises how AI clients connect to tools, but routing is only one layer of control. The practical governance problem is attribution: who or what requested a tool, which identity authorised it, and what data or action followed. In this market, a gateway can route traffic while still leaving the organisation blind to privilege scope, tool selection, and evidence quality. That is why MCP governance quickly becomes an identity problem rather than just a network or API problem. See the MCP Security Guide.

Practical implication: Treat MCP routing as a transport layer and design separate controls for identity, authorisation, logging, and review.

How agent identity changes the control model

An AI agent that can select tools at runtime needs a distinct identity model, because user delegation alone does not preserve accountability. When each agent is issued its own credentials, scoped permissions, and audit trail, the organisation can bound access by principal instead of by borrowed human session. That shifts governance from passive observation to explicit issuance, revocation, and attribution. For regulated environments, the key design question is whether the agent is a proxy for the user or a governed principal in its own right. See the AI Agent Authorisation Guide.

Practical implication: Define whether each agent is a separate principal and issue credentials, permissions, and logging accordingly.

Why hosted connectors and policy engines still leave enterprise gaps

Hosted connector runtimes and policy engines reduce operational overhead, but they do not automatically close governance gaps created by distributed deployment models. A policy engine can enforce rules only where it is in the path, and a hosted connector still needs clear lifecycle ownership, change control, and evidence retention. Enterprises adopting MCP at scale need to know where policy decisions are made, where logs are retained, and which layer is accountable when a connector or agent behaves unexpectedly.

Practical implication: Map every MCP control point to an accountable owner and confirm where policy, logs, and lifecycle management actually reside.

Threat narrative

Attacker objective: The objective is to exploit opaque agent access paths to reach enterprise tools, credentials, or data without reliable attribution or oversight.

1. Entry begins when AI agents are granted access to enterprise tools through MCP-connected clients and local or hosted connectors.
2. Escalation occurs when those agents reuse or inherit credentials without clear visibility into which tool calls or actions they make.
3. Impact follows when security teams cannot reconstruct the action chain, limiting their ability to contain misuse, prove accountability, or satisfy audit requirements.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

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 governance is becoming an identity architecture problem, not a gateway problem. The market conversation often starts with routing, but the real control gap is attribution across tools, credentials, and actions. When enterprises cannot say which principal did what through which connector, the governance model has already failed. The practical conclusion is that MCP control planes must be judged by identity fidelity, not by transport features alone.

Agent identity must be treated as a first-class governance object. AI agents are no longer just extensions of human sessions once they receive their own credentials, scoped permissions, and audit trails. That changes the unit of control from the employee to the software principal, which is a major shift for PAM, IGA, and NHI programmes. The right question is no longer how to observe usage after the fact, but how to make agent identity reviewable at issuance time.

Curated tool surfaces are a governance mechanism, not merely a product design choice. A Virtual MCP model with approved connectors and role-bound access reduces ambiguity in the same way a narrow entitlement set reduces blast radius. The upside is clearer administration and fewer uncontrolled tool paths; the downside is that organisations must keep the curated surface aligned with real work or users will route around it. The practitioner lesson is to govern the tool surface as tightly as the credentials behind it.

Open source does not remove governance responsibility, it relocates it. Self-hosted gateways and API management stacks can provide flexibility, but they shift infrastructure, compliance, and monitoring obligations back to the organisation. That matters because AI agent programmes often expand faster than the operations model behind them. The issue is not whether the stack is open or managed, but whether the operating model can still answer who has access, under what policy, and with what evidence.

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.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Identity governance has to move from user-centred review to agent-centred issuance. Access reviews assume a stable subject with durable entitlements, but autonomous agents can be created, scoped, and retired in much shorter cycles than human accounts. That shifts the real control point to provisioning, delegation, and revocation rather than periodic review.

Curated tool surfaces will become a control boundary for agentic systems. The more AI clients spread across development and business workflows, the more organisations will need a bounded set of connectors and policies that define what each agent may touch. That boundary will matter as much as the credentials behind it.

Nearly one in five organisations give AI systems dramatically more access than human employees, according to the 2026 Infrastructure Identity Survey. That level of privilege inflation means many programmes are still treating AI access as an exception instead of a governed identity class.

For practitioners

• Define the governing principal for every AI agent Decide whether each agent is a separate identity, a delegated human session, or a shared service principal, then align credentials, permissions, and audit expectations to that model.
• Separate transport controls from identity controls Use MCP gateways for routing, but require a second control layer for authorisation, logging, and revocation so access decisions do not disappear into the network path.
• Curate the tool surface before scaling access Limit each agent or role to a known set of connectors and approved actions so that runtime policy can enforce a bounded and reviewable capability set.
• Make auditability part of deployment design Require attributable logs, retained policy decisions, and a clear owner for each connector or gateway so compliance evidence exists before the first production rollout.

Key takeaways

• MCP adoption is exposing a governance gap where teams cannot reliably see which tools, credentials, and actions an AI agent uses.
• The biggest architectural issue is attribution, because routing alone does not create identity evidence or accountability.
• Enterprises should separate transport control from identity control and treat AI agents as governed principals before scaling access.

Related NHI Mgmt Group resources: MCP Security Guide · AI Agent Authorisation Guide · Zero Trust for AI Agents

Key terms

• MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Virtual MCP: Virtual MCP is a curated access layer that exposes selected tool definitions through role-based endpoints instead of giving every client direct access to every available connector. It helps teams reduce tool sprawl, approve capabilities before use, and present a narrower, policy-controlled surface to agents. This supports safer deployment of enterprise tool access.
• Tool Surface: The tool surface is the set of commands, APIs and connected services an AI agent can invoke at runtime. It is a governance boundary because each tool expands what the agent can do, and therefore expands what an attacker can abuse if they gain control of the runtime.

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.