Authorization Laundering

What Authorization Laundering Means

Authorization laundering is a delegation failure: the requester is not entitled to do the action directly, but can make a more privileged intermediary do it on their behalf. The security issue is not merely who logged in, but who is allowed to decide, submit, approve, or execute the action at runtime.

In practice, this pattern appears when systems treat a request as legitimate because it comes from a trusted intermediary, even though the original requester should not have the same power. That makes the trust boundary, not the login screen, the real control point.

Why It Is Dangerous in Agentic and Delegated Workflows

Authorization laundering is especially risky in agentic workflows because an autonomous agent can become the intermediary that inherits broad permissions and then acts on a user’s intent without preserving the original authorisation context. That can turn a narrow request into an overbroad action, particularly when tools, APIs, or downstream services trust the agent more than the initiating human.

The danger is that privilege becomes mobile. Once a privileged intermediary can relay requests, the environment may no longer distinguish between “the user may ask” and “the user may do,” which creates a path around least privilege and policy checks.

For a practical control lens, AI Agent Authorisation Guide is useful because it focuses on task-scoped access, delegated authority, and per-action approval for agents.

How Organisations Recognise and Contain the Pattern

Exposure usually shows up where one identity, service, or agent can forward requests that originated elsewhere, especially when the downstream system only validates the intermediary’s authority. Organisations should examine where user intent, approval, and execution are merged, and where a privileged channel can be reused to perform actions that the original requester could not perform directly.

Containment depends on preserving the original actor, the delegated scope, and the decision point separately. That means externalised policy checks, explicit audience restrictions, and runtime enforcement that evaluates each action against the true requester and the requested operation, not just the relay path.

Authorisation Models Guide helps frame when RBAC, ABAC, ReBAC, or policy-based control is better suited to per-action decisions. Model Context Protocol: Authorization specification shows how runtime authorization and token handling should be designed so the server does not silently trust forwarded authority.

Security Implications for Identity, Session, and Privilege Design

This term matters because the security failure is often architectural. If authorisation is only checked at initial login, or if a session can be reused across tools and steps without re-evaluating authority, then a user can indirectly obtain capabilities that policy would otherwise deny. The same issue can surface in enterprise applications, APIs, and AI systems that mix user context with service context.

The practical design lesson is to separate authentication from authorisation, keep delegated scope narrow, and make privilege decisions close to the resource or action being requested. A system should be able to prove not just that a caller is authenticated, but that the caller is entitled to this specific action in this specific context.

IAM and IGA Basics is the natural foundation for understanding the distinction between authentication, authorisation, provisioning, and entitlement governance. Externalised Authorisation Buyer's Guide is useful where teams need a policy engine that can make consistent decisions outside the application.

Practitioner Guidance

Why practitioners should care: Authorization laundering is a policy bypass pattern, not just an implementation quirk. If your platform lets a privileged intermediary act without preserving who asked for the action and why, you lose the ability to enforce least privilege at runtime.

What to watch for: Pay special attention to systems where agents, service layers, or automation can submit actions on behalf of users, especially when approval, delegation, and execution are collapsed into one hop. That is where overreach and hidden privilege amplification tend to appear.

Practitioner takeaway: Treat delegated authority as a first-class control problem, and require every meaningful action to carry the original actor, the delegated scope, and the policy decision that justified it.

Related resources from NHI Mgmt Group

• What are MCP Authorization Extensions and how do they help organizations?
• Why is it necessary to address authorization challenges in AI agent deployment?
• When should organisations use runtime authorization for AI agents?
• What is the difference between prompt-based control and runtime authorization for agents?