A nested act claim records each intermediate actor in a delegated identity chain, showing who acted on behalf of whom. It turns delegation history into signed token data that downstream services can inspect when deciding whether a request is allowed.
Expanded Definition
A nested act claim is the evidence layer that makes delegated action inspectable in an NHI or agentic system. Rather than asserting only the immediate caller, it records the chain of actors and intermediate delegation steps so a service can verify who acted, under what authority, and whether that authority still applies.
This matters because modern workflows often chain service accounts, agents, workloads, and on-behalf-of tokens. A nested act claim helps distinguish direct authentication from delegated execution, which is especially important when a request passes through brokers, orchestration layers, or AI agents. Definitions vary across vendors, but the security intent is consistent: preserve delegation provenance in a machine-readable form that downstream policy engines can evaluate alongside context from the NIST Cybersecurity Framework 2.0 and identity controls.
NHIMG treats this as a governance signal, not just a token field. If the chain cannot be inspected, the system cannot reliably determine whether an agent is acting within approved bounds or simply relaying credentials and permissions through multiple hops. The most common misapplication is collapsing the entire delegation path into a single subject claim, which occurs when teams trust the final token issuer but do not preserve each intermediate actor.
Examples and Use Cases
Implementing nested act claims rigorously often introduces token complexity and stricter validation logic, requiring organisations to weigh auditability against parsing and interoperability overhead.
- An AI agent submits a ticket through a workflow broker, and the service checks every hop in the claim chain before honoring the action.
- A platform workload calls a payment API on behalf of a user session, and the API verifies whether the delegation path still matches policy intent.
- A support automation tool accesses records through a service account, while the claim chain preserves the original operator, the bot, and the approval boundary.
- A federation layer passes a request through multiple internal services, and each service inspects the nested claims before forwarding privileged operations.
- A breached credential is replayed through an orchestration layer, but the request is rejected because the delegation history does not match the expected actor sequence, a pattern increasingly relevant in cases like the DeepSeek breach and other secrets-driven incidents.
These patterns align with delegated identity guidance in the NIST Cybersecurity Framework 2.0, where traceable access decisions depend on dependable identity evidence. For NHI teams, the practical goal is to make downstream authorization see the whole chain, not just the last hop.
Why It Matters in NHI Security
Nested act claims reduce ambiguity in environments where service accounts, agents, and automation can impersonate legitimate business actions. Without them, investigators may know that an action succeeded, but not which intermediary obtained or relayed the authority. That gap makes it harder to separate legitimate delegation from credential abuse, overbroad trust, or agentic misuse.
This becomes operationally important when secrets are exposed or reused, because attackers often exploit whatever delegation path is easiest to abuse. NHIMG research shows the average time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities. That disconnect means the provenance of an action may be the only reliable clue left after a token, key, or service account is compromised. Nested act claims also support investigation workflows that connect identity evidence to policies described in NIST Cybersecurity Framework 2.0 and help teams reason about how delegated execution should behave under the State of Secrets in AppSec findings.
Organisations typically encounter nested act claim requirements only after a delegated request is abused or disputed, at which point the missing provenance 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 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-06 | Delegation provenance and claim integrity are core to NHI authorization hardening. |
| NIST SP 800-63 | Federation and assertion handling inform how delegated identity evidence should be trusted. | |
| NIST Zero Trust (SP 800-207) | 3.2 | Zero trust requires continuous verification of identity and context across every request path. |
Inspect delegation claims at each hop and deny requests when actor lineage is incomplete or inconsistent.
