The identity a system uses when an agent acts on behalf of a human or another agent. It includes the delegator, the executing agent, the target resource, and the policy context needed to decide whether the action is still within scope.
Expanded Definition
delegated execution Identity is the operational identity used when an AI agent or other system performs an action on behalf of a human, another agent, or a workflow. It is not just a login surrogate. It binds the delegator, the executor, the target resource, and the policy context that determines whether the action remains authorised.
In NHI governance, this matters because delegated execution can be narrow, time-bound, and resource-specific, or it can expand into broad standing access if the policy layer is weak. The term is still evolving across vendors, so some platforms describe it as delegated authority, impersonation, run-as identity, or service-to-service delegation. NHI Management Group treats it as a distinct control concept because the identity must be evaluated at runtime, not assumed from the original human request. That distinction aligns closely with the NIST Cybersecurity Framework 2.0 emphasis on access governance and continuous risk treatment, and it also reflects the identity boundaries discussed in the Ultimate Guide to NHIs.
The most common misapplication is treating delegated execution as a normal service account, which occurs when an organisation fails to preserve the delegator, scope, and expiry context during automation.
Examples and Use Cases
Implementing delegated execution identity rigorously often introduces policy and telemetry overhead, requiring organisations to weigh tighter authorisation against more complex orchestration and audit design.
- An employee approves a payment workflow, and an agent executes the transfer only within the approved amount and time window.
- A support agent requests a password reset, while a delegated identity allows the workflow engine to query only the specific user record needed for that ticket.
- A CI/CD assistant rotates a certificate on behalf of a platform engineer, but only for the named application and only during a maintenance window.
- An internal copilot drafts a procurement action, and a delegated identity submits the request after policy checks confirm role, budget, and target system constraints.
- In breach analysis, NHIMG’s 52 NHI Breaches Analysis and the Top 10 NHI Issues show how exposed identities and weak scoping turn routine automation into an access pathway; this is why the delegation context must be preserved alongside execution.
These scenarios sit close to standards-based identity federation and runtime authorisation patterns described by NIST and related guidance, but no single standard governs delegated execution identity yet.
Why It Matters in NHI Security
Delegated execution identity becomes a governance issue the moment an agent can act beyond the original user session. If the delegator, scope, and expiry are not enforced, an agent may keep acting after the business need has ended, which turns a valid workflow into persistent access. That is how task automation becomes privilege drift.
The risk is not theoretical. NHI Management Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, which makes uncontrolled delegation especially dangerous. The same pattern appears in operational incidents such as the Cisco DevHub NHI breach and the JetBrains GitHub plugin token exposure, where identity scope and secret handling became part of the blast radius.
Practitioners should treat delegated execution as a Zero Trust control point: verify who delegated, what the agent may do, where it may act, and how long that authority lasts. Organisations typically encounter this consequence only after an audit failure, unauthorized action, or incident review, at which point delegated execution identity 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 Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers excessive or poorly scoped non-human identity permissions. |
| NIST Zero Trust (SP 800-207) | JIT | Zero Trust requires continuous verification of access decisions at runtime. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and reviewed as part of identity governance. |
Revalidate delegated authority for each action and revoke when context changes.
