Identity & access

Authorization

May this actor perform this action?

Reference notes by Min · Reviewed October 11, 2026

Source-based definitionAlso: AuthZ1 primary reference

Definition

Authorization determines whether an identified actor may perform a particular action on a resource under applicable rules.

An authorization decision is specific to an actor, operation, resource and relevant context. Access to a tool does not necessarily authorize every parameter combination that tool accepts. A valid request can still need a narrower resource or task scope.

What it covers

Action
Read, write, export, send or execute.
Resource
The record, service or system affected.
Context
Task, requester, approval and current restrictions.

Define permissions at the meaningful operation boundary: reading one case, drafting a reply and committing a refund are different actions. Consider target ownership, tenant boundaries, task expiry and required approval when designing that decision.

In practice

Practical design patterns by Min.

  • Evaluate permission at the tool boundary.
  • Scope decisions to the actual resource and operation.
  • Recheck after scope or authority changes.

Translate business authority into explicit service rules. Keep those rules outside model-generated text and apply them to the exact submitted parameters.

Evaluate negative cases such as another customer’s record, an expired task or a write operation requested through a read-only workflow. Retain the reason for denial without leaking protected data.

Working example

Reading is allowed; exporting is not

An agent can view an assigned support case.

  1. Authenticate the actor.
  2. Check the requested operation against case permissions.
  3. Deny a bulk export even if viewing one case is allowed.
Illustrative scenario, not a reported deployment.

Why the controls matter

The same authenticated support agent may read its assigned case while being denied another customer’s file. Both outcomes are consistent with one workload identity and different resource scopes.

Common pitfalls

  • Using authentication as the entire access decision.
  • Checking permission only when the task starts.

A successful check at the beginning of a long task may become stale. Identify actions that require a fresh decision when they are actually committed.

Questions for operational review

Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.

  • What exact action is authorized?
  • For which resource and requester?
  • When must the decision be reevaluated?

References

Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.

  1. NIST CSRC: Authorization ↗Accessed October 11, 2026