Act And May_Act Claims

Expanded Definition

Act and may_act claims describe delegation in a way that is meaningful to downstream services, not just the original token issuer. The act claim identifies the current actor, while may_act identifies the party or parties permitted to become the actor later in a delegated chain. That distinction matters in NHI and agentic systems because a token can move across services, but authority should not silently expand as it moves.

In practice, these claims help preserve provenance across hops, especially when an agent calls another service on behalf of a user or when one NHI delegates work to another NHI under constrained authority. They are most useful when paired with strict audience validation, token lifetime limits, and server-side policy checks, since the claims themselves are signals rather than enforcement. Definitions vary across vendors and implementations, so no single standard governs this yet, but the operational intent is consistent: make delegation explicit and auditable. The most common misapplication is treating a forwarded token as unrestricted bearer access, which occurs when downstream services ignore the actor chain and rely only on token presence.

For broader identity control context, see NIST SP 800-53 Rev 5 Security and Privacy Controls.

Examples and Use Cases

Implementing act and may_act claims rigorously often introduces policy complexity, requiring organisations to weigh stronger delegation traceability against additional validation logic at each hop.

• An API gateway receives a token from an upstream agent and checks act to confirm which NHI is currently executing the request.
• A workflow engine uses may_act to allow only a designated downstream agent to continue a task after an approval step.
• A service mesh preserves actor provenance so an audit log can show the original requester, the intermediate NHI, and the final tool-calling agent.
• A delegated maintenance token lets a break-glass operator act for a service account for a short window without converting the token into open-ended bearer access.
• In a federated environment, a platform enforces that the downstream service only accepts tokens whose may_act claim matches the expected service identity.

For a real-world example of what goes wrong when delegated credentials are handled loosely, review the DeepSeek breach. In adjacent identity guidance, NIST SP 800-53 Rev 5 Security and Privacy Controls provides control language that supports provenance, least privilege, and authorization checks.

Why It Matters in NHI Security

Act and may_act claims are important because delegated NHI activity often looks legitimate right up until an incident review asks who actually initiated the action. Without explicit actor chaining, teams lose provenance across service hops, and incident responders cannot tell whether a tool invocation came from the intended agent, a substituted NHI, or a replayed token. That creates gaps in auditability, makes privilege creep harder to spot, and weakens trust in agent-to-agent workflows.

NHI Management Group research shows how fast exposed identity material can be abused: when AWS credentials are publicly exposed, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, as reported in LLMjacking: How Attackers Hijack AI Using Compromised NHIs. That kind of speed is why delegated authority must be explicit, short-lived, and verifiable rather than implied by token possession alone. Organisaties typically encounter the limits of these claims only after a compromised token is replayed through multiple services, at which point actor provenance becomes operationally unavoidable to address.

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?
• False Claims Act Exposure
• How should security teams prove DORA compliance for AI agents that act autonomously?