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.
What Nested Act Claims Do
Nested act claims make delegation visible at each hop, rather than only showing the final caller. That matters because a downstream service can distinguish direct action from action taken through one or more intermediaries, which is essential when trust depends on the full authority chain and not just the outermost token.
They are especially useful when requests cross service boundaries or agent boundaries, because the service receiving the request can inspect who acted on behalf of whom before deciding whether the chain is acceptable.
A nested act claim also helps preserve attribution. If a request is later reviewed, the chain can show whether the original actor, an intermediary, or a subordinate step introduced the authority that reached the service.
How Nested Act Claims Fit Delegated Identity Chains
Nested act claims are part of delegation-aware token design. The token is no longer just a bearer statement about the current caller; it becomes a structured record of delegated authority, with each intermediate actor preserved as signed data that can survive handoffs across systems.
That structure supports on-behalf-of flows, token exchange, and chained delegation where authority may narrow as it moves forward. In practice, the claim format is what lets a service reason about the lineage of authority instead of treating the request as if it came from a single flat identity.
Used well, the claim clarifies delegation depth, reduces ambiguity between impersonation and legitimate delegation, and gives policy engines a basis for checking whether the chain matches the intended trust model.
Why Downstream Services Inspect the Chain
Downstream services inspect nested act claims to decide whether to accept, constrain, or reject a request. The service may care about the immediate caller, the original principal, the presence of a trusted intermediary, or whether the delegation path has been narrowed enough for the requested action.
This is where the claim becomes more than audit metadata. It can influence authorization decisions, because a service that understands the chain can apply different checks when a request arrives through delegation than when it arrives directly.
The practical value is strongest in multi-hop environments, where a token might be reused across tools, services, or agents. Without chain visibility, the receiving service has to trust the outer token alone, which hides important context about how the request gained authority.
Common Failure Modes and Design Trade-Offs
Nested act claims only help when every hop preserves them faithfully and every consumer knows how to interpret them. If an intermediary strips the chain, flattens it, or inserts ambiguous data, the service can lose the very attribution needed to make a safe decision.
The other trade-off is complexity. The more delegation steps a system allows, the more important it becomes to bound who may act, for how long, and for what scope. A long delegation chain can be legitimate, but it also increases the chance of confused deputy behavior, privilege creep, or unclear accountability.
That is why the claim should be treated as security-sensitive control data, not as decorative token metadata. Its value depends on consistent signing, strict validation, and a policy model that can actually use the chain it receives.
Risk and Threat Considerations
Nested act claims reduce delegation ambiguity, but they also expose a failure point if the chain is missing, forged, or ignored. When services trust a token without validating the intermediate actors, an attacker or misconfigured intermediary can hide who really introduced the authority used in the request.
Failure mechanism: A service accepts a delegated request without checking the full act chain, or it processes a chain that has been truncated, rewritten, or not bound tightly enough to the original delegation context.
Impact: The result can be unauthorized action, misleading attribution, privilege amplification through delegation, or a confused deputy path where a trusted service exercises authority more broadly than intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Nested act claims depend on trustworthy identity assertions for the actors in the chain. |
| AC-6 — Least Privilege | Delegation chains should narrow authority as it passes through intermediate actors. | |
| AU-2 — Event Logging | Nested act claims improve auditability of who acted on behalf of whom. | |
| Recommendation — Authenticate each participating actor so delegated requests can be attributed to the correct principal. Constrain each intermediary to the minimum authority needed for the delegated task. Log delegation-chain context so investigators can reconstruct the authority path behind each request. | ||
Practitioner Guidance
What to watch for: Use nested act claims only where downstream services will actually inspect and enforce them. If the ecosystem treats the token as a generic bearer credential, the delegation history will not protect you, no matter how carefully it is encoded.
Governance implication: Define which hops may appear in the chain, what each hop is allowed to do, and when the chain must cause denial rather than acceptance. The control objective is not just traceability, it is enforceable delegation boundaries.
Practitioner takeaway: A nested act claim is most valuable when it is both preserved end-to-end and meaningfully enforced at the point of decision.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org