Remote MCP servers need OAuth-backed identity, not trust by default

At a glance

What this is: This is a tutorial on securing a remote MCP server with OAuth-based auth and scope checks, with the key finding that AI tool access must be governed as identity access.

Why it matters: It matters because MCP turns model-to-tool connections into a live identity problem for NHI, agentic AI, and human approval workflows, which means IAM teams need explicit authorization boundaries, not assumptions of safe integration.

👉 Read Descope's tutorial on securing a remote MCP server with OAuth

Context

Model Context Protocol, or MCP, standardises how AI applications connect to external tools and data sources. In this article, the core governance problem is that a remote MCP server can expose real operational access unless authentication and authorisation are built into the transport and the tool call path.

For identity teams, that changes the control surface from static application access to runtime tool access. The relevant question is no longer whether an AI app can reach an API, but whether the identity, scope, consent, and token handling around that call are actually governed.

The same pattern shows up across NHI, autonomous AI, and human-mediated access journeys, but this post is primarily about remote machine access. The starting position is typical: a developer tutorial that becomes materially relevant once the sample is deployed against real services.

Key questions

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

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: When does MCP create more risk than it reduces?

A: MCP creates more risk when agents can access multiple tools with inherited authority, long-lived credentials, or weak audit trails. That combination turns a single compromise into a broader chain of actions. If you cannot explain who acted, what context they carried, and which tool calls were allowed, the risk is already too high.

Q: What do teams get wrong about securing AI tools with OAuth?

A: Teams often assume OAuth alone solves the problem, but OAuth only works when scopes, issuer trust, and token validation are enforced correctly inside the server. If the MCP tool accepts broad tokens or ignores request context, authentication exists in name only. Governance has to extend to each tool call, not stop at sign-in.

Q: Who is accountable when an MCP client grants access too broadly?

A: Accountability sits with the team operating the client, the server, and the authorization policy, because MCP failures usually come from broken relationship handling rather than a single bad request. Security and platform teams should document who owns consent registration, token validation, and local execution restrictions.

Technical breakdown

How remote MCP transport changes the access model

Remote MCP replaces local stdin-style integration with networked transport such as SSE or streamable HTTP. That means the server is no longer a private runtime helper; it becomes an externally reachable identity boundary that must authenticate clients before tool invocation. In practice, the transport layer and the tool handler both matter because the connection can be valid while an individual tool call is not. This is why the article routes auth metadata through the request context rather than treating transport success as sufficient.

Practical implication: Treat the MCP transport as a governed access surface and enforce authentication before any tool session can be established.

Why OAuth metadata and dynamic client registration matter for MCP

The article uses OAuth 2.0 Authorization Server Metadata and Dynamic Client Registration so an MCP client can discover endpoints and register itself programmatically. That is useful because an MCP ecosystem cannot rely on hand-configured client records at scale. But it also expands the trust model: the server must publish authoritative metadata, accept registration only within policy, and ensure the client identity created during onboarding is the one later used for tool calls.

Practical implication: Validate metadata, registration, and token audience rules as part of the MCP onboarding control set, not as optional plumbing.

Tool-scoped authorisation inside the MCP handler

The key control point is the tool handler, where authInfo carries scopes, expiry, and bearer token context into the call. This enables per-tool enforcement, such as denying a schema request when the scope is absent. The architectural lesson is that coarse session authentication is not enough for AI tools that can reach user-specific or sensitive data. Every tool should have an explicit entitlement model, and that model should be checked at execution time, not inferred from the session alone.

Practical implication: Map every MCP tool to a specific scope or entitlement and reject calls that do not carry the exact required authorisation.

NHI Mgmt Group analysis

Remote MCP servers turn model connectivity into an identity governance problem. Once an LLM can reach external tools over a network, the access path resembles a privileged integration rather than a harmless developer convenience. The issue is not the protocol itself, but the fact that every tool call now depends on identity, consent, scope, and token handling working together. Practitioners should treat MCP as part of the enterprise access plane, not as an experiment isolated from IAM controls.

Scope enforcement at the tool layer is the real control boundary. A validated session does not prove that a given tool call should be allowed, especially when the tool may expose user-linked data or operational systems. The article’s pattern of checking scopes in the handler is the right governance shape for remote MCP, because it separates authentication from authorisation. Practitioners should expect this distinction to become mandatory wherever AI clients invoke sensitive workflows.

Model Context Protocol raises the stakes for NHI governance because clients can become machine identities at runtime. The client-registration and bearer-token flow creates a non-human identity path that needs lifecycle, revocation, and audit treatment like any other workload credential. That means IAM teams should not leave MCP identity to application developers alone. The control question is who owns the client, who can revoke it, and how its tool grants are reviewed over time.

Fine-grained tool access is now a baseline requirement, not an advanced feature. Once an AI system can call weather, database, or enterprise APIs, the security model must be built around least privilege per tool and per scope. Broad bearer access is too coarse for environments where the model may act across multiple services. Practitioners should align MCP governance with the same privilege discipline used for high-risk workload identities.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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.
• That gap makes OWASP Agentic Applications Top 10 a useful reference point for teams extending identity controls into AI tool execution.

What this signals

Remote MCP is where agent identity and workload identity converge. As soon as a model can register, authenticate, and invoke tools over the network, the practical control problem shifts to entitlement granularity, client ownership, and revocation. Teams that already inventory service accounts should fold MCP clients into the same governance model, then align it with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.

Identity metadata becomes part of the threat model. In remote MCP, authorization server metadata, dynamic client registration, and bearer-token validation are not back-end implementation details. They are the policy surfaces that determine whether the AI client can act like a controlled workload or an unbounded integration path. That is why MCP governance needs IAM ownership, not just application ownership.

For practitioners

• Define MCP client ownership and revocation paths Assign a business or platform owner to every registered MCP client, then document who can revoke the client, rotate its credentials, and audit its tool grants when the application changes purpose.
• Enforce tool-level scopes for every MCP action Map each tool to a specific scope and reject any call that arrives without the exact entitlement, even if the transport session and user login are already valid.
• Separate registration policy from runtime authorisation Treat dynamic client registration as an onboarding control and tool execution as a runtime control, with independent review for both so one does not become a substitute for the other.
• Log token context and tool usage together Retain scope, expiry, client identity, and tool invocation records in the same audit trail so investigations can reconstruct who accessed what through the MCP path.
• Review MCP servers as workload identities Classify remote MCP clients as non-human identities in your inventory and apply the same lifecycle discipline you use for service accounts, including offboarding and periodic access review.

Key takeaways

• Remote MCP servers should be governed as identity-controlled access points, not as simple developer tooling.
• OAuth metadata, dynamic client registration, and tool-level scopes create the real control plane for AI-to-API access.
• Without explicit ownership and revocation, MCP clients behave like unmanaged non-human identities with broad operational reach.

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.
• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
• 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.
• Remote MCP Server: A Remote MCP server exposes tools over a network so an AI client can discover and invoke them through a standard protocol. In security terms, it becomes part of the identity chain, because it brokers requests, handles authorization, and can expand the blast radius when its OAuth implementation is weak.

What's in the full article

Descope's full blog post covers the implementation detail this analysis intentionally leaves for the source:

• Step-by-step Express.js wiring for the MCP Auth SDK and bearer-token middleware.
• Sample code for handling scopes inside the tool handler and returning 403 responses.
• Dockerfile and Fly.io deployment steps for hosting the remote MCP server.
• Example MCP Inspector validation flow for testing the auth handshake and tool calls.

👉 Descope's full post covers the MCP server code, auth middleware, and Fly.io deployment steps.

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 programme, it is worth exploring.