A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
Expanded Definition
Delegated authorization is the pattern that lets an application, integration, or agent perform actions on behalf of a user after explicit consent. In NHI practice, the delegated actor becomes a durable Non-Human Identity when the grant persists beyond the original session, which is why definitions vary across vendors and no single standard governs this yet. The concept is closely related to OAuth-based consent flows, but the security question is not just whether a token was issued; it is whether the scope, lifetime, and revocation path are fit for operational use. NIST Cybersecurity Framework 2.0 helps frame the governance problem through access control and recovery discipline, while the NIST Cybersecurity Framework 2.0 reminds practitioners that authorization must remain traceable and adjustable across the asset lifecycle. NHI Management Group treats delegated authorization as an identity governance issue, not a convenience feature, because the approved app often inherits enough trust to behave like an internal service account.
The most common misapplication is treating user consent as permanent entitlement, which occurs when broad scopes are granted to SaaS apps and never revisited after the original business need changes.
Examples and Use Cases
Implementing delegated authorization rigorously often introduces user-friction and lifecycle overhead, requiring organisations to weigh workflow convenience against revocation discipline and scope minimisation.
- A calendar integration can read and create events on a user’s behalf, but only if the scopes are narrowly bounded and the token is revoked when the employee leaves.
- An AI assistant can draft emails or update tickets for a manager, but the approval chain should be time-bound and reviewed under the same governance lens described in the Ultimate Guide to NHIs.
- A finance SaaS connector may need delegated rights to sync invoices, yet the integration should not inherit full mailbox access just because the vendor recommends it.
- An internal workflow tool may act on behalf of a user to provision cloud resources, but the resulting permissions should be mapped to role boundaries and monitored like any other NHI.
- An external partner app may request consent for a single project, but operators must confirm that the approval is not silently reused across tenants or environments.
In practice, the strongest implementations combine consent logs, scoped tokens, and periodic access review, then validate those controls against the NIST Cybersecurity Framework 2.0 and related least-privilege principles.
Why It Matters in NHI Security
Delegated authorization matters because it is one of the easiest ways for an ordinary business app to become a high-trust NHI. Once an integration receives broad scopes, it can bypass human checkpoints, persist across sessions, and retain access even after the original user no longer understands what was approved. That is exactly the kind of risk highlighted in Ultimate Guide to NHIs, where 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. Weak delegated models also undermine zero trust because the grant can outlive both the user intent and the business need. For governance teams, the important question is not whether the app was “allowed once,” but whether it can still act today, with the same scope, under the same risk assumptions. Organisations typically encounter the consequence only after an account compromise, a failed offboarding, or an audit that reveals stale OAuth grants, at which point delegated authorization 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 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 over-privileged non-human access created by delegated grants. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should stay aligned to least-privilege governance. |
| NIST Zero Trust (SP 800-207) | Section 4.1 | Zero Trust requires continuous verification of trusted app actions. |
Map delegated authorization scopes to least-privilege reviews and enforce timely revocation.
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?
