What breaks when MCP permissions rely only on user login and roles?

Why This Matters for Security Teams

MCP permissions that rely on user login and RBAC can look correct on paper while failing at the point that matters most: the request itself. A logged-in user may be allowed to use a tool, but that does not prove the specific MCP client, workload, or agent was approved to invoke it in that moment. That gap creates confused deputy conditions, cross-tool privilege leakage, and weak auditability. The same pattern shows up in broader agentic risk research, including NHIMG’s OWASP Agentic Applications Top 10 and the external OWASP Agentic AI Top 10, both of which highlight that autonomous systems need request-level controls, not just account-level trust.

For MCP, the core issue is that identity alone does not express intent. A human session can be legitimate while the agent action is not. Security teams therefore need server-side consent, explicit client scoping, and policy checks that evaluate what is being requested, which tool is being called, and whether that call fits the approved purpose. In practice, many security teams encounter this only after an agent has already used a valid login to reach a tool it was never meant to touch.

How It Works in Practice

Effective MCP governance treats the agent or client as a workload identity, then validates each tool call against context at runtime. That means the server should not trust inherited user roles alone. It should confirm the client identity, the user consented scope, the action requested, and the target resource before issuing access. This is where intent-based authorisation becomes more useful than static RBAC. Rather than asking, “Does this user have a role?” the policy asks, “Is this specific client allowed to perform this specific operation for this specific task?”

Current guidance suggests combining short-lived credentials, request signing, and policy-as-code so approval can be enforced per call rather than per session. For agentic systems, that often pairs well with JIT credential provisioning and ephemeral secrets, because a long-lived token can outlive the task that justified it. The operational pattern is similar to the controls discussed in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and reinforced by the external OWASP Non-Human Identity Top 10.

• Bind the MCP client to a workload identity, not just a browser session or user token.
• Evaluate policy at request time with full context, including tool, scope, tenant, and purpose.
• Issue JIT credentials with narrow TTLs, then revoke them when the task ends.
• Log the client, user, prompt, tool, and decision outcome for audit and incident response.

That model is especially important for autonomous agents that chain tools or call downstream services without a human pause, because a valid user session can still become a high-risk execution path. These controls tend to break down when MCP is deployed as a simple proxy over human IAM, because the server cannot distinguish approved user access from approved client behaviour.

Common Variations and Edge Cases

Tighter client-scoped authorization often increases operational overhead, requiring organisations to balance security gain against onboarding friction and policy maintenance. There is no universal standard for this yet, so implementation details vary across vendors and platforms. Some teams use a coarse allowlist for early rollout, while others enforce per-tool and per-action approval from day one.

The hardest edge case is delegated access, where a human asks an agent to act on their behalf but the agent then uses that trust to expand into adjacent tools. In those environments, RBAC may still have a role, but only as a baseline control. It should be paired with runtime checks, explicit delegation boundaries, and short-lived secrets that cannot be reused outside the intended task. NHIMG’s Analysis of Claude Code Security shows why code-execution and tool-use contexts demand more than traditional login gates, while the external OWASP Top 10 for Agentic Applications 2026 frames the broader risk of autonomous privilege use.

For high-trust environments, best practice is evolving toward zero standing privilege, continuous policy evaluation, and explicit client consent per action. That is not just a better authentication pattern. It is the minimum needed to keep an authorised user from becoming an accidental proxy for an unauthorised MCP client.

Related resources from NHI Mgmt Group

• What breaks when agents are given a human user's permissions?
• What breaks when organisations rely only on native AI safety controls?
• What breaks when AI agents rely on static secrets?
• What breaks when Slack app permissions are too broad for AI agents?