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.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “MCP Permission Models: Designing Secure Interactions”.
Key questions
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 audience-bound tokens matter for MCP authorization?
A: MCP clients can move across multiple resource servers in a single session, so generic tokens create replay risk and scope ambiguity.
Q: How do security teams decide whether an MCP agent has too much access?
A: A useful test is whether the agent can read data, trigger actions, and move across systems with one broad entitlement.
Practitioner guidance
- Implement server-side per-client consent Bind each user approval to a specific client identifier and granted scope, and reject any request that lacks a consent record for that exact client-user pair.
- Enforce token audience validation Check that every incoming token is intended for the MCP server that receives it, and reject tokens whose audience matches a different service even if the signature is valid.
- Eliminate token passthrough in the MCP path Require downstream services to obtain their own delegated credentials through token exchange or an equivalent server-side delegation flow instead of forwarding the original user token.
Bottom line: MCP authorization fails when user consent is not bound to a specific client, because that turns legitimate authority into a confused deputy risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 23 hours ago by NHI Mgmt Group
06/06/2026 3:39 am
Confused deputy risk is the core MCP authorization failure mode. MCP does not fail because agents are dynamic. It fails when delegated authority is treated as portable across clients, users and tools without an explicit consent binding. That breaks the basic access-control premise that the requester and the approved client are the same thing. The practical conclusion is that MCP governance has to start with per-client authorization, not with generic role design.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations use RBAC, ABAC or PBAC for MCP deployments?
A: Use them in layers, not as substitutes for the MCP baseline controls. RBAC is useful for broad boundaries, ABAC adds context, and PBAC centralizes decisions for complex environments, but none of them replaces per-client consent or audience validation. The right choice depends on how dynamic the agent’s access pattern is.
👉 Read our full editorial: MCP permission models that prevent confused deputy failures
This post was modified 23 hours ago by NHI Mgmt Group