Notifications
Clear all
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.
NHIMG editorial — based on content published by Aembit: MCP security controls for agentic AI and identity governance
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern MCP access in agentic workflows?
A: Security teams should govern MCP access as delegated identity, not simple application connectivity.
Q: Why do MCP implementations create confused deputy risk?
A: MCP creates confused deputy risk when a server treats user authentication as enough to authorise any client that can present the token.
Q: What breaks when token passthrough is allowed in MCP?
A: When token passthrough is allowed, every intermediary becomes a credential capture point and every downstream service inherits more trust than intended.
Practitioner guidance
- Enforce per-client consent registries Map each approved user-to-client relationship server-side and require every MCP request to match a specific client identity and granted scope.
- Block token relay paths Prohibit token passthrough through proxies, middleware, and logging layers.
- Constrain MCP scopes to task boundaries Replace broad permissions such as read-all-data with resource-specific grants that match the workflow step.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of the six MCP threat vectors and the exact failure patterns behind each one
- Protocol-level guidance on OAuth 2.1, PKCE, redirect URI matching, and state validation for MCP deployments
- Architecture-specific recommendations for local MCP servers, including stdio transport and filesystem protections
- Control mapping for Aembit's workload IAM model across AWS, Azure, GCP, and on-premises environments
👉 Read Aembit's analysis of MCP security controls and agentic identity risk →
MCP security controls: what IAM teams need to lock down now?
Explore further
06/06/2026 4:04 am
MCP is really a delegation-control problem disguised as a protocol question. Standardisation makes agent-to-tool interoperability easier, but it also makes authorisation failures repeatable at scale. Once multiple clients, servers, and resources share a common interaction model, any gap in consent validation or token handling becomes a reusable attack pattern. Practitioners should read MCP as identity infrastructure first and integration plumbing second.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an MCP server authorises the wrong action?
A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.
👉 Read our full editorial: MCP security controls are now an identity governance problem
