An authorisation model that evaluates each proposed action before execution, using the specific tool, resource, arguments and delegated identity involved. It is the practical answer to agentic risk because the dangerous event is not login, but the runtime choice the model makes next.
What Decision-level Authorisation Actually Means
Decision-level authorisation is a runtime control, not a one-time login event. It evaluates the specific action, target resource, arguments, and delegated identity immediately before execution so the system can approve or deny what the actor is trying to do now.
This matters because modern automation, especially AI-driven workflows, can be authenticated and still be unsafe. The security question is whether the next action is allowed, constrained, and traceable under the current context, not merely whether the actor once obtained a valid session.
Why It Is Different from Static Permission Models
Traditional role and attribute models decide access at a broader scope, such as a user, workload, or session. Decision-level authorisation narrows that lens to the exact request, which is important when the same identity can make safe and unsafe calls depending on tool, object, scope, or intent.
This is one reason it aligns with Authorisation Models Guide, which compares RBAC, ABAC, ReBAC and policy-based authorisation for people, workloads and AI agents. The practical shift is from coarse entitlement logic to a contextual decision about the current operation.
It also fits the broader identity and access lifecycle covered in IAM and IGA Basics, because decision-level control depends on inventorying entitlements, ownership, and policy boundaries well enough to make each request intelligible.
How the Runtime Decision Is Made
A strong decision-level model usually evaluates four things together: which tool or API is being called, which resource is being touched, what parameters or arguments are being passed, and who or what is acting on whose behalf. That combination is what makes the control precise enough to stop misuse without blocking legitimate work.
The best-known patterns for this are externalised authorisation, policy decision points, and per-request policy evaluation. The point is to move the trust decision close to execution so the system can compare intent, context, and policy at the moment of action rather than relying on an earlier login or coarse session grant.
For AI-driven systems, that runtime check is especially important because the next tool call may be much more sensitive than the previous one. AI Agent Authorisation Guide is directly relevant here because it focuses on per-action policy decisions, delegated authority, and human approval gates for agents.
When the action boundary is poorly defined, the control collapses into a blanket yes-or-no permission model. Decision-level authorisation is strongest when the policy can inspect the actual request and apply least privilege to that specific action.
What It Protects in Agentic and API-Driven Systems
This term is especially relevant wherever software can act on behalf of a person or another system, because the dangerous event is often the action itself, not the login. A valid session can still be abused to overreach, exfiltrate data, change records, trigger side effects, or chain into a higher-impact operation.
That is why decision-level controls are a strong fit for APIs and tool interfaces. The external reference point for this kind of failure is OWASP API Security Top 10, which highlights broken authorisation as a core API risk when requests are not evaluated at the object, property, or function level.
For agentic systems, the same pattern becomes a governance problem as well as a technical one. A delegated actor may be technically authenticated yet still be too powerful for the current task, which is why request-scoped checks are often paired with explicit approval flows, tool scoping, and narrow delegation.
Where It Commonly Fails
Decision-level authorisation fails when the policy engine cannot see enough of the request, when the request is authorised too broadly, or when the system trusts the delegated identity more than the specific action. In practice, that creates opportunities for over-permissioned tools, confused deputy behaviour, and escalation through seemingly legitimate calls.
It also fails when organisations treat the identity as the control instead of the request. A well-formed identity can still make a dangerous call if the authorisation layer does not inspect the target, operation, and arguments with enough precision.
Risk and Threat Considerations
Decision-level authorisation reduces the blast radius of compromised sessions, overbroad delegation, and agent misuse, but it also introduces a high-value policy boundary. If that boundary is too coarse, poorly instrumented, or bypassable, attackers can turn a legitimate runtime call into data theft, privilege abuse, or destructive side effects.
Failure mechanism: The system approves actions based on identity alone, or on a request that is not inspected deeply enough for the actual tool, object, or argument being used. That allows unsafe operations to look legitimate at execution time, which is especially dangerous in automated and agentic flows.
Impact: A compromised or over-empowered actor can misuse delegated access to access sensitive resources, trigger unintended transactions, or chain a single permitted action into broader compromise.
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 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Decision-level authorization evaluates each action before execution, which directly addresses function-level abuse. |
| Recommendation — Enforce per-action authorization checks for every sensitive API or tool invocation. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The term operationalizes least privilege by approving only the specific action requested at runtime. |
| IA-5 — Authenticator Management | Runtime authorization depends on strong credential and session handling for the delegated identity. | |
| IA-9 — Service Identification and Authentication | The concept is material to service, workload, and tool-to-tool authorization decisions. | |
| Recommendation — Constrain each runtime request to the minimum access needed for that action. Manage credentials and session material so runtime decisions are based on trustworthy identity context. Authenticate non-human actors before applying per-request authorization policy. | ||
| OWASP ASVS | V8 — Authorization | ASVS authorization requirements directly map to fine-grained request evaluation and enforcement. |
| Recommendation — Verify that authorization is enforced at the object, function, and request level. | ||
Practitioner Guidance
What to watch for: Use this term as a design cue whenever the same identity can make both safe and unsafe requests in the same session or workflow. The governance question is not whether the actor is known, but whether the next action is narrow enough to be safe.
Practitioner note: Decision-level authorisation works best when policy, context, and enforcement are close to the execution path, because delayed or generic checks tend to reintroduce coarse privilege.
Related resources from NHI Mgmt Group
- How do agent-native payments change the decision between API keys and runtime authorisation?
- What breaks when REST APIs rely on authentication without object-level authorisation?
- Why do API gateways struggle with broken object level authorisation?
- What breaks when object-level authorisation is missing in web applications?