MCP servers create new governance gaps for enterprise AI access

At a glance

What this is: This is an explainer on MCP servers, showing how the protocol standardizes AI-to-tool connectivity and where enterprise governance starts to break down at scale.

Why it matters: It matters because the same control gaps that affect service accounts and workload identities now appear in AI application access paths, forcing IAM, PAM, and NHI teams to rethink auth, routing, and auditability.

👉 Read Kong's guide to MCP servers for enterprise AI

Context

Model Context Protocol, or MCP, gives AI applications a standard way to discover and invoke external capabilities instead of relying on bespoke connectors for every system. In practice, that turns tool access into an identity and authorization problem because the AI client, not just the application owner, becomes part of the trust chain.

The governance issue appears when MCP moves from a single developer setup to a fleet of servers across databases, SaaS tools, and internal services. At that point, credential sprawl, uneven access policy, and weak visibility look much more like non-human identity management than ordinary application integration.

Key questions

Q: How should security teams govern access to MCP servers in production?

A: Treat MCP servers as part of the non-human identity estate. Security teams should assign ownership, scope every credential, log every tool invocation, and enforce centralized policy for discovery and routing. If access cannot be enumerated, rotated, and audited, the deployment is not ready for production use.

Q: Why do MCP servers create new risk for IAM and NHI programmes?

A: Because they multiply credentials, authorization rules, and telemetry points across many connected systems. That creates identity sprawl, uneven privilege management, and weak visibility. The governance problem is not the protocol itself, but the number of independently managed trust relationships it introduces.

Q: What breaks when AI tools are exposed through loosely governed MCP servers?

A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight. That can expose sensitive data, trigger unauthorized system changes, or widen lateral movement paths. The failure is a control boundary mismatch between what the AI can ask for and what it can safely do.

Q: How do teams reduce blast radius when deploying many MCP servers?

A: Use central policy, server registration, and fine-grained capability scoping so one credential cannot reach every connected system. Then review logs for unusual tool sequences and limit each server to the smallest practical set of actions. The goal is to constrain how far one identity can move before detection or containment.

Technical breakdown

How MCP discovery and invocation work

MCP separates capability discovery from execution. A host application uses an MCP client to connect to an MCP server, the server advertises tools, resources, and prompts, and the client mediates JSON-RPC requests over stdio or HTTP+SSE. The LLM does not speak to the server directly. That separation is useful because it keeps protocol logic out of the model, but it also means the security boundary sits between client, server, and transport rather than inside the model itself.

Practical implication: treat every MCP client-server connection as an explicit trust relationship that needs policy, logging, and access review.

Why tools, resources, and prompts need different controls

MCP exposes three capability classes with different risk profiles. Tools let the model trigger actions, so they can create state changes or reach sensitive systems. Resources are application-selected context, usually read-only but still subject to data access governance. Prompts are user-selected templates and sit closest to explicit human intent. The protocol standardises capability delivery, but it does not standardise authorisation policy. That gap matters because a tool with broad write permissions can turn a harmless integration layer into an execution path.

Practical implication: classify each exposed capability by read, write, and execution risk before allowing an agent to consume it.

Why production MCP deployments need central governance

A single server is manageable; dozens are not. Once MCP spreads across environments, each server can introduce its own credentials, rate limits, and access rules, creating authentication sprawl and inconsistent audit coverage. The architecture then resembles early API sprawl before gateways became standard. Central control becomes necessary for identity, discovery, policy enforcement, and telemetry. Without it, teams lose the ability to answer basic questions such as who approved access, which server was used, and whether the agent stayed within its intended scope.

Practical implication: add a central control plane for MCP before server count and agent count grow beyond manual governance.

Threat narrative

Attacker objective: The attacker seeks to turn AI tool access into a reliable path for data exposure, unauthorized actions, or lateral movement through connected systems.

1. Entry occurs when an AI application connects to an MCP server with credentials or permissions that were provisioned for convenience rather than tightly scoped use.
2. Escalation happens when the server exposes tools with broader action rights than the requesting agent actually needs, or when multiple servers create unmanaged access pathways.
3. Impact follows when the agent can reach production systems, retrieve sensitive data, or execute changes through a poorly governed tool interface.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP governance is really non-human identity governance in a new wrapper. The protocol standardises discovery, but it does not eliminate the need to govern credentials, privilege, and auditability across each server-client relationship. That puts MCP squarely in the same control family as service accounts, API keys, and workload identities. Practitioners should treat the server fleet as an identity estate, not an integration detail.

Authentication sprawl is the first operational failure mode in production MCP. Every additional server can introduce its own auth configuration, rotation process, and authorization policy. The result is not just complexity, but uneven control quality across the same AI estate. This is where the discipline of lifecycle management becomes central, because access that cannot be centrally enumerated cannot be confidently governed.

Capability type matters more than protocol novelty. Tools, resources, and prompts are not equivalent, because only tools can reliably trigger side effects under model control. That means authorisation must be designed around action potential, not just connection success. The practical conclusion is that teams need policy boundaries at the capability level, not only at the server level.

Identity blast radius: The real risk in MCP is not one compromised server, but the cumulative spread of access across many servers with inconsistent controls. Once agents can chain discovery, invocation, and downstream system reach, the blast radius expands faster than conventional API governance assumes. Practitioners should measure how far one compromised MCP identity can travel before containment breaks.

MCP will push enterprises toward gateway-style control for agent access. The architecture problem is familiar: many endpoints, many policies, many credentials, and not enough visibility. That means the market is moving toward centralized governance layers for AI connectivity, with identity, routing, and telemetry becoming inseparable. Security teams should expect MCP to be governed like a platform, not a point integration.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint research.
• For a broader view of agent risk and control design, see OWASP Agentic Applications Top 10 for the governance patterns that apply when tool use becomes runtime behaviour.

What this signals

Identity blast radius is the right lens for MCP programmes because every new server widens the number of credentials, policies, and logs that must stay aligned. The security team should expect governance to fail at the seams first, especially where discovery and execution are managed separately. That is why central policy, not individual server hardening, becomes the scaling control.

Agentic AI governance will increasingly depend on the same operational disciplines used for service accounts, but with more dynamic access paths. The problem is not just who can connect, but which tools can be invoked and whether those invocations can be traced back to a business owner. Teams should align MCP oversight with the NHI Lifecycle Management Guide and the NIST AI Risk Management Framework.

The likely direction of travel is a gateway model for AI connectivity, where discovery, routing, and authorization are governed together. That shift will matter most for organisations trying to avoid Shadow AI and unmanaged server growth. Once agents can discover capabilities at runtime, static allowlists alone will not be enough to preserve control.

For practitioners

• Inventory every MCP server as an identity-bearing asset Track each server, its credentials, and its downstream systems in the same inventory used for service accounts and other non-human identities.
• Separate tool permissions from read-only context Classify exposed capabilities so that write or execute actions require tighter approval and logging than resource reads or prompt templates.
• Centralize authentication and discovery before server sprawl grows Introduce a shared control layer for policy enforcement, approved server discovery, and consistent audit logging across the MCP estate.
• Review AI agent blast radius by server and by tool Test how far one compromised credential could move across connected databases, SaaS tools, and internal APIs before containment procedures fail.

Key takeaways

• MCP standardises AI-to-tool connectivity, but it does not solve the governance problem of who can reach what, under which credential, and with what audit trail.
• Production MCP estates create the same sprawl patterns security teams already know from NHI, only now the access paths are driven by AI applications and tool invocation.
• The control answer is centralised policy, capability-level authorisation, and lifecycle management for every server, credential, and connected system.

Key terms

• Mcp Server: An MCP server is a process that exposes tools, resources, and prompts to an AI application through the Model Context Protocol. It is not the model itself. In governance terms, it becomes a controllable access point that must be inventoried, authorized, and monitored like any other non-human identity endpoint.
• Tool: A tool is a capability an AI application can invoke to perform an action, such as querying a database or creating a ticket. Tools are the highest-risk MCP capability because they can change state. Security teams should treat tool exposure as an authorization decision, not just an integration choice.
• Resource: A resource is data or context the host application fetches for the AI, usually without model-initiated action. Resources are typically read-only, but they still need access control because they can surface sensitive schemas, documents, or operational data. Their governance burden is data visibility and audience restriction.
• Prompt: A prompt in MCP is a predefined template a user selects to guide interaction with server capabilities. Prompts are closer to explicit user intent than tools are, but they still require control because they can shape what the AI requests and how capabilities are exercised. They are safer than tools, not safe by default.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: What Is an MCP Server? Guide to the Model Context Protocol for Enterprise AI. Read the original.