Enterprise access control for MCP servers: what practitioners need

At a glance

What this is: This is an analysis of how enterprises should govern access to MCP servers, with the key finding that MCP adoption only becomes manageable when access control, identity integration, and proxy enforcement are built in from the start.

Why it matters: It matters because MCP turns AI tool connectivity into an identity problem, forcing IAM, PAM, and NHI teams to decide how users, groups, and agents are authorised at server and tool level.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Obot's analysis of enterprise MCP access control

Context

Model Context Protocol, or MCP, connects AI models and agents to tools and data sources. That connection is only as safe as the identity and access layer wrapped around it, because once MCP servers can reach business systems, the question becomes who or what is allowed to use which tools under which conditions.

The article’s central point is that MCP rollout fails when teams treat it as a connectivity problem rather than an access governance problem. For IAM and NHI teams, the real decision is whether MCP access is managed through existing identity platforms, scoped by role and claims, and enforced at runtime instead of left to ad hoc local settings.

This is directly relevant to enterprise identity architecture because MCP servers can become a new access plane across SaaS, cloud, and internal systems. The governance pattern is familiar, even if the protocol is new: central policy, least privilege, logging, and lifecycle control must arrive before broad adoption does. For background, see the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

Key questions

Q: How should security teams govern access to MCP registry-discovered servers?

A: Security teams should treat registry-discovered servers as governed non-human access, not as simple developer convenience. Use OAuth as the default access model, require narrow scopes, and keep revocation under central identity control. That gives teams a consistent way to audit consent, reduce standing secrets, and tie server access to lifecycle processes.

Q: What breaks when MCP servers do not enforce tool scoping?

A: When MCP servers do not enforce tool scoping, models can reach tools and data across users, tenants, or environments that were never meant to be shared. The failure is usually not obvious at the interface level. It appears later as leakage, unauthorised actions, or audit gaps that are hard to reconstruct after the fact.

Q: How do teams know whether MCP controls are actually working?

A: Teams know MCP controls are working when every tool invocation can be traced to a verified identity, a policy decision, and a recorded approval state where required. If logs cannot answer who asked, what was allowed, and why the call ran, then the controls are not governing the workflow. They are only documenting its existence.

Q: Who is accountable when an exposed MCP server is used to reach internal systems?

A: Accountability sits with the team that owns the delegated access path, the network exposure, and the identity controls around the server. In practice, that means security, platform, and application owners must all understand whether the MCP trust boundary is intentionally public or accidentally exposed.

Technical breakdown

OAuth 2.1 and PKCE for MCP server access

MCP access control depends on federated identity rather than a separate AI-specific login silo. In the article’s model, users authenticate through an existing identity provider and the MCP gateway validates OAuth 2.1 tokens before forwarding requests. PKCE reduces client interception risk, while metadata discovery simplifies endpoint setup and avoids hand-built integrations. The important architectural point is that MCP access should inherit enterprise identity controls instead of bypassing them with local credentials or one-off server-side exceptions.

Practical implication: Use your existing IdP and OAuth 2.1 enforcement points as the control plane for MCP access, not standalone server-local authentication.

Granular group-based access and tool-level authorisation

The article distinguishes between access to an MCP server and access to individual tools inside that server. That matters because a user may be allowed to read from one connected system but not write to it, or may be entitled to one MCP server but not another. Group mapping, JWT claims, and scoped permissions create a policy model that is closer to RBAC with per-tool constraints than to broad server-level allow lists. Without that extra layer, MCP becomes a wider conduit than the business actually intended.

Practical implication: Define server access and tool access separately so read, write, and admin functions can be governed with different claims or roles.

Proxy enforcement, validation, and auditability

The article’s proxy pattern places enforcement between the client and the resource server, which is where identity control becomes operational instead of theoretical. Each call can be checked for token signature, audience, expiry, and scope before any tool or resource action occurs. That gives teams a runtime choke point for policy enforcement, logging, and compliance evidence. It also prevents shadow use of local servers that would otherwise sit outside central oversight and create unmanaged access paths.

Practical implication: Route all MCP traffic through a proxy that validates tokens and records every tool invocation for audit and investigation.

Threat narrative

Attacker objective: The attacker objective is to turn a trusted MCP integration point into a shortcut for broader enterprise access and data exposure.

1. Entry occurs when a user or agent reaches an MCP server through broad or unsecured access, especially where server discovery is informal or local deployments are left outside central governance.
2. Escalation happens when the server exposes multiple tools or connected systems without per-tool scoping, allowing a valid identity to move from read access to write-capable or high-value actions.
3. Impact follows when the MCP layer becomes a path into email, CRM, cloud, or data systems with weak logging and insufficient authorization, expanding blast radius across enterprise services.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 server access is now an identity governance problem, not a connectivity problem. The article makes clear that once MCP exposes enterprise systems, the real control question is who can reach which tools, under which claims, and through which identity provider. That shifts MCP from developer convenience into IAM and NHI governance territory, where central policy and auditability matter more than deployment speed. Practitioners should treat MCP as a governed access plane, not a simple integration layer.

Tool-level authorisation is the named concept that enterprises keep missing. Server-level allow lists are too coarse when a single MCP host can expose both read and write actions, or multiple systems with very different sensitivity. A practical access model must separate identity authentication from tool invocation rights, because broad server access without tool scoping produces hidden privilege expansion. The implication is that teams need policy boundaries at the tool layer, not just the server layer.

OAuth 2.1 alignment is necessary, but not sufficient, for safe MCP adoption. The article correctly points toward federated identity, PKCE, and token validation, yet those controls only work if enforcement is consistently proxied and centrally governed. In identity terms, the risk is not lack of login support but fragmented authorisation across distributed MCP servers. Practitioners should regard runtime validation and audit logging as part of the access model, not as optional observability extras.

Grey-market MCP server sprawl will look familiar to IAM teams. The article’s description of servers passing between employees mirrors the unmanaged SaaS and shadow NHI patterns security teams already struggle to contain. Once local servers are shared informally, governance drifts from formal onboarding into ad hoc trust, and that is where policy exceptions accumulate. The practical conclusion is that discovery, approval, and decommissioning must be part of MCP lifecycle management from day one.

For agent access, MCP widens the NHI perimeter even when the article focuses on human users. The same server and tool controls that protect people will need to extend to AI agents as they begin to consume MCP endpoints in production workflows. That means identity programmes should not create a second, softer access model for agent-driven calls. Practitioners should design MCP governance so human and non-human access can be evaluated through one policy architecture.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably see where non-human access is actually living.
• That visibility gap is why the NHI Lifecycle Management Guide is the right next step for teams building a governed control plane.

What this signals

Tool-level authorisation is the critical design choice for MCP adoption. Teams that stop at server-level allow lists will reproduce the same overbroad access patterns that have already defined NHI sprawl. The programme implication is clear: policy has to move closer to the action, not stay at the catalog layer.

With 97% of NHIs carrying excessive privileges, the broader identity market already shows what happens when access is granted more generously than it is governed. MCP will magnify that problem unless teams bind gateway policy, claims, and audit evidence into one operating model.

The most useful forward posture is to treat MCP as part of the enterprise identity fabric, with lifecycle ownership, decommissioning rules, and visibility into who can reach which tools. That is where the NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10 become practical references, not background reading.

For practitioners

• Centralise MCP access through an enterprise gateway Publish approved MCP servers through a single control plane that integrates with your existing identity provider and blocks unmanaged local servers from becoming shadow access paths.
• Separate server access from tool access Map groups and claims to specific MCP servers first, then apply finer-grained controls for read, write, and administrative tools inside each server.
• Enforce runtime token validation at the proxy Validate token signature, audience, expiry, and scope on every call before a resource server can be reached, and retain logs for audit and incident review.
• Document MCP server lifecycle ownership Assign clear owners for publishing, review, and retirement so approved MCP servers do not drift into informal sharing or permanent exceptions.
• Plan for agent access alongside human access Use the same policy model for AI agent calls that you apply to human users, so future non-human access does not bypass the governance path already in place.

Key takeaways

• MCP adoption becomes an identity governance issue the moment servers expose real enterprise systems and tools.
• Runtime validation, scoped access, and proxy enforcement are the controls that separate governed MCP from shadow access sprawl.
• Enterprises should design MCP rollout with the same lifecycle discipline they apply to NHI programmes, or tool access will expand faster than policy can contain it.

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.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• 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.

What's in the full article

Obot's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance on integrating MCP access with identity providers such as Okta, Entra, Google, and GitHub.
• Proxy enforcement details for validating token audience, scope, and expiry before resource access.
• Implementation patterns for mapping groups to specific MCP servers and tools.
• Operational examples of how the gateway supports discovery, logging, and compliance across teams.

👉 Obot's full post covers gateway enforcement, OAuth 2.1 setup, and tool-level policy detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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, PAM, or NHI programme, it is worth exploring.