Human-to-agent delegation is the transfer of execution from a person to an AI tool or agent that acts with some of the person’s credentials or permissions. The security challenge is that the delegated actor may behave faster, more broadly, or less predictably than the original human account owner.
What human-to-agent delegation actually changes
Human-to-agent delegation is not just a convenience pattern, it changes who is effectively operating under the human’s authority. Once an AI agent can act with borrowed credentials or permissions, the security boundary shifts from a person making individual decisions to software making many rapid ones.
That matters because the delegated actor may combine speed, breadth and autonomy in ways the original user did not intend. A human can usually notice a questionable step; an agent can chain several legitimate steps together before anyone intervenes.
Where delegation fits in the identity and access model
Delegation sits inside the broader identity and authorization problem. The core question is not whether the human is trusted, but what the agent is allowed to do on the human’s behalf, for how long, and under what conditions.
That makes the subject closely related to RFC 8693: OAuth 2.0 Token Exchange, because token exchange is one of the clearest standards-based ways to represent on-behalf-of use and delegated authority. It also connects to AI Agent Authorisation Guide, which focuses on task-scoped access, per-action decisions and human approval gates for agent activity.
In practice, the security meaning of delegation depends on whether the agent inherits the human’s standing access, receives a narrowed token, or is forced through fresh policy checks for each action. Those choices determine whether delegation remains controlled or becomes indistinguishable from full account sharing.
Delegation, autonomy and the agent lifecycle
Human-to-agent delegation is most useful when the agent can complete a bounded task without constant supervision, but that same autonomy creates lifecycle questions. A delegation that is safe for one action may be unsafe once reused, persisted, or attached to a broader workflow.
This is why the agent’s identity state, ownership and revocation path matter as much as the initial grant. Agentic AI Identity Guide is relevant here because it treats delegation, registration, ownership and retirement as lifecycle questions, not one-time setup steps.
The same logic is echoed by Zero Trust for AI Agents, which frames every action as something to verify, not something to trust just because it originated from an approved user. For delegation, that means the agent should be evaluated as its own actor at runtime, even when it is acting for a legitimate person.
Why delegated access creates a bigger attack surface
Delegation expands the attack surface because an attacker no longer needs only the human account, they may only need the delegated path, the token, or the agent’s overbroad permissions. That creates exposure to misuse, accidental overreach and hard-to-attribute activity.
The problem becomes more serious when delegated credentials are long-lived, copied across tools, or reused in multiple environments. NHI Authentication Guide is relevant because delegated agents often rely on the same authentication building blocks used by other non-human actors, including short-lived tokens, federation and sender-constrained approaches.
Threat-wise, delegation can support confused-deputy behaviour, privilege escalation through inherited access, and actions that look legitimate because they were technically performed using valid credentials. The more capable the agent, the more important it becomes to separate identity, authority and approval rather than treating them as one grant.
Risk and Threat Considerations
Human-to-agent delegation creates a material security risk because a legitimate human permission can be turned into broad, fast, and difficult-to-audit machine action. The danger is not only compromise, but also overreach, where an agent stays within its technical allowance while exceeding the human’s practical intent.
Failure mechanism: Delegated access is too broad, too persistent, or too weakly bound to the specific task, so the agent can reuse borrowed authority, chain actions, or act in contexts the human never reviewed.
Impact: Attackers can abuse delegated credentials or legitimate operators can trigger unintended high-impact actions, leading to data exposure, unauthorized transactions, lateral movement, or hard-to-reconstruct incidents.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Human-to-agent delegation directly concerns borrowed authority and agent privilege use. |
| Recommendation — Bind delegated agent actions to task-scoped identity and limit inherited privilege. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Delegated agents authenticate as non-human actors using token and service-like credentials. |
| AC-6 — Least Privilege | Delegation becomes risky when the agent receives more access than the task requires. | |
| IA-5 — Authenticator Management | Delegation depends on issuing, rotating and revoking the credentials or tokens the agent uses. | |
| Recommendation — Use IA-9 to authenticate the agent independently of the human account. Enforce AC-6 so delegated access is narrowed to the minimum necessary permissions. Apply IA-5 to issue short-lived credentials and revoke delegated access quickly. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Identity Management, Authentication and Access Management | Zero trust requires per-request verification of delegated agent access and authority. |
| Recommendation — Verify each delegated action and remove standing privilege where possible. | ||
Practitioner Guidance
Why practitioners should care: Delegation should be designed as a bounded authority model, not as a convenience feature. The practical question is whether the agent can do the minimum necessary work without inheriting more of the human’s access than the task requires.
Common misunderstanding: A signed-in user does not make agent action automatically safe. If the agent can continue acting after the person has stopped watching, the control problem is no longer just authentication, it is delegated authorization and revocation.
Practitioner takeaway: Treat the human as the origin of intent, but treat the agent as the runtime actor that must be constrained, observed, and retired on its own terms.