A machine or agent identity that acts on behalf of a user or system and inherits access to connected tools. The control problem is not only authentication, but the scope, duration, and downstream reach of that delegation once the session is established.
Expanded Definition
Delegated non-human identity describes an NHI that performs actions on behalf of a user, workload, or system and inherits a slice of that principal’s authority. In practice, the identity may be created by an API gateway, workflow engine, AI Agent, or automation platform, then used to call downstream tools, data stores, and internal services.
The key distinction is that delegation is not the same as static authentication. A token may prove the caller is legitimate, but the security question is whether the delegated scope, session duration, and downstream reach are tightly bounded. Guidance across vendors is still evolving, especially where MCP-style tool use, JIT access, and ZSP policies intersect with RBAC. NIST’s Zero Trust Architecture guidance is useful here because it treats every request as a policy decision, not a one-time trust event, which aligns well with delegated access paths. See also the Ultimate Guide to NHIs for the broader lifecycle model and the NIST Cybersecurity Framework 2.0 for governance-oriented access control concepts.
The most common misapplication is treating delegated NHI access like a normal service account, which occurs when teams reuse a long-lived identity for broad tool access after the original user context has changed.
Examples and Use Cases
Implementing delegated NHI rigorously often introduces session-management and policy complexity, requiring organisations to weigh automation speed against tighter limits on what the identity may do.
- An AI Agent is allowed to draft a support ticket, but its delegated identity cannot export customer records unless a separate approval step grants JIT access.
- A workflow that triggers from a payroll system uses delegated access to update a downstream HR platform, with RBAC restricting field-level write permissions.
- A developer portal issues a short-lived delegated token for a build pipeline so the pipeline can retrieve secrets from a vault, but not create new credentials.
- An operations bot receives delegated authority from an incident commander during a major outage, then loses that authority automatically when the incident is closed.
- A federated application exchanges one user action for several tool calls, but every call is evaluated against policy to prevent excessive downstream reach, a pattern discussed in the Ultimate Guide to NHIs — What are Non-Human Identities and reflected in implementation lessons from the Top 10 NHI Issues.
These patterns are especially relevant in tool-using systems, where delegated authority can cross trust boundaries faster than security teams expect. Zero Trust design guidance from NIST Cybersecurity Framework 2.0 helps frame the control objective: constrain each action, not just the login event.
Why It Matters in NHI Security
Delegated non-human identities matter because compromise rarely stays local. Once a delegated session is hijacked, the attacker may inherit the original principal’s reach into code repositories, cloud APIs, secret stores, or internal automation systems. That makes the scope of delegation a governance issue, not just an IAM configuration detail. NHI Management Group’s research shows that 97% of NHIs carry excessive privileges, which means many delegated identities are likely broader than their business purpose requires.
This is why practitioners should pair delegation with expiration, step-up approval, and continuous policy evaluation. The operational lesson from incidents such as the Cisco DevHub NHI breach and the JetBrains GitHub plugin token exposure is that a delegated identity can become a multiplier for blast radius when its authority is not bounded in time and context. Organisations typically encounter this consequence only after a token leak, misuse of an automation account, or audit finding, at which point delegated 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 |
|---|---|---|
| NIST Zero Trust (SP 800-207) | 3 | Zero Trust requires continual policy checks for each delegated request. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Delegated identities expand secret and privilege exposure if poorly scoped. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must reflect least privilege for delegated non-human identities. |
Evaluate every delegated action before execution and expire access as soon as context changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
