User-centric IAM assumes a stable subject, a predictable session, and fixed access paths. MCP agents can change tool choice and context at runtime, so static entitlements, hard-coded permissions, and per-app logic become brittle. Governance has to move to a runtime policy plane that evaluates each delegated action against scope and consent.
Why MCP authentication breaks the user-centric IAM assumption
User-centric IAM works when a person is the stable subject of control: you know who signed in, what session they have, and which app they are using. MCP changes that shape. The authenticated actor may be an agent making delegated decisions across tools, so the control point is no longer a single user session but a runtime transaction that can shift context, scope, and destination mid-flow.
This is why bolting MCP onto a login-and-app-permission model feels brittle. The model tries to infer trust from a static subject, while the real decision is about whether a specific delegated action should be allowed right now. In practice, that means the security boundary moves from user identity alone to the action, the tool, the scope, and the consent state attached to that action.
When the underlying pattern is agentic, the relevant guidance shifts toward runtime authorization and delegated authority. MCP Security Guide and MCP authorization specification both reflect that the protocol needs action-level controls, not just user sign-in.
What becomes brittle in practice
The first breakage is in entitlement design. Static roles, hard-coded permissions, and per-application allowlists assume the subject and workflow are known in advance. MCP agents do not stay fixed that way. They may choose different tools, chains, or resources at runtime, which makes coarse permissions either too broad to be safe or too narrow to be usable.
The second breakage is session logic. Traditional IAM often treats the session as evidence that the next action is valid because the same user remains active. That assumption fails when an agent can continue acting after the initiating user has moved context, changed intent, or stopped watching. The control question becomes whether the delegated action still matches the original scope and consent, not whether the session is still alive.
The third breakage is policy placement. If authorization only happens at login, you miss the point where risk actually appears, which is when the agent selects a tool or sends data to a server. That is why runtime policy planes matter. They can inspect scope, requested resource, and delegation context on every call instead of assuming the first authentication event is enough.
For a broader agentic security view, OWASP Agentic AI Top 10 is useful because it treats identity and privilege abuse as part of the agent threat model, not as an afterthought.
What a runtime policy plane must decide
The practical shift is from “who is logged in?” to “what is this delegated actor allowed to do, with which tool, against which resource, and under what current consent?” That requires evaluation at the moment of action, ideally with awareness of scope, audience, tool sensitivity, and whether the request matches the user’s intent.
This is also where MFA, single sign-on, and traditional federation become supporting controls rather than complete answers. They still matter for the human entry point, but they do not resolve tool misuse, confused deputy conditions, or overly broad delegation once the agent is operating. The best implementations separate human authentication from runtime authorization and treat them as different decisions.
In mature deployments, the policy layer should be able to deny, narrow, or re-authorize a tool call without breaking the whole session. That is the key design change: the agent should not inherit unlimited continuity from the user’s login just because the login was valid a few minutes ago.
For teams building the identity side of that stack, AI Agent Identity Security: The 2026 Deployment Guide and MCP Security Guide are the strongest internal navigation points because they connect authentication to delegated action, ephemeral credentials, and tool-level control.
Risk and Threat Considerations
Bolting MCP authentication onto a user-centric IAM stack creates a classic confused-deputy risk. The user may be properly authenticated, but the agent can still be steered into using legitimate authority for an unintended tool, resource, or data exchange. If the control plane cannot see the runtime decision, the system may grant access that looks valid at the login layer but is unsafe at the action layer.
Failure mechanism: Static entitlements and session-based trust are applied to an actor whose tool choice and context change at runtime, so the security decision lags the actual request.
Impact: Over-permissioned agents can exfiltrate data, invoke unintended tools, or repeat actions outside the user’s current intent, turning a valid login into a broad abuse path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP agent delegation creates runtime privilege abuse risk. |
| ASI02 — Tool Misuse | MCP security hinges on whether tools are invoked within intended scope. | |
| ASI09 — Human-Agent Trust Exploitation | User-centric IAM can over-trust agent actions that outlive user intent. | |
| Recommendation — Enforce least privilege and per-action checks for delegated agent tool use. Validate tool calls against current intent and deny unsafe tool selection. Bind approval and consent to the exact delegated action, not the login session. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MCP deployments often depend on managing tokens and other authenticators safely. |
| AC-6 — Least Privilege | Static permissions become brittle when agent actions change at runtime. | |
| AC-3 — Access Enforcement | Runtime policy enforcement is central when MCP decisions occur per action. | |
| Recommendation — Rotate and protect authenticators used for delegated agent access. Limit each agent action to the minimum resource and scope required. Enforce authorization at the point of tool invocation and resource access. | ||
Practitioner Guidance
What to prioritise: Put runtime authorization ahead of any attempt to “fit” MCP into existing app-permission patterns. The control must decide each delegated action, not just the initial login.
What to verify: Confirm that your policy engine can evaluate tool, resource, and scope on every call, and that it can fail closed when the request cannot be mapped to current consent.
Common mistake: Treating OAuth, SSO, or MFA as if they solve agent authorization by themselves. They authenticate the user, but they do not bound the agent’s runtime authority.
Practitioner takeaway: If the control model cannot follow the action as it changes, it is the wrong model for MCP; the right design is consent-aware, tool-aware, and enforced at runtime.
Related resources from NHI Mgmt Group
- Why does MCP change the IAM conversation for agents?
- What breaks when agent access is bolted onto existing IAM stacks?
- What breaks when authentication is bolted onto an AI product too late in the build process?
- What breaks when API security is bolted onto IAM instead of designed as a separate control layer?