The act claim is a JWT claim defined by RFC 8693 to represent delegation in a token. It identifies the acting party and can nest to show a chain of prior actors. This lets policy and audit systems distinguish impersonation from delegation and preserve who actually performed the request.
Expanded Definition
The act claim is a delegation-oriented JWT claim defined by RFC 8693 that identifies the party acting on behalf of another party, and it may be nested to preserve a chain of prior actors. In NHI security, that distinction matters because a token can represent both the original subject and the current acting identity, which is critical when an AI agent, service account, or automation layer performs an operation under delegated authority. The broader standard context is the OAuth 2.0 Token Exchange model in RFC 8693, where the act claim helps policy engines and audit systems answer not just “who is authorized,” but “who actually executed the request.” This is especially important when identities are chained across workloads, brokers, or agents, because delegated execution can otherwise look like direct impersonation. Guidance varies across vendors on how much of the delegation chain to preserve, so implementations should treat the claim as an audit and authorization signal, not as a standalone proof of trust. The most common misapplication is collapsing act into a generic subject field, which occurs when platforms ignore delegation context and then misattribute actions to the wrong principal.
Examples and Use Cases
Implementing the act claim rigorously often introduces token-handling and logging complexity, requiring organisations to weigh clearer accountability against more demanding policy evaluation and audit correlation.
- An AI agent exchanges a user token for a downstream API token, and the act claim records the agent as the active executor while preserving the user as the delegating origin.
- A privileged automation workflow invokes a secrets retrieval service, and the act chain shows the scheduler, the service account, and the original operator for forensic review.
- A federation gateway forwards a request through multiple trust domains, and the act claim helps distinguish legitimate delegation from direct credential theft.
- Incident responders trace an unauthorized configuration change using delegation evidence alongside guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls to verify who had effective control at each hop.
- Research on DeepSeek breach shows how exposed credentials and exposed systems can create confusion about which identity truly acted, making delegation evidence valuable in post-incident analysis.
Why It Matters in NHI Security
Delegation claims are a governance control as much as an identity feature. When NHI programs fail to preserve acting identity, organizations lose the ability to separate approved delegation from credential misuse, especially in environments where service accounts, AI agents, and orchestration layers operate with broad permissions. That creates gaps in detection, response, and accountability. In practice, the act claim supports traceability across token exchange boundaries, which makes it easier to map behavior back to the real executor instead of the token holder. This is directly relevant to NHI control design because delegated authority is often where over-privilege hides, and where incident reviewers need evidence that a request was relayed rather than originated. The State of Secrets in AppSec data from GitGuardian and CyberArk is a reminder that secrets handling and identity accountability are tightly coupled, since leaked credentials can quickly blur the line between valid delegation and abuse. The other relevant NHIMG case study is LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where compromised credentials can let attackers operate through legitimate-looking execution paths. Organisations typically encounter the need for act-claim evidence only after an unauthorized action has already propagated through delegated systems, at which point delegation tracing 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 Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, 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 Agentic AI Top 10 | AI-04 | Delegated agent actions need clear actor attribution to distinguish tool use from impersonation. |
| OWASP Non-Human Identity Top 10 | NHI-07 | NHI governance depends on traceable service and workload identity delegation. |
| NIST SP 800-63 | Digital identity guidance informs authentication context and token-based delegation trust. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust policy must evaluate the actual acting entity across every hop. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance requires reliable attribution of privileged actions. |
Inspect delegation claims at each boundary and authorize the current actor, not just the original subject.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
