Delegated permissions are access rights granted through another identity, application, or administrative relationship rather than directly to the end user. They matter because revoking the visible account does not always remove the underlying authority, which can preserve access after offboarding.
Expanded Definition
Delegated permissions describe authority that is exercised through an intermediary identity, application, or administrative relationship rather than granted only to the end user. In NHI environments, that intermediary is often a service account, OAuth client, API gateway, or tenant-level admin role that can act on behalf of another principal.
This matters because delegation changes the control surface. A visible user account may appear removed, yet the delegated path can still authorize access until the upstream grant, token, consent, or trust relationship is revoked. That distinction is central to OWASP Non-Human Identity Top 10 guidance on hidden authority and to NHI governance patterns described in Ultimate Guide to NHIs — Key Challenges and Risks. Definitions vary across vendors, especially when products blur delegated access, impersonation, and application-scoped consent, so practitioners should verify the exact trust path being used. The most common misapplication is treating delegated permission revocation as complete when only the user object is disabled, which occurs when the underlying app consent or service-to-service trust remains active.
Examples and Use Cases
Implementing delegated permissions rigorously often introduces administrative overhead, because every upstream relationship must be tracked, reviewed, and revoked separately from the visible account.
- A collaboration app uses delegated API access to read mail or calendar data on behalf of a user, so offboarding must remove both the user access and the app consent.
- A CI/CD system assumes a deployment role through a service principal, creating a delegated path that can continue even if the original operator account is disabled.
- An admin portal grants a helpdesk group permission to reset passwords in tenant-specific contexts, which is delegation through role assignment rather than direct end-user entitlement.
- A third-party integration receives scoped access to create tickets or move records, and the delegation must be time-bound and reviewed against the OWASP Non-Human Identity Top 10 guidance on secret and token exposure.
- Enterprise offboarding checklists should include delegated token inventories, a point reinforced by Ultimate Guide to NHIs — Key Challenges and Risks where lingering access is a recurring risk factor.
Why It Matters in NHI Security
Delegated permissions are a common source of lingering access because they often survive account changes, policy drift, and incomplete revocation workflows. When organisations focus only on the human-facing account, they can miss the application grant, service trust, or role binding that actually carries authority. That gap is especially dangerous in NHI programs, where NHI Mgmt Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Good governance requires inventorying where delegation exists, who approved it, what scope it carries, and how quickly it can be withdrawn. It also requires periodic validation that consent, tokens, and impersonation rights match the intended business function. In practice, delegated permissions become a security incident amplifier when they are combined with excessive privilege, stale secrets, or weak change control, because the attacker inherits a trusted path instead of having to create one. Organisations typically encounter the consequence only after an offboarding event, tenant compromise, or audit exception, at which point delegated permissions become 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-02 | Delegated access often depends on secrets and tokens that must be tightly controlled. |
| NIST CSF 2.0 | PR.AA-05 | Delegated authority must be governed as part of identity and access management. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust requires continuous evaluation of trust relationships behind delegated access. |
Treat delegation as a dynamic trust decision and revalidate it before each sensitive action.
