Enterprise access control for MCP servers: what practitioners need

At a glance

What this is: This is an Obot analysis of enterprise Model Context Protocol access control, arguing that MCP servers need centralised identity integration, scoped authorization, and proxy enforcement to avoid unmanaged access sprawl.

Why it matters: It matters because IAM, IGA, and NHI teams now need to govern tool access for AI workflows with the same discipline they apply to SaaS and privileged systems.

Context

Model Context Protocol access control is the identity problem that appears when AI models and agents are allowed to reach enterprise tools and data through a standardised interface. The underlying gap is not connectivity, but governance: once MCP servers become shared enterprise services, existing authentication and authorization models must control who can reach which tools, under what claims, and with what audit trail.

The article argues that unmanaged MCP deployment recreates the same sprawl pattern seen in unsanctioned SaaS use, only with faster scale and broader operational reach. That makes MCP governance relevant to NHI, human IAM, and agentic AI programmes at the same time, because the control plane must cover users, agents, and the services they invoke.

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 does scope-based OAuth matter for MCP server access control?

A: Scope-based OAuth matters because it lets operators separate basic authentication from authorization to specific MCP capabilities. Without scoped permissions, a valid login can become overly broad access. A narrowly defined scope makes the access decision explicit, supports consent where needed, and creates a clearer boundary between the client identity and the tools it is allowed to invoke.

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. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How should organisations govern MCP access across humans, agents, and services?

A: Use one central policy layer that maps identity claims to servers and individual tools, then apply the same review discipline across people, automations, and downstream service calls. That keeps MCP governance aligned with IAM and NHI practice instead of creating a parallel AI-only access model.

Technical breakdown

How OAuth 2.1 fits MCP server access control

MCP access control relies on an authorization layer that can authenticate a user or agent through an identity provider, issue scoped tokens, and let the MCP server or gateway make policy decisions from claims rather than from local assumptions. The article emphasises OAuth 2.1, PKCE, metadata discovery, and audience-bound access tokens because the server needs a standard way to validate who is calling, what client is calling, and which resource server should accept the request. In practice, this is less about the protocol label and more about making access decisions portable across enterprise identity systems.

Practical implication: Use an enterprise authorization pattern that validates token audience, expiry, and scope before any MCP tool call is accepted.

Why proxy enforcement matters for MCP gateways

A proxy layer turns access policy into an enforceable control rather than a document. Every MCP call can be inspected for token integrity, claim scope, and policy compliance before it reaches the resource server, which is crucial when the same gateway fronts multiple teams and multiple downstream services. This design also creates the audit trail needed to reconstruct tool usage, detect overreach, and separate approved access from informal sharing of server endpoints. Without that choke point, governance becomes advisory and exceptions spread quietly.

Practical implication: Route MCP traffic through a proxy that performs authorization, logs every request, and blocks calls that do not match policy.

Tool-level authorization inside an MCP server

Server-level access is not always enough, because different tools inside the same MCP server can carry very different risk. Read-only access to a CRM, for example, does not imply permission to write records, trigger workflows, or move data into another system. Fine-grained authorization lets teams map roles and claims to tool functions, which is especially important when humans and AI agents share the same platform but should not share the same effective privileges. The control objective is to prevent broad server access from becoming implicit permission to perform every available action.

Practical implication: Separate read and write capabilities at the tool level so broad server access does not become broad action authority.

Threat narrative

Attacker objective: The objective is to reach enterprise tools and data through a weakly governed MCP path and use that access beyond its intended scope.

1. Entry occurs when an MCP server is exposed as a shared enterprise service without a central access control layer, allowing users or agents to discover and reach tools more easily than intended.
2. Credential and token abuse follows when authorization is weak, because tokens, claims, or local trust assumptions can be reused to reach resources that were not meant for the caller.
3. Impact appears as sensitive data exposure, compliance drift, and operational sprawl when local servers or informal sharing routes bypass enterprise governance.

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.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

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 access control is becoming an identity governance problem, not just a protocol integration task. Once MCP servers are offered as enterprise services, the question shifts from connectivity to who can invoke which tools, under which claims, and with what audit evidence. That places MCP squarely inside IAM, IGA, and NHI governance because the same control plane has to serve humans, agents, and service-backed tool calls. Practitioners should treat MCP rollout as an identity architecture decision, not a feature enablement exercise.

Enterprise-grade access control only works when authorization is centralised. The article correctly points to OAuth 2.1, scoped access, and proxy enforcement because local or ad hoc server permissions do not scale across teams. That is the core reason unsecured MCP deployments recreate SaaS sprawl: access decisions fragment, audit trails weaken, and entitlement review becomes impossible to enforce consistently. The practitioner implication is to govern MCP through a central control layer rather than letting each server become its own policy island.

Fine-grained tool authorization is the real control boundary. Server-level access is too coarse when read, write, and workflow-triggering functions sit inside the same MCP service. If teams grant broad server access and rely on user trust alone, they create a hidden privilege expansion path that is hard to see in reviews and hard to contain in incident response. The right unit of governance is the tool, not just the server.

MCP authorisation should be treated as a cross-domain identity pattern that links human IAM, NHI controls, and agentic oversight. The same gateway logic must distinguish between employee access, automated client access, and downstream service calls. That means existing identity programmes need to align claims, roles, and audit expectations across all three actor types before adoption spreads. Practitioners should design MCP policy as a shared governance layer, not a siloed technical feature.

Access sprawl in MCP is a named governance risk worth tracking explicitly. The article describes a grey market of servers passed between employees, which is exactly how unmanaged entitlement growth takes root. The concept is useful because it captures a familiar IAM failure mode in a new AI context: once access distribution becomes informal, enterprise controls lose visibility and the programme stops knowing what it owns. Teams should treat that as a lifecycle and accountability problem from day one.

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.
• Read next: MCP Security Guide

What this signals

Access control is the control plane that decides whether MCP becomes enterprise infrastructure or informal shadow access. If organisations let MCP servers proliferate without central policy, they will end up managing tool access as a collection of exceptions rather than a governed entitlement model. The practical consequence is that identity teams need to treat MCP as part of the access lifecycle, not as a separate AI rollout.

MCP gateway design should be evaluated against the same governance expectations used for SaaS and privileged access. That means policy enforcement, auditability, and directory-based visibility are not optional extras. The more an MCP server can touch business systems, the more its access path needs to look like an identity control, not a convenience layer.

Access sprawl is the right named concept for this pattern. It describes what happens when employees exchange access paths faster than IT can normalise them, and it is especially dangerous when those paths lead into AI-connected tools. Practitioners should assume that the first unmanaged MCP server will create pressure for many more unless the directory and gateway are in place early.

For practitioners

• Centralise MCP authorization through an enterprise gateway Require all MCP traffic to pass through a gateway that integrates with your existing identity provider and enforces OAuth 2.1-based authorization decisions.
• Scope access by team and use case Map business groups to specific MCP servers and avoid broad defaults so users only see the tools and data sources they actually need.
• Enforce proxy-side token validation Validate token signature, expiry, audience, and scope before each MCP call reaches the resource server, and log the request for auditability.
• Separate read and write permissions at tool level Do not treat server access as blanket authority. Restrict high-risk tool actions such as writes, exports, or workflow triggers to the smallest claim set possible.
• Publish approved MCP servers through a curated directory Create a centrally governed catalog of approved MCP servers so employees do not route access through informal, untracked endpoints.

Key takeaways

• MCP access control is the real enterprise control point because unsecured servers can expose data, expand privileges, and undermine auditability across teams.
• OAuth 2.1, scoped authorization, and proxy enforcement turn MCP from an informal integration layer into a governed access path.
• If teams do not centralise MCP access early, they risk recreating shadow access patterns that are hard to review, hard to audit, and hard to reverse.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Scoped Authorization: Scoped authorization limits a system to the minimum permissions and data needed for a specific task. For AI workflows, it constrains what the agent can touch, reducing blast radius, improving governance, and making access easier to audit when the workflow operates in production.
• Proxy enforcement: A runtime pattern in which requests are inspected and authorised before they reach the target resource. For MCP, proxy enforcement turns policy into a live control, allowing teams to validate tokens, record usage, and block unauthorised tool calls centrally.

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.