Skip to main content

​
Production Step-Up and Approval

​
Audience

This page is for operators who trigger production mutations, CLI/Agent users, and implementers defining production guardrails.

​
Goal and Scope

This page explains:
  1. which production operations require approval by default
  2. where step-up and approval sit in the execution chain
  3. why Web, CLI, and Agent must share the same guardrail semantics

​
Core Concepts

​
Step-up

Step-up means increasing identity assurance before a high-risk operation, for example through:
  • re-validating the session
  • a second-factor check
  • stronger token constraints

​
Approval

Approval is the explicit authorization record for a high-risk production mutation. It answers:
  • who requested which action
  • in which environment and on which resource
  • who approved it
  • whether it has already been consumed

​
Default approval-required cases

  • production deployment create / update / rollback
  • production database write actions
  • production object deletion in object storage
  • production installation or other high-risk operational actions

​
Standard Workflow

AuthN -> AuthZ(require_approval) -> Approval -> ValidateBinding -> Execute -> Audit Binding validation includes at least:
  • subject_id
  • env
  • resource_hash
  • action
CLI / Agent flows should additionally bind:
  • command_hash

​
CLI Examples

aios approval request \
  --action deploy.app.update \
  --resource app:project/prod/my-api

aios app up --env prod

​
Web UI Path

  • initiate a production mutation from the application detail page
  • enter the step-up / approval flow
  • review ticket state and consumption in the approval center

​
Pitfalls / Risk Notes

  • approval is not a replacement for AuthZ; it is one AuthZ branch outcome
  • approval tickets must become invalid after successful consumption to prevent replay
  • any channel that can mutate production without this chain is a major design flaw