Notifications
Clear all
Topic starter
16/08/2026 1:12 pm
TL;DR: Remote MCP servers widen the AI tool surface by letting LLMs call external APIs over standardized protocols, and Descope’s tutorial shows how OAuth 2.0 metadata, dynamic client registration, and bearer-token checks fit into that flow, according to Descope. The governance issue is that tool access now becomes identity access, so teams must control scopes, consent, and token validation as tightly as any other NHI path.
NHIMG editorial — based on content published by Descope: Deploy secure remote MCP servers with Descope and Fly.io
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Descope's tutorial on securing a remote MCP server with OAuth →
Remote MCP servers and OAuth: are your identity controls ready?
Explore further
16/08/2026 1:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Remote MCP servers need OAuth-backed identity, not trust by default
