MCP auth and Zero Trust: are deployments keeping up?

TL;DR: MCP has moved from no authorization framework in November 2024 to a recognizable OAuth 2.1 and OpenID Connect profile by July 2026, according to NetFoundry, but token passthrough, risky client registration, and skipped audience checks still undermine real deployments. The standard is mature; the governance gap is whether teams enforce the audience-bound, least-privilege model in practice.

Editorial analysis by NHI Mgmt Group, based on content published by NetFoundry: “Who’s Calling? The State of MCP Authentication and Authorization”.

Key questions

Q: What breaks when an MCP server passes client tokens to upstream APIs?

A: Token passthrough creates confused deputy risk because downstream services may accept a token that was issued for a different audience.

Q: Why do skipped audience checks increase risk in MCP deployments?

A: Skipped audience checks let a valid token be accepted by the wrong resource server, which turns a scoped credential into a reusable bearer token across boundaries it was never meant to cross.

Q: How should teams govern MCP clients before production rollout?

A: Treat MCP clients as governed identities, not ad hoc integrations.

Practitioner guidance

• Enforce audience-bound tokens Require every MCP server to validate issuer, audience, and resource indicators before accepting a request.
• Ban downstream token forwarding Reject any MCP deployment that passes client tokens to upstream APIs instead of using a server-owned credential.
• Deprecate anonymous client registration Move clients to verified metadata documents and maintain a controlled inventory of approved MCP callers.

Bottom line: MCP has matured into a recognisable OAuth-style model, but the security value depends on whether servers actually validate audience, issuer, and scope.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →