May Act is a consent and authorisation state that means a user or system is permitted to perform an action, but is not required to do so. In identity and access control, it distinguishes optional capability from obligations such as must act, and may be enforced through policy rules, delegated authority or conditional access decisions.
What May Act Means in Access Control
May Act expresses permission without obligation. It matters because many access decisions are not binary allow or deny alone, they also define whether an approved actor can exercise a capability now, later, or only under specific policy conditions.
How May Act Differs from Must Act
In identity and access control, May Act is the softer of two common obligation states. A “may” decision says the user or system is authorised to proceed, but it does not impose a duty to do so, which makes it useful for discretionary workflows, optional approvals, and conditional delegation.
This distinction is important in policy language because optional authority can be misread as required authority. If teams treat “may” as “must,” they can create unnecessary operational coupling; if they treat it as merely descriptive, they may under-enforce policy intent.
Where May Act Appears in Governance and Policy Design
May Act typically appears in permission models, policy engines, delegated authority rules, and consent-driven workflows. It often sits alongside conditions such as time limits, context checks, or user consent, so the decision grants capability while still preserving discretion about whether to use it.
In practice, it is a useful term for distinguishing entitlement from mandate. That helps designers describe what a principal is allowed to do, what they are expected to do, and what remains optional under a given rule set.
Why the Term Matters in Operational Interpretation
May Act reduces ambiguity in security and business rules because it separates authorization from obligation. That separation is especially valuable in systems where a permitted action could still be inappropriate, unnecessary, or deferred based on context.
It also helps avoid over-automation. A system may be authorised to perform an action, but a human review, a second condition, or a contextual signal may still decide whether the action should actually occur.
NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for understanding how access control and authorization decisions are expressed in governed environments.
Risk and Threat Considerations
May Act is usually safe as a concept, but it can create exposure when policy authors, implementers, or operators confuse permission with mandate, or when optional authority is too broad and too easy to invoke. The risk is less about the wording itself and more about the control failure that follows from ambiguous policy semantics.
Failure mechanism: A principal with discretionary authority can exercise an approved action in ways that exceed intended business need, especially when conditional controls, human review, or revocation rules are weak.
Impact: Misinterpreted authorisation can lead to unnecessary privilege use, unintended actions, policy drift, and weaker accountability for who chose to act and why.
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 | AC-3 — Access Enforcement | May Act expresses whether access is permitted by policy, which is central to enforcement decisions. |
| AC-6 — Least Privilege | Optional authority should be bounded so permitted actions do not become excessive standing power. | |
| IA-2 — Identification and Authentication (Organizational Users) | May Act depends on a principal being recognised before policy can grant permission to act. | |
| Recommendation — Define enforcement rules so permitted actions are distinguished from mandatory workflow requirements. Limit discretionary permissions to the minimum needed for the approved purpose. Require strong authentication before issuing permissions that allow optional actions. | ||
Practitioner Guidance
Common misunderstanding: Treating “may act” as if it were a recommendation or an obligation is a frequent source of control confusion. Policy writers should use it only when permission is truly optional, and should pair it with clear conditions when the action should happen only in certain contexts.
Governance implication: Teams should reserve the term for rules where discretion is intentional, and make sure downstream workflows, approvals, and audit records preserve that distinction. When a system can act but is not required to, the ownership question becomes who decides, under what conditions, and how that decision is reviewed.
Related resources from NHI Mgmt Group
- How should security teams prove DORA compliance for AI agents that act autonomously?
- How should organisations prove EU AI Act compliance across the AI lifecycle?
- How should security teams govern AI assistants that can act inside IAM systems?
- How should security teams govern MCP-enabled AI assistants that can act on tools and data?
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 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org