Whenever the action is destructive, irreversible, or outside the original task boundary. Authentication proves the token is accepted, but it does not prove the request belongs in that moment. High-impact operations need a separate runtime check that considers context, not just possession of the secret.
When a valid token is not enough for authorisation
A token can confirm that a caller was accepted by the system, but that is not the same as proving the requested action is safe in context. Treat the token as insufficient whenever the operation would permanently change data, move money, alter access, or act outside the original intent. At that point, the decision needs a fresh runtime check.
Why possession of a token does not settle the decision
Authentication answers only one question: did the caller present something the system recognises? It does not answer whether the request still fits the current task, whether the target object belongs to the caller, or whether the action exceeds the intended scope. That is why a valid token can still be the wrong basis for a destructive, cross-tenant, or privilege-changing request.
In practice, the gap appears when systems rely on coarse permissions or stale assumptions. A token may still be valid even after the user moved roles, the workflow changed, the resource owner changed, or the session was replayed in a different context. For that reason, authorisation models need to be paired with request-time policy checks when the decision depends on object, relationship, purpose, or environment.
Which requests deserve an extra check
The safest rule is to require more than token validity when the request is destructive, irreversible, or materially high impact. That includes deleting records, revoking access, exporting sensitive data, changing entitlements, and approving actions that commit the organisation to an external side effect. It also includes actions that are technically allowed but no longer appropriate because the context has drifted since the token was issued.
Context matters most when the same identity can perform both low-risk and high-risk actions. A token that is sufficient to read a profile is not automatically sufficient to transfer funds, reset another user’s credentials, or approve an administrative change. In those cases, the correct control is not simply a stronger token, but a separate authorisation decision tied to the specific operation.
That distinction is especially important when systems support delegation, service-to-service calls, or automation. A request may carry a valid credential and still need step-up checks, policy evaluation, or bounded delegation before it is trusted to proceed. AI agent authorisation follows the same principle: the credential proves the caller is real, while the runtime decision determines whether this action should happen now.
Risk and Threat Considerations
The risk is not token failure, it is over-trusting a token as if it were a blanket approval. If a token is replayed, over-scoped, or used after the business context has changed, an attacker or careless operator can still trigger a harmful action that looks authenticated but is not truly authorised.
Failure mechanism: The system accepts possession of a valid secret, then skips a fresh policy decision on the specific object, action, or context. That lets stale, stolen, or over-broad access perform operations the original session intent never justified.
Impact: High-value records can be deleted, access can be widened, funds can move, and sensitive data can leave the boundary without a second control stopping it. In incident terms, the token becomes a vehicle for abuse rather than proof of legitimate intent.
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, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Directly covers valid-token requests that still exceed allowed action scope. |
| API1 — Broken Object Level Authorization | Applies when a valid token is used against objects the caller should not control. | |
| Recommendation — Enforce function-level checks before allowing destructive or privileged API actions. Verify object ownership or relationship on every sensitive request. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Requires enforcing decisions on what an authenticated subject may do. |
| AC-6 — Least Privilege | Limits tokens and sessions so possession alone cannot authorise high-impact actions. | |
| IA-5 — Authenticator Management | Supports token handling and lifecycle controls when token validity is not enough. | |
| Recommendation — Apply access enforcement to each protected action, not just session acceptance. Scope privileges narrowly and separate low-risk from high-risk operations. Rotate, expire, and revoke authenticators to reduce token abuse windows. | ||
| NIST Zero Trust (SP 800-207) | Continuous Verification | Zero trust requires verifying each request context, not trusting the token alone. |
| Recommendation — Re-evaluate access context for each sensitive transaction. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Covers enforcing who can do what beyond basic authentication. |
| Recommendation — Gate destructive actions with explicit access controls and review. | ||
Practitioner Guidance
What to verify: Separate “token accepted” from “action approved” in your design review. If the request can change state, expose data, or affect another principal, verify that the authorisation decision is evaluated at request time against the target, action, and current context.
Decision rule: If the action is reversible and low impact, a normal permission check may be enough. If the action is destructive, irreversible, or outside the original task boundary, require a stronger runtime decision, such as step-up approval, relationship-based policy, or a fresh object-level check.
What good looks like: The system can explain why the token was accepted, why the action was allowed, and what context was used to make that call. When those answers are missing, the design is usually relying on authentication as a substitute for authorisation.
Practitioner takeaway: Treat the token as proof of caller identity, not proof of business intent; the more consequential the action, the more the authorisation decision must be evaluated at the moment the action is taken.
Related resources from NHI Mgmt Group
- Why is OAuth token management critical in cloud environments?
- When should organisations treat SaaS token use as an incident?
- When should organisations treat a token as a privileged identity rather than a routine credential?
- Should organisations treat ransomware, supplier compromise, and token abuse as one governance issue?