Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
Expanded Definition
Delegated access is not the same as a permanent shared account or a broad service credential. It is an explicit permission grant that lets one identity perform limited actions on behalf of another, usually through OAuth scopes, token exchange, or application-level impersonation. In NHI security, the critical question is not whether delegation exists, but whether it is bounded by purpose, duration, and revocation. The OWASP Non-Human Identity Top 10 treats identity scope, secret exposure, and excessive permission as recurring risk patterns, and those same patterns surface whenever delegated access is treated as a convenience instead of a control surface. Definitions vary across vendors when products describe delegation as “impersonation,” “on behalf of,” or “consent-based access,” so operators should inspect the actual token, scope, and audit trail rather than rely on labels. The most common misapplication is granting delegated access without an expiry or review trigger, which occurs when a business process is automated once and never re-validated.
Examples and Use Cases
Implementing delegated access rigorously often introduces workflow friction, requiring organisations to balance automation speed against tighter approval, scoping, and revocation controls.
- A helpdesk app uses delegated access to update user profiles in a directory, but only after a specific administrator approves the scope and time window.
- A finance automation tool accesses an email inbox to extract invoices, while token permissions are limited to read-only and only for a defined mailbox.
- A customer support platform sends messages on behalf of an agent, but the delegation is revoked when the case closes and the agent leaves the queue.
- An internal approval bot acts on behalf of a manager for low-risk actions, while higher-risk changes require step-up controls and separate logging.
For implementation guidance, the Ultimate Guide to NHIs explains why delegated permissions should be treated like any other non-human access path: scoped, observable, and removable. When teams want a deeper view of failure patterns, the 52 NHI Breaches Analysis shows how over-permissioned identities repeatedly widen blast radius after compromise. In practice, delegated access is also common in federation models discussed by the same standards ecosystem that informs OWASP Non-Human Identity Top 10, especially where a human approval flow hands authority to automation for a narrow purpose.
Why It Matters in NHI Security
Delegated access becomes a security issue when the original intent is forgotten but the permission remains active. That is how legitimate automation turns into silent standing privilege. In NHI environments, this matters because delegated identities often inherit access to mailboxes, APIs, storage, and admin consoles that are far broader than the task actually requires. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which is why delegated access must be reviewed with the same seriousness as service accounts and API keys. The governance failure is usually not delegation itself, but lack of lifecycle control: no expiry, no owner, no periodic attestation, and no clear revocation path. That is why the Ultimate Guide to NHIs ties identity governance to rotation, offboarding, and Zero Trust thinking. Organisations typically encounter delegated access as a problem only after an automation account outlives the business process it was created for, at which point the permission is 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 | Covers over-privileged and improperly scoped non-human access paths. |
| NIST CSF 2.0 | PR.AA-5 | Supports identity management for services and access delegation governance. |
| NIST Zero Trust (SP 800-207) | SP 5 | Zero Trust requires every delegated request to be explicitly authorized and continuously evaluated. |
Track delegated identities, owners, and lifecycles to keep access current and auditable.
