Notifications
Clear all
Topic starter
08/06/2026 4:25 pm
TL;DR: MCP servers still often rely on API keys, while OAuth support remains uneven and implementation-heavy, with about 60% requiring a key passed on every request, according to WorkOS. That means the security problem is not just authentication choice, but how identity, consent, and token handling are governed across tool-connected AI workflows.
NHIMG editorial — based on content published by WorkOS: How WorkOS solved enterprise auth for MCP 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 authentication for MCP servers in production?
A: Security teams should treat MCP authentication as an authorization design problem, not just a login problem.
Q: Why do API keys create more risk in MCP environments than in ordinary app integrations?
A: API keys create standing access, and standing access is hard to justify when AI tools can call APIs repeatedly on behalf of users.
Q: When should organisations prioritise OAuth over simpler authentication for MCP?
A: Organisations should prioritise OAuth when an MCP server can touch user-specific data, production systems, or privileged actions.
Practitioner guidance
- Eliminate pass-through API keys for production MCP flows Use scoped OAuth tokens or delegated authorization patterns for any MCP server that touches user data, admin actions, or internal APIs.
- Review dynamic client registration as a privileged onboarding process Constrain which clients can register, what metadata they can present, and which scopes they can request.
- Separate consent from capability expansion Validate that the permissions granted during OAuth consent match the actual tool actions exposed by the MCP server.
What's in the full article
WorkOS' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for MCP auth with AuthKit and the OAuth bridge flow
- Implementation notes on dynamic client registration, consent handling, and token issuance
- Mux's production experience integrating MCP auth without rebuilding its existing authentication stack
- Documentation-linked setup paths for new builds versus existing applications
👉 Read WorkOS's article on enterprise auth for MCP servers →
MCP server auth and OAuth bridging: what IAM teams should watch?
Explore further
08/06/2026 6:02 pm
Standing credential exposure is the wrong default for MCP governance: The article shows that many MCP deployments still rely on API keys passed through every request, which turns access into a reusable secret rather than a governed authorization event. That is not just a weakness in secret handling. It is a control model that assumes the client can safely carry standing privilege across the entire tool path. Practitioners should treat pass-through keys as a design smell, not a normal integration choice.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 48% of organisations say they cannot track and audit the data their AI agents access, leaving a complete compliance and investigation blind spot in nearly half of deployments.
A question worth separating out:
Q: What do security teams need to verify before exposing an MCP server to users?
A: Teams need to verify who can register as a client, what scopes they can request, how tokens are validated, and how consent maps to real tool permissions. If any of those links are vague, the MCP server can expand access beyond the user’s intent or the organisation’s policy. Auditability should be built in before go-live.
👉 Read our full editorial: MCP server authentication still hinges on OAuth complexity
