Authorization laundering occurs when a person causes an action they could not perform directly by routing the request through a more privileged intermediary. In agentic systems, the agent can become that intermediary, so the control problem shifts from login authentication to delegated authority and runtime checks.
Expanded Definition
Authorization laundering is the abuse of delegated authority: a requester cannot perform an action directly, so the request is routed through an intermediary that does have the needed permissions. In human workflows, that intermediary may be a helper account, a privileged operator, or an automated approval path. In agentic systems, the intermediary is often an AI agent or service account that can invoke tools, APIs, or downstream systems on behalf of the user. The security question is not only whether the requester is authenticated, but whether the requested action is within the intermediary’s legitimate scope at runtime. This is why least privilege, explicit delegation boundaries, and step-up checks matter as much as login controls, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls. Definitions vary across vendors when this pattern appears in AI orchestration, but the core issue is consistent: authority is being stretched beyond its intended origin. The most common misapplication is treating delegated execution as equivalent to user intent, which occurs when systems trust the intermediary’s standing permissions without revalidating the specific action.
Examples and Use Cases
Implementing controls against authorization laundering rigorously often introduces workflow friction, requiring organisations to weigh automation speed against tighter runtime authorization checks.
- A support agent asks a privileged AI assistant to reset a customer’s MFA settings, even though the support agent lacks that permission directly.
- A CI/CD runner with deploy rights is used to push a configuration change requested by a low-privilege developer, bypassing review boundaries.
- An agentic procurement bot can approve a vendor action because its service account can call the approval API, even when the initiating user cannot.
- A helpdesk workflow routes a blocked account unlock request through an administrator queue, but the queue is auto-approved by a privileged intermediary without validating intent.
These patterns are easier to miss when organizations assume the presence of an approval layer equals proper authorization. The Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which makes intermediary abuse much easier when service accounts are broadly scoped. For policy mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary practitioners use to restrict and review delegated actions.
Why It Matters in NHI Security
Authorization laundering is dangerous because it turns one overly privileged NHI into a reusable bypass for many users, tasks, or agents. Once that intermediary is trusted, attackers do not need to steal a direct credential for the restricted action; they only need to influence the delegate path, tool invocation, or approval workflow. That risk is especially acute in agentic environments where an AI agent may execute with standing permissions and multiple downstream integrations. NHI Management Group notes in the Ultimate Guide to NHIs that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is exactly the governance context where delegated authority must be tightly bounded. The practical fix is to treat every delegated action as a separate authorization event, not as an automatic extension of the intermediary’s privileges. Organisations typically encounter this problem only after an incident review shows that a low-privilege request succeeded through a privileged agent or service account, at which point authorization laundering becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers overprivileged NHIs and delegated access paths that enable unauthorized action routing. |
| OWASP Agentic AI Top 10 | A-03 | Agent tool use can launder authority when user intent is executed through privileged agents. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and access review principles directly address delegated authority abuse. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires policy enforcement on each action, not trust in the calling intermediary. |
| CSA MAESTRO | GOV-2 | Agent governance frameworks address delegated execution, tool access, and approval boundaries. |
Constrain intermediary NHI privileges and require runtime checks for each delegated action.
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?
