A May Act Claim is a claim in an identity token that says the bearer may perform a stated action, rather than that it is definitely authorised to do so. It is used in access decisions as an advisory signal, so systems still need their own policy checks before granting access.
What a May Act Claim Means in a Token
A May act claim is an advisory token claim that signals a bearer may perform an action, but it does not itself establish authorisation. Systems that consume it still need an independent policy decision before granting access or delegated execution.
This matters because the claim is about permission intent, not final approval. In token exchange and delegation flows, that distinction helps systems describe who may act on whose behalf without collapsing advisory context into an actual access grant.
How May Act Claims Shape Delegation
May Act Claims are most useful where a token needs to carry delegation context across a chain of actors. They let the receiving service see that an action is allowed to be requested or considered, while keeping the final decision anchored in policy, audience, scope, and local enforcement.
That makes the claim especially relevant in on-behalf-of flows, token exchange, and other designs where a subject token and an actor token may both matter. The claim helps preserve delegation semantics without implying that the token bearer has unconditional authority.
For a deeper treatment of those delegation patterns, see RFC 8693: OAuth 2.0 Token Exchange.
Why May Act Claims Are Not the Same as Authorization
The key design point is separation of duties between token content and policy enforcement. A May Act Claim can inform a decision, but it should not be treated as a substitute for access control logic, consent, or scope validation.
That separation reduces the chance of a confused-deputy style failure, where a service mistakes delegated context for standing authority. It also avoids over-trusting whatever a token says about what the bearer may do, especially when the token crosses trust boundaries.
In practice, the safest reading is: the claim can narrow uncertainty, but it cannot widen privilege on its own.
Where May Act Claims Fit in Modern Identity Flows
May Act Claims appear in patterns that need explicit delegation semantics, such as service-to-service mediation, cross-domain exchange, and agent-assisted workflows. They are most useful when a system must preserve who initiated an action, who is acting, and whether the downstream action is still subject to local checks.
That is why these claims are often discussed alongside actor tokens, subject tokens, and attenuated authority. They are part of a broader design approach that keeps delegated power narrow, auditable, and revocable instead of treating every forwarded token as equivalent to original user authorisation.
For a practical guide to those delegation patterns, the OAuth Token Exchange and Delegation Guide explains how act claims, token exchange, and downscoping work together. Relatedly, Agent Identity and Access Guide shows how delegation, credential choice, and authorisation controls fit into an agent access model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Token exchange and delegated actor context depend on service-to-service authentication and trust. |
| AC-3 — Access Enforcement | A May Act Claim informs access decisions but does not itself grant access. | |
| AC-6 — Least Privilege | Delegation claims are meant to narrow authority rather than expand it. | |
| Recommendation — Apply IA-9 to authenticate the delegating service before accepting delegated token context. Enforce AC-3 so policy remains the final gate before any action is authorised. Use AC-6 to constrain delegated tokens to the minimum authority needed for the task. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Treating an advisory claim as authority can bypass function-level checks. |
| API2 — Broken Authentication | Delegation flows rely on correct token interpretation and sender authentication. | |
| Recommendation — Validate function-level authorization separately from any token claim. Verify token provenance and authentication before trusting delegated claims. | ||
Practitioner Guidance
Why practitioners should care: Treat May Act Claims as advisory metadata, not as a green light. If your policy engine does not independently validate the action, the audience, and the current context, the claim should not change the access decision.
Common misunderstanding: Teams sometimes read a May Act Claim as if it were proof of entitlement. In reality, it is only useful when paired with local enforcement that can still deny the request even when the token says the action may be attempted.
Practitioner takeaway: Use the claim to preserve delegation context, but keep final authority in policy, not in token text.
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 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org