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.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “MCP Authentication and Authorization Patterns”.
Key questions
Q: What breaks when MCP relies on sessions instead of request-level authorization?
A: Session-based authentication breaks because MCP requests can be generated dynamically by nonhuman identities and routed through tools or intermediaries that were never part of the original trust decision.
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 are the signs that an MCP authorization model is too loose?
A: Warning signs include token passthrough between components, broad token scopes, shared sessions for workloads, and redirect URI patterns that accept wildcards or partial matches.
Practitioner guidance
- Enforce client-bound consent Map each approved user-to-client relationship to explicit scopes, then reject requests that do not match the approved client identifier and operation.
- Eliminate session authentication Remove session cookies and other server-maintained authentication state from MCP flows, and require token validation on every request instead.
- Block token passthrough Validate tokens directly with the authorization server and use token exchange for downstream access rather than forwarding the original token.
Bottom line: MCP security best practices are built around confused deputy prevention, not just login verification or token issuance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 12:25 pm
Confused deputy risk is the right mental model for MCP governance. MCP is not simply about authenticating agents or hardening API calls. It is about stopping a legitimate server from applying valid authority to the wrong client or operation, which is why per-client consent and audience validation sit at the center of the specification. Practitioners should treat authorization binding, not login success, as the control boundary.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
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
This post was modified 1 day ago by NHI Mgmt Group