Surrogate delegation is when one person is authorised to act on another person’s behalf for a defined task or decision. In access control, it uses delegated approval, proxy assignment or temporary entitlement changes, with the accountable human and scope clearly recorded.
What Surrogate Delegation Means in Access Control
Surrogate delegation is a controlled form of acting on behalf of another person. The key security property is that the authority is limited, explicit, and tied to a defined purpose, rather than becoming a broad substitute for the original account or role.
In practice, surrogate delegation is used when approval, review, or administrative action must continue even though the principal is unavailable. That can include proxy approval, delegated sign-off, temporary role elevation, or a formally recorded substitute decision-maker.
How Surrogate Delegation Differs from Shared Access
Surrogate delegation is not the same as shared credentials, informal password handoff, or a standing second user who can do anything the first user can do. The delegated person should act only within the approved scope, and the system should preserve who approved, who acted, and under what authority.
This distinction matters because surrogate delegation preserves accountability. If the original owner remains the accountable party, the delegation record must show the scope, start and end condition, and the action trail. Without that, organisations lose the ability to distinguish legitimate proxy action from improper use.
Where It Appears in Governance and Operations
Surrogate delegation is common in approvals, access reviews, procurement sign-off, clinical or legal substitution, and administrative continuity processes. It is also used when temporary coverage is needed for absence, escalation, or emergency decision-making.
Because the authority is time-bound or task-bound, organisations need a clear model for who can delegate, who can receive delegated authority, and what the surrogate may do. A strong implementation keeps the underlying principal visible, rather than replacing them with an indistinct replacement identity.
For delegated authority flows built on token exchange or on-behalf-of patterns, RFC 8693: OAuth 2.0 Token Exchange is the clearest standards reference for how delegation can be expressed safely and traceably.
Security Controls and Traceability Requirements
The security value of surrogate delegation depends on tight scope, short duration, and auditability. The delegated action should inherit only the permissions needed for the task, and those permissions should expire automatically when the task or approval window ends.
Good implementations also separate the act of delegation from the act of execution. That separation reduces the chance that a temporary proxy becomes a durable privilege path, and it makes reviews easier when the organisation needs to prove who authorised what.
Control thinking from NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame surrogate delegation as a combination of access control, accountability, and audit logging rather than a purely procedural approval pattern.
Risk and Threat Considerations
Surrogate delegation creates risk when the substitute authority is broader than intended, longer lived than necessary, or poorly recorded. The danger is usually not the delegation itself, but the drift that turns a narrow proxy into a standing privilege path.
Failure mechanism: Attackers or insiders can abuse delegated authority if the surrogate path is weakly scoped, difficult to revoke, or indistinguishable from normal owner activity. Poor logging can also hide misuse by making it hard to tell whether a surrogate acted legitimately or under coercion, compromise, or convenience.
Impact: The result can be unauthorised approvals, unintended data access, fraudulent transactions, or privileged action taken without effective oversight. In the worst case, one weak delegation mechanism becomes a repeatable shortcut around normal approval controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Surrogate delegation must constrain the proxy to only the authority needed for the task. |
| AC-2 — Account Management | Delegated authority depends on clear assignment, tracking, and revocation of who may act on behalf of whom. | |
| AU-2 — Audit Events | Proxy actions need logged evidence showing who delegated, who acted, and under what scope. | |
| Recommendation — Limit delegated authority to the minimum permissions needed for the approved action. Track delegated relationships and remove them when the need ends. Log delegated actions so the surrogate trail is auditable and attributable. | ||
Practitioner Guidance
Governance implication: Surrogate delegation should have an explicit owner, a defined scope, and a revocation rule. If the business cannot explain who may delegate, for which decisions, and for how long, the control is too ambiguous to be reliable.
What to watch for: Look for delegation that persists after the original need has passed, approvals that do not show the surrogate relationship, and exception processes that quietly become routine. Those are the clearest signs that delegated authority is replacing accountability instead of supporting it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org