MCP servers create new governance gaps for enterprise AI access

At a glance

What this is: Kong describes MCP servers as the protocol layer that lets AI applications discover and invoke tools, while warning that production-scale deployments create governance, authentication, and routing gaps.

Why it matters: IAM and NHI teams need to treat MCP as a governed access layer because each server can introduce its own credentials, policies, and visibility blind spots.

Context

MCP servers sit between AI applications and the external systems they need to use. In practice, they standardise discovery and invocation across databases, APIs, file systems, and SaaS tools, which is why the control problem quickly shifts from integration plumbing to access governance.

The governance gap appears when MCP moves from a single development server to a production fleet. At that point, credentials, routing, observability, and authorization boundaries are no longer implied by the application stack, and each server becomes a separate identity surface that must be controlled explicitly.

For enterprise IAM teams, the relevant question is not whether MCP can connect systems, but whether each connection is governed with the same discipline as any other privileged machine or workload identity.

Key questions

Q: What breaks when MCP servers are exposed without identity controls?

A: Without identity controls, anyone with a link, key, or copied credential can reach tools and data outside policy. That breaks visibility, weakens compliance evidence, and makes it difficult to separate approved use from shadow AI activity across SaaS and internal systems.

Q: Why do many MCP servers create more risk than a single development server?

A: Because scale turns a simple integration pattern into a distributed access problem. A single server can be reviewed manually, but many servers create separate credentials, policies, and visibility gaps. That increases the chance that an agent reaches privileged tools or data through an approval path nobody is watching closely.

Q: How should teams govern tool access differently from resource access in MCP?

A: Tools should be treated as state-changing actions and reviewed more strictly than resources, which are read-only context. That means explicit approval, tighter scoping, and better logging for tools, while resources still need inventory and least-privilege access because they can expose sensitive schemas or documents.

Q: When should security teams require an MCP registry or gateway?

A: They should require one as soon as server count or business criticality makes manual allowlisting unreliable. A registry and gateway help centralize approved discovery, policy enforcement, and observability so agents cannot freely connect to unvetted servers or bypass fleet-wide controls.

Technical breakdown

How MCP discovery and invocation create a new access layer

MCP separates the host, client, server, and transport so the AI application does not talk directly to external systems. The client negotiates capabilities with the server, then sends JSON-RPC requests for tools, resources, or prompts over stdio or HTTP+SSE. That structure is efficient, but it also creates a distinct control plane for who can reach what, when, and under which policy. In production, that layer behaves like an identity boundary even when teams initially treat it as an integration detail.

Practical implication: Treat every MCP server as a governed access endpoint, not just a connectivity helper.

Why MCP tools, resources, and prompts need different authorization models

MCP is not one control boundary. Tools can change state and therefore need the strongest authorization, resources expose read-only context that still needs access scoping, and prompts are user-selected templates with explicit initiation. If teams apply one uniform policy to all three, they either over-restrict safe access or under-protect tool execution. The risk is not just misuse; it is misclassification of what the server is allowed to expose at each capability layer.

Practical implication: Map authorization by capability type before allowing an MCP server into production.

Why production MCP fleets expose authentication sprawl and weak observability

A single MCP server may be manageable, but dozens create a distributed credential problem. Each server can carry its own authentication requirements and access policies, which makes rotation, inventory, and review harder as the fleet grows. The same pattern applies to observability: without per-server instrumentation, teams cannot reliably answer which agent called which tool, how often, or with what outcome. That turns governance into a fragmented operational task rather than a central policy function.

Practical implication: Centralize authentication, logging, and registry governance before the server count makes manual control impossible.

Threat narrative

Attacker objective: The objective is to use MCP-connected access paths to reach tools or data the organization never governed as a single identity plane.

1. Initial access begins when an AI host connects to an MCP server that exposes tools or resources without centralized identity governance.
2. Credential access or abuse follows when each server carries its own authentication and authorization logic, creating separate trust decisions across the fleet.
3. Impact occurs when an agent reaches a privileged tool or resource without fleet-wide visibility, making unauthorized access difficult to detect or contain.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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-plane problem, not an integration problem: Once AI applications consume many servers, each server becomes an access decision with its own credentialing, policy, and visibility requirements. That means the control model has to move from point-to-point integration management to governed non-human identity access. Practitioners should treat the server fleet as a distributed entitlement surface, not a developer convenience.

Capability type is the real control boundary: Tools, resources, and prompts are not interchangeable, and the governance model should not treat them as if they were. Tools can mutate state, resources can expose sensitive context, and prompts can still encode access decisions that users do not inspect closely. The implication is that entitlement design for MCP has to start with what the server can do, not just who can reach it.

Distributed credentialing creates trust debt: When every MCP server manages its own credentials, organizations accumulate a governance burden that grows faster than the fleet. Rotation, offboarding, and auditability become local chores instead of central controls. The named concept here is MCP trust debt: the growing gap between how many server-level trust decisions exist and how little of that trust can be reviewed from one place. Practitioners should see this as structural exposure, not mere operational inconvenience.

Production MCP deployments will push teams toward registry and gateway patterns: The article reflects a broader market shift from ad hoc server connections to centralized discovery and policy enforcement. That mirrors earlier API governance evolution, but with agents now sitting in the consumer role. The practical conclusion is that identity teams, platform teams, and security teams will need a shared control plane for server approval, routing, and audit.

Agent access governance must now span human intent and machine execution: Even when a person starts the workflow, the agent and its connected servers become the entities exercising privilege. That makes the access model hybrid in practice, but the control obligation remains strict and machine-oriented. Practitioners should design for governed delegation chains instead of assuming human approval is enough once execution begins.

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.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

MCP trust debt: as the number of servers grows, every local credential and approval rule becomes part of a larger governance liability. Teams that let discovery stay ad hoc will eventually discover that their access model is more distributed than their security ownership.

The practical shift for IAM and NHI programmes is toward centralized approval, routing, and audit for AI-to-tool connections. Without that layer, a simple server count increase becomes a control failure, not just an operational scaling issue.

For practitioners

• Inventory every MCP server as a governed identity surface Track server owner, purpose, connected systems, credential source, and exposed capability types so the fleet is visible before production use expands.
• Separate authorization by capability type Apply stricter approval and scoping to tools than to resources or prompts, and require explicit review for any capability that can change state.
• Centralize discovery through an approved registry Replace hardcoded server connections with an approved inventory so agents can only discover MCP servers that have been reviewed and authorised.
• Instrument per-server logs and usage signals Capture which agent invoked which tool, the request context, and the outcome so audit and incident response do not depend on each server's local logs.
• Treat credential rotation as a fleet control Set a rotation and revocation process for every MCP server credential, including third-party and local deployments, rather than leaving each team to manage it separately.

Key takeaways

• MCP servers make AI access more structured, but they also turn each connection into a separate governance decision that security teams must own.
• Production fleets create authentication sprawl, uneven observability, and unclear authorization boundaries that do not appear in small development setups.
• Centralized discovery, capability-specific authorization, and per-server auditability are the controls that change MCP from a convenience layer into a governable access plane.

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.
• Capability Boundary: A capability boundary is the control line around what a non-human actor can do through a specific tool, workflow, or service. For AI agents, it is the practical unit of governance because the boundary determines what action the system can trigger, not just what the model can describe.
• Capability Negotiation: Capability negotiation is the handshake process where the client and server exchange supported protocol versions and available functions before work begins. It helps both sides agree on what can be used, reducing compatibility issues and making tool access more predictable during the session.
• MCP trust debt: MCP trust debt is the accumulated risk created when Model Context Protocol connections, permissions, and assumptions are added quickly without strong governance. It appears when agents, tools, and data sources are linked before identity, authorization, logging, and revocation are fully defined, leaving hidden access paths and weak accountability.

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.