TL;DR: MCP servers now sit in the authentication path for AI tools, and the June 2025 MCP specification updates make them OAuth resource servers rather than authorization servers, according to WorkOS. That shift turns MCP security into an identity governance problem for both NHI and emerging agentic workflows, where scoped access and user context determine exposure.
NHIMG editorial — based on content published by WorkOS: XMCP + AuthKit for securing MCP tools and servers
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern access to MCP servers in production?
A: Security teams should treat MCP servers as protected resources and require identity-bound access at the protocol boundary.
Q: Why do MCP servers create new IAM and NHI governance risks?
A: MCP servers expose tools in a way that can bypass the access assumptions many teams built for human-operated applications.
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
- Classify every MCP server as a governed resource Assign an owner, sensitivity tier, and access policy to each MCP endpoint before it is exposed to users, internal agents, or external clients.
- Enforce token validation at the tool boundary Require every request to present a valid bearer token, verify the issuer against the configured AuthKit domain or equivalent IdP, and reject calls that cannot be tied to a trusted JWKS.
- Scope tools by identity attributes and task context Use claims such as organisation membership, role, and authentication strength to limit what a caller can do inside the tool.
What's in the full article
WorkOS's full post covers the operational detail this analysis intentionally leaves for the source:
- The exact XMCP configuration pattern for enabling OAuth2 on a server with AuthKit.
- The JWT verification workflow using remote JWKS inside a tool handler.
- The WorkOS dashboard settings for dynamic client registration and redirect handling.
- The demo repository structure for a protected MCP server and user context extraction.
👉 Read WorkOS's XMCP and AuthKit guide for securing MCP servers →
MCP server authentication gaps: what IAM teams need to know?
Explore further
Authentication is now the control plane for MCP, not a wrapper around it. Once tools are callable by LLMs through protocol rather than hardcoded integration, access control shifts from application plumbing to identity governance. The article shows that a secure MCP server depends on token validation, scope enforcement, and user context propagation. That is an NHI problem first and a developer-experience problem second. Practitioners should treat MCP exposure as an access surface that requires the same governance discipline as any other machine-facing resource.
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 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, which shows the control problem is already operational rather than theoretical.
A question worth separating out:
Q: How can organisations tell if an MCP server is actually governed?
A: An MCP server is governed when every client is registered, every request is authenticated, and every tool invocation can be traced back to a specific identity and scope. If access cannot be reviewed, revoked, or audited with confidence, the server may be running, but it is not yet under control.
👉 Read our full editorial: MCP server authentication gaps are now an IAM problem