—Governance · Approvals
A write starts as a proposal.
The Agent can inspect low-risk context, but GitHub writes, deployment-target changes, identity configuration, and deployments stop at an explicit approval boundary.
The released boundary
01
Risk classification
- Low risk: read-only checks can execute inline and are still recorded.
- Medium risk: reversible configuration or repository changes require approval.
- High risk: deployments and sensitive configuration require approval.
- Production context: risk can only escalate; it is never reduced for convenience.
02
Approve or reject
The proposal shows the requested tool, arguments, risk, workspace, and status. Approval and rejection use separate authenticated endpoints. The Agent cannot approve its own request.
03
Execution and recovery
After approval, Axiom calls the same scoped responder used by the product surface. For AWS ECS, the tenant workflow captures the current task definition, waits for steady state, and restores the prior definition if stabilization fails.
04
Audit evidence
Every tool call receives an action record, including low-risk reads. The record distinguishes proposed, approved, rejected, executed, and failed states so observation is as reviewable as mutation.
Trust questions
Can the Agent write without approval?
Not through the released medium- and high-risk tool path.
Can production lower the risk?
No. Production context raises risk; it never lowers it.
Who approves?
A workspace administrator authenticated through the desktop-session path.
Are reads recorded?
Yes. Low-risk tool calls receive executed action records.
Does approval prove success?
No. Approval authorizes execution; the external result and validation provide outcome evidence.
Is every rollback universal?
No. The documented automatic rollback applies to the released ECS workflow.
Still blocked?
Include the failed step and error. Never send a password, token, or cloud secret.