Access authorisation is the decision that determines what a user, service account, or AI agent may do after identity has been verified. In IAM, it maps authenticated identities to approved resources and actions through policies, roles, attributes, and context, helping enforce least privilege, separation of duties, and controlled access.
How Access Authorisation Works
Access authorisation is the enforcement layer that turns a verified identity into a bounded set of allowed actions. It answers the practical question, “what can this subject do now?” and is typically expressed through policies, roles, attributes, resource scopes, and contextual rules.
Because authorisation sits after authentication, it is not about proving who someone is, but about constraining what they may reach, change, approve, or delegate. Good authorisation design keeps the decision specific to the resource and action, rather than granting broad standing access by default.
Core Models and Decision Inputs
Most modern authorisation schemes rely on a small set of decision inputs: the subject, the resource, the action, and the context. RBAC uses roles as an abstraction, ABAC evaluates attributes, and ReBAC uses relationships; many real systems combine these patterns rather than using only one.
Policy engines and policy-as-code approaches move the decision out of the application flow so that access logic can be reviewed, tested, and reused. For guidance on how these models compare in practice, see Authorisation Models Guide.
Why Access Authorisation Matters in IAM
Authorisation is where least privilege becomes operational. If the rule set is too coarse, users, services, and AI agents accumulate permissions they do not need; if it is too strict or poorly designed, legitimate workflows break and teams create unsafe workarounds.
It also underpins separation of duties, because the system must be able to deny conflicting combinations of permissions even when the same identity is authenticated successfully. In enterprise IAM, this is the control layer that prevents authenticated access from becoming unrestricted access.
For a broader view of how authorisation sits inside access governance, provisioning, and entitlement management, see IAM and IGA Basics.
Common Failure Modes
The most damaging failures usually come from over-permissioned roles, weak entitlement review, mis-scoped policies, and inconsistent enforcement across applications or APIs. Authorisation drift is especially dangerous because access that was once justified can quietly remain in place long after the original need has disappeared.
Context also matters. A rule that is acceptable for a human user may be unsafe for a service account or AI agent if it allows broad, persistent, or reusable access. When those subjects are involved, the authorisation design must account for task scope, delegation, and revocation speed.
For an agent-specific view of scoped permissions and delegated decision-making, see AI Agent Authorisation Guide.
Risk and Threat Considerations
Access authorisation failures create direct exposure because a single bad policy can turn a valid login or token into excessive reach across data, systems, or administrative functions. Attackers often look for broken authorisation because it is one of the fastest paths from limited access to high-impact compromise.
Failure mechanism: The control fails when policies are too broad, inconsistent, or bypassable, allowing authenticated subjects to access resources, functions, or records beyond their intended scope.
Impact: The result can be data exposure, privilege escalation, lateral movement, destructive actions, or unauthorized automation at scale, especially where service accounts and AI agents are granted persistent permissions.
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, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Defines enforcing who may do what on protected resources. |
| AC-6 — Least Privilege | Directly governs minimising permissions granted after authentication. | |
| IA-9 — Service Identification and Authentication | Covers non-human subjects that must be authenticated before authorisation decisions apply. | |
| Recommendation — Enforce AC-3 to restrict each subject to approved actions on approved resources. Apply AC-6 to limit permissions to the minimum needed for each role or task. Use IA-9 to establish trustworthy service-to-service identities before authorising access. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Addresses account and privilege management that underpins authorisation decisions. |
| Recommendation — Implement CIS-6 to manage permissions, review access, and remove unnecessary entitlements. | ||
| OWASP ASVS | V8 — Authorization | Defines application-level authorisation requirements and enforcement checks. |
| Recommendation — Use V8 to verify that every sensitive action is subject to explicit authorization checks. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Captures object-level access failures that expose data across identities. |
| API5 — Broken Function Level Authorization | Covers unauthorized access to sensitive functions and admin capabilities. | |
| Recommendation — Test APIs for BOLA so callers cannot access objects outside their allowed scope. Validate function-level authorization so only intended roles can invoke privileged actions. | ||
Practitioner Guidance
Why practitioners should care: Authorisation should be treated as a living control, not a one-time configuration. The real governance challenge is keeping policy intent aligned with actual business need as applications, roles, integrations, and automation change over time.
What to watch for: Pay close attention to permission creep, overlapping roles, hidden admin paths, and rules that differ across products or environments. If the same action is allowed in one place and blocked in another, the policy model is already drifting.
Practitioner takeaway: The best authorisation design is narrow, explicit, and reviewable, with decisions that are easy to explain and hard to accidentally overextend.
Related resources from NHI Mgmt Group
- Why do organisations struggle to govern dynamic authorisation without a central access view?
- Why do cloud access control models often fail when organisations use them for both authentication and authorisation decisions?
- Why do AI agents need action-level authorisation instead of resource-level access?
- Why do infrastructure access controls so often delay FedRAMP authorisation and increase delivery risk?