Act And May_Act Claims

What the claims do in a delegated token

Act and may_act claims are the bookkeeping layer that makes delegation explicit inside a token. The act claim identifies the current actor, while may_act records who is permitted to act later, so a forwarded token preserves provenance instead of silently becoming unrestricted bearer access. That distinction matters whenever a token crosses hops, intermediaries or service boundaries.

Used well, these claims let systems distinguish “the subject who owns the grant” from “the party currently exercising it”. In practice, that helps reduce confusion between delegation and impersonation, and it gives downstream services a way to reason about who is actually making the request.

How act and may_act preserve provenance across hops

Delegated flows often accumulate context as a request moves through brokers, gateways or agents. The act claim captures the current delegating chain at the point of use, while may_act describes the next eligible actor in that chain. That makes the token history-readable: each hop can show who acted, who was authorised to act next, and where the delegation came from.

This is especially important in cross-domain or multi-hop token exchange, where the receiving service needs a clear statement of provenance rather than an assumption that the token itself should be trusted forever. The claims support narrower, traceable delegation rather than open-ended reuse.

OAuth Token Exchange and Delegation Guide explains the token-exchange model behind act and may_act claims, including on-behalf-of flows and downscoping.

Delegation Chains and Attenuated Authority for AI Agents shows how actor claims support chained delegation and why attenuation matters when authority passes through multiple hops.

Where confusion and misuse appear

These claims are easy to misread as a generic identity field, but they are really about delegation state. If implementers treat a token with act information as though it were equivalent to direct user authentication, they can blur the boundary between original ownership, delegated authority and current execution context. That leads to audit gaps and authorization mistakes.

Another common failure is accepting forwarded tokens without checking whether the current actor matches the intended chain. In that case, the claims exist but do not actually constrain use, which defeats the purpose of carrying the delegation metadata at all.

Why the claims matter for authorization design

Act and may_act claims are most useful when downstream services need to enforce “who may act for whom” rather than simply “is this token valid”. They let an authorization decision depend on delegated authority, not just token possession. That is what makes them useful for trust boundaries where one component is allowed to speak for another but not to exceed the delegated scope.

They also support cleaner attribution. If a system records only the forwarding service, or only the original grant holder, it loses the chain of responsibility. Claims that preserve both the current actor and the permitted next actor help keep the authorization story intact across handoffs.

Agent Identity and Access Guide places these claims in the broader context of agent identity, delegation and credential choices.

Confused Deputy in AI Agents Guide is useful for understanding why delegation metadata must be paired with proper consent and audience checks.

How practitioners should read them in real systems

In implementation terms, act and may_act are not decorative JWT fields. They are evidence that the system is trying to preserve the delegation chain and keep authority bounded as tokens move between services. Readers should treat them as part of a broader trust design that includes audience scoping, token exchange rules and clear service-to-service authorization boundaries.

Agent-to-Agent Authentication Guide is a useful companion when the current actor is itself an autonomous or service-based caller, because the claims only help if the receiving side can also verify the caller’s identity and intent.

OWASP Agentic Top 10 ASI03 Guide helps connect delegated authority to identity and privilege abuse risks when agents can act on behalf of others.

Risk and Threat Considerations

These claims reduce ambiguity, but they also create a security dependency: if they are ignored, forged or allowed to drift from the real delegation path, a token can be used beyond the authority it was meant to carry. That can turn a bounded delegation into a confused-deputy path or an audit trail that no longer matches who actually exercised the permission.

Failure mechanism: A receiver accepts the token as proof of general access instead of checking the delegation chain, so the current actor, the permitted next actor and the intended audience no longer stay aligned.

Impact: Attackers or misconfigured intermediaries can widen privilege, hide provenance, or reuse forwarded tokens in places where the original grant was never intended to apply.

Practitioner Guidance

Why practitioners should care: If your system uses token exchange, service chaining or delegated automation, act and may_act are only valuable when every hop understands and enforces them consistently. They should be treated as part of the authorization model, not as optional metadata.

Common misunderstanding: A token that contains delegation claims is not automatically safe to forward. The receiver still has to validate that the claims match the intended delegation relationship, scope and audience for that specific transaction.

Practitioner takeaway: Use these claims to preserve a verifiable delegation chain, then pair them with audience checks and per-hop authorization so provenance remains enforceable, not merely recorded.

Related resources from NHI Mgmt Group

• Why do subcontractor security assurances create False Claims Act risk?
• When does a cybersecurity gap become False Claims Act risk?
• Why can a stale SPRS score create False Claims Act risk?
• False Claims Act Exposure