Action-level authorization

Action-level authorization binds permission to an operation and its intended effect, rather than granting every operation on an API or tool.

01 / The operating case

What changes in a real workflow?

A maintenance agent may describe a server but not restart it; both methods are exposed by the same cloud tool.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision boundary

Put the check where it can stop the effect.

Classify read, propose, modify and destructive operations separately. Bind the restart decision to the instance identifier and maintenance window at the executor.

Architecture review / negative test

Make the boundary testable.

Build an effect inventory from actual endpoints, not friendly tool labels. A single cloud plugin may include describe, stop, restart and terminate; classify each by reversibility and operational impact. Review whether a generic execute command can invoke the same effect without passing through the named restart check.

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A tool-level allowlist treats a harmless read and a production restart as equivalent.

Evidence to retain

Keep the requested verb and target in the decision receipt and compare them with the executed command.

04 / Canonical scope

Why this reference stands alone

Parameter-level authorization narrows arguments inside an allowed verb; this page owns the operation distinction.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation