Notifications
Clear all
Topic starter
06/06/2026 2:09 am
TL;DR: Model Context Protocol standardizes how AI agents connect to tools, but Aembit’s analysis shows the real risk is delegated authority without precise permission controls, which can produce confused deputy failures, token passthrough exposure and overbroad access. The security baseline is not optional: it must be designed for agent-driven, task-specific access, not human-style static permissions.
NHIMG editorial — based on content published by Aembit: MCP permission models that prevent confused deputy failures
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: What breaks when MCP permissions rely only on user login and roles?
A: User login and RBAC do not prove that a specific MCP client was approved for a specific action.
Q: Why do MCP environments increase the risk of token leakage and overpermission?
A: MCP agents move across tools and trust boundaries quickly, so forwarded tokens and broad roles can outlive the task they were meant to support.
Q: How do security teams know if MCP access policies are too coarse?
A: If a single role or policy grants access to broad datasets or multiple tools when the task needs only one resource, the policy is too coarse.
Practitioner guidance
- Enforce server-side client consent mapping Maintain a consent registry that maps user identifiers to approved client identifiers and scopes, then reject any MCP request that lacks an exact server-side match.
- Block token passthrough between intermediaries Require direct token validation against the authorisation server and use delegation mechanisms such as token exchange when downstream services need their own credentials.
- Tighten audience and redirect validation Validate every token audience claim against the receiving MCP server and enforce exact redirect URI matching with no wildcards, partial matches, or query-string drift.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Exact implementation guidance for per-client consent registries and request validation flows
- The full authorization pattern breakdown for token audience checks, redirect URI matching, and state validation
- Deployment guidance for combining RBAC, ABAC, conditional access, and PBAC in live MCP environments
- Operational examples showing how secretless, short-lived credentials change agent access design
👉 Read Aembit's analysis of MCP permission models and agent access controls →
MCP authorization patterns: what IAM teams need to enforce?
Explore further
06/06/2026 3:39 am
MCP permission design fails when teams confuse user authentication with client authorisation. The article makes clear that a valid user session does not prove that any given agent or client should be allowed to act. That is a classic delegated-access mistake, and it is exactly where confused deputy failures emerge. The implication is that identity teams must stop treating user login as a sufficient authorisation event for agentic access.
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.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone.
A question worth separating out:
Q: Who is accountable when an MCP agent accesses the wrong resource?
A: Accountability sits with the teams that defined consent, token handling, and policy review for the MCP deployment. If token passthrough, weak audience checks, or incomplete client approval allowed the request, that is a governance failure, not an agent anomaly. Frameworks such as NIST CSF and Zero Trust architecture expect explicit access validation.
👉 Read our full editorial: MCP permission models that prevent confused deputy failures
