Topic starter
06/06/2026 2:24 am
TL;DR: MCP standardises how AI agents coordinate across tools and data, but the same interoperability also expands the attack surface through confused deputy abuse, token passthrough, SSRF, session hijacking, and scope creep, according to Aembit. The governance issue is not agent capability itself, but the assumption that user authentication or broad scopes are enough to authorise every client and tool interaction.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “MCP Threat Modeling: Understanding the Attack Surface”.
Key questions
Q: How should security teams govern MCP server authentication in production?
A: Treat MCP authentication as a governed access layer, not a developer convenience.
Q: Why do MCP implementations need direct token validation instead of token relay?
A: Because relay turns the MCP server into a forwarding point for credentials that can be stolen or replayed elsewhere.
Q: What breaks when MCP clients share broad scopes?
A: Broad scopes collapse the boundary between authentication and authorization.
Practitioner guidance
- Enforce per-client consent registries Map each approved client application to explicit user consent and revalidate that mapping on every MCP request.
- Validate token audience on every request Reject any token whose audience claim does not match the receiving MCP server, even when the token is signed and unexpired.
- Eliminate token passthrough in all brokered flows Issue scoped downstream credentials to the MCP server itself instead of forwarding the user token through intermediaries.
Bottom line: MCP security is an identity governance issue because client identity, consent and scope determine whether a valid request should be trusted.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 19 hours ago by NHI Mgmt Group
06/06/2026 4:04 am
MCP security controls are an identity governance problem, not just a protocol-hardening problem. The article correctly frames MCP as an interoperability layer that moves identity decisions into the path of every tool call, consent check and downstream delegation. Once that happens, identity governance has to cover client identity, token audience, consent registry state and tool scope together. Practitioners should stop treating MCP as a transport detail and start treating it as a governed access plane.
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: What is the difference between per-client consent and general user authentication in MCP?
A: User authentication proves who logged in. Per-client consent proves which application is allowed to act on that person’s behalf. MCP needs both, because a valid user login does not tell the server whether the specific client making the request is trusted to use the requested tool or data path.
👉 Read our full editorial: MCP security controls are now an identity governance problem
This post was modified 19 hours ago by NHI Mgmt Group