> ## Documentation Index
> Fetch the complete documentation index at: https://docs.skrmir.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Production Step-Up and Approval

> Defines the shared step-up and approval guardrails for production mutations across Web, CLI, and Agent flows.

# 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`

## Planned CLI Examples (Not Yet Implemented)

The repository does not currently ship these prod approval/deploy subcommands. They remain examples of how a future CLI must reuse the same approval binding and execution chain.

```bash theme={null}
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

## Related Pages

* [Environment Model: Dev/Test/Preview/Prod](/en/platform/projects/environments-dev-test-preview-prod)
* [Authentication and Authorization Model](/en/operations/authn-authz)
* [Agent Overview](/en/agent/index)