Operate · Approvals

The approval workflow.

Nothing modifies your infrastructure without explicit approval. Risk classification determines who must approve. Approvals are immutable, audit-logged, and can be revoked before apply.

The default

Every execution plan item is gated. Auto-apply is opt-in per action class and never enabled by default for production environments.

01

Why approvals exist

Autonomous agents that bypass human review are unsafe at enterprise scale. Three reasons approvals are mandatory:

  • Accountability — every change is attributed to a human approver in the audit trail
  • Risk containment — multi-party approval prevents single-actor mistakes on broad changes
  • Trust calibration — auto-apply autonomy escalates per action class only after a measured history of successful outcomes

02 · Risk tiers

What requires approval

1

Low-risk (contained blast radius)

Examples: deleting an unused EBS volume, terminating an idle Lambda, modifying a non-production tag.

Default: single approver. On the Trust Ladder enterprise tier, low-risk operations can be set to auto-apply after a configured number of successful outcomes.

2

Medium-risk (moderate blast radius)

Examples: rightsizing an EC2 instance behind an ALB, modifying an RDS parameter group, rotating an IAM access key.

Default: single approver with mandatory rollback path verification. Never auto-applied.

3

High-risk (broad blast radius)

Examples: modifying IAM policy on a privileged role, changing a security group attached to many resources, dropping a database resource.

Default: multi-party approval (2+ approvers). Can never be auto-applied regardless of trust ladder state.

03

Who can approve

By default, any organization member can approve. Enterprise tier supports:

  • Role-based approval gates (only members with the "approver" role)
  • Resource-scoped approvers (only specific resource owners)
  • Environment-specific approvers (production approvers vs. staging)
  • External approval via ServiceNow Change Request or PagerDuty escalation

04 · Audit

Audit trail

Every approval generates an immutable AxiomApprovalRequest + AxiomAuditEvent pair with:

  • Approver identity
  • Timestamp
  • Plan items approved and explicitly rejected
  • Optional note from approver
  • Pre-apply state and post-apply state
  • Rollback strategy at time of approval

Approvals are revocable until apply begins. After apply starts, rollback is the only path.

05 · Safe autonomy boundaries

The Trust Ladder

Trust Ladder is the model that lets agent autonomy escalate over time — only after measured success.

  • Per action class, the agent tracks success/failure ratio
  • After N consecutive successful outcomes (configurable, default 25), the action class can be promoted to auto-apply
  • Promotion always requires explicit org-admin approval — the agent cannot self-escalate
  • Any failure in an auto-apply class immediately demotes that class back to manual approval
  • High-risk classes can never be auto-applied regardless of history

Trust questions

What is happening at approval?

A human is reviewing a proposed change to your infrastructure before Axiom applies it.

Why approvals?

Accountability + risk containment + safe autonomy. The default for any autonomous system at enterprise scale.

Is it safe to approve?

Yes — each item includes blast radius, rollback path, RTO, and Terraform diff. You see exactly what will change.

What happens after I approve?

Pre-flight snapshot → apply → verification. Rollback fires automatically on health failure.

Can I revoke an approval?

Yes, until apply begins. After apply, rollback is the recovery path.

What if approval expires?

After 24 hours unapplied, the plan expires. Re-scan to generate a fresh plan against current state.

Need a human?

Most flows are documented — but we'll help if anything is unclear.

Talk to Vision XIX Labs