Notifications
Clear all
Topic starter
06/06/2026 11:33 am
TL;DR: The MCP security best practices specification makes confused deputy attacks, token passthrough, and session-based authentication the central risks for agent and tool trust, while mandating OAuth 2.1, per-request validation, and five authorization patterns, according to Aembit. The bigger issue is that existing IAM assumptions about stable user sessions and broad token reuse do not survive request-by-request nonhuman identity behaviour.
NHIMG editorial — based on content published by Aembit: MCP security best practices and the confused deputy problem
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams enforce per-client authorization in MCP environments?
A: Security teams should bind each request to a specific client identity, approved scope, and approved operation on the server side.
Q: Why do token audience checks matter so much in MCP?
A: Token audience checks matter because a valid token for one service should not be reusable against another service.
Q: What breaks when MCP servers use token passthrough or session auth?
A: Token passthrough and session authentication both create reusable trust artefacts that are easy to intercept or replay.
Practitioner guidance
- Enforce per-client consent registries Map each user to approved client applications and approved scopes on the server side, then reject requests that cannot be bound to a specific client and operation.
- Validate audience claims on every request Reject any token whose aud claim does not match the MCP server identifier, even if the token is signed and unexpired.
- Eliminate token passthrough from intermediary services Require direct token validation against the authorization server and use token exchange when downstream services need access on behalf of the user.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Exact authentication pattern guidance for OAuth 2.1, PKCE, mTLS and federation in MCP deployments
- Step-by-step authorization checks for consent registries, redirect URI matching and state validation
- Transport hardening detail for HTTPS, TLS versions, HSTS and stdio-based local server transport
- Policy implementation examples for conditional access, posture checks and attribute-based controls
👉 Read Aembit's analysis of MCP security best practices and confused deputy risk →
MCP confused deputy risk: what IAM teams need to enforce?
Explore further
06/06/2026 12:25 pm
Confused deputy is the right named concept for MCP governance failure: the article shows that MCP does not mainly fail because authentication is absent, but because trust is misapplied across clients and intermediaries. User authentication was designed for a single authorised actor, not for a server that can be induced to act on behalf of another client. The implication is that MCP governance has to be built around explicit client binding, not inherited trust.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- In our Ultimate Guide to NHIs, 91.6% of secrets remain valid five days after notification, which shows how slowly governance catches up once credentials move.
A question worth separating out:
Q: How do organisations decide whether MCP should use OAuth, mTLS, or federation?
A: Use OAuth 2.1 for standard delegated access, mTLS for higher assurance between tightly controlled workloads, and federation when identity must span cloud or on-premises domains. The decision should follow the trust boundary, the exposure of the token path, and the operational maturity of the workload identity stack, not personal preference.
👉 Read our full editorial: MCP security best practices expose the confused deputy risk
