A token claim used to identify the actor performing an action on behalf of a principal. In delegated AI and service flows, it separates the human principal from the runtime actor so downstream systems can enforce policy and generate accurate audit records.
Expanded Definition
An act claim is the part of an identity token that names the runtime actor carrying out an action, while the principal claim identifies who authorised it. In delegated NHI flows, that separation is essential for policy checks, audit fidelity, and downstream attribution across agents, services, and brokers.
Definitions vary across vendors, but the operational idea is stable: a system may accept a request from one identity while recording that another identity actually performed the work. That distinction matters in OAuth-based delegation, service-to-service calls, and agentic execution paths where an AI agent, workload, or intermediary acts on behalf of a human or another NHI. The act claim should therefore be treated as an enforcement signal, not just a logging field, and it should be evaluated alongside token scope, audience, and trust context. For broader identity governance, this fits the same control logic described in the NIST Cybersecurity Framework 2.0 when organisations map identity assertions to access decisions.
The most common misapplication is treating the act claim as interchangeable with the principal claim, which occurs when engineers log only the caller identity and ignore delegated execution chains.
Examples and Use Cases
Implementing act claims rigorously often introduces token complexity and verification overhead, requiring organisations to weigh stronger attribution against more demanding integration and debugging work.
- An AI coding agent opens a ticket, edits a repository, and triggers a deployment while acting for a named engineer. The act claim records the agent runtime identity, while the principal remains the approving human.
- A support automation service refreshes customer access on behalf of a privileged operator. If the token omits the act claim, audit logs may falsely attribute the change to the operator alone.
- A federated workflow broker receives a delegated request and passes it downstream to multiple services. The act claim preserves the intermediate actor so each service can apply local policy and trace trust boundaries.
- A compromised workload credential is used to call an internal API. With proper actor attribution, incident responders can distinguish the stolen credential from the account that authorised the workflow, a lesson echoed in the DeepSeek breach and in NHI research on rapid credential abuse.
For implementation guidance, organisations usually pair actor attribution with the assurance and identity controls described in NIST Cybersecurity Framework 2.0, especially where delegation spans multiple systems.
Why It Matters in NHI Security
Act claims reduce ambiguity in delegated authority. Without them, investigators cannot reliably answer whether a request came from a principal, an automated agent, or a compromised intermediary. That creates weak audit trails, brittle approvals, and poor containment when secrets, tokens, or certificates are reused across workflows. In practice, the control becomes especially important where service identities are abundant and human oversight is indirect.
NHIMG research shows why this matters: when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, as reported in DeepSeek breach related threat reporting from the same research stream. That speed means attribution has to survive real-world compromise, not just compliant design reviews. The act claim helps security teams separate authorised delegation from stolen execution authority, which is increasingly important as agentic systems gain broader tool access and more workflows depend on non-human execution paths. Strong identity governance also aligns with the access discipline in the NIST Cybersecurity Framework 2.0.
Organisations typically encounter the need for act-claim rigor only after an agent, service account, or brokered workflow is abused, at which point attribution gaps become 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 SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Act claims help distinguish delegated execution from principal identity. |
| NIST SP 800-63 | Digital identity guidelines inform token binding and assertion use in delegated flows. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires evaluating each request's asserted actor and context. |
Bind delegated assertions to the correct actor and validate them before granting access.
Related resources from NHI Mgmt Group
- How should security teams prove DORA compliance for AI agents that act autonomously?
- How should organisations prove EU AI Act compliance across the AI lifecycle?
- How should security teams govern AI assistants that can act inside IAM systems?
- How should security teams govern MCP-enabled AI assistants that can act on tools and data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
