The Axiom permissions model.

Most cloud incidents involving third-party tools trace to over-permissive integration roles:

• Vendor compromise becomes customer compromise when the integration role has write access
• "Just-in-case" permissions accumulate and rarely get cleaned up
• Auditors can't reason about scope when the role grants * on broad services

Axiom solves this by making the smallest possible role the default — and forcing every additional capability to be a deliberate opt-in.

The role Axiom creates during onboarding contains only Describe / Get / List actions across:

• EC2, S3, RDS, IAM, CloudWatch, CloudWatch Logs, Cost Explorer, STS, Resource Groups Tagging

It cannot:

• Create, modify, or delete any resource
• Read object content (S3) or row data (RDS)
• Decrypt secrets or KMS keys
• Read Lambda function source code or environment variable values
• Modify IAM policies, users, roles, or permission boundaries

Full policy + per-line explanation at /docs/aws-setup.

Execution requires a second IAM role you create per action class. Three rules:

• Per action class — separate execution roles for cost optimization, security remediation, drift correction, and ReleaseOps. You can enable only the classes you want.
• More scoped than scan — execution role permissions list specific Modify/Delete actions Axiom needs, never *.
• Approval-gated — Axiom assumes the execution role only after an approval flips a plan item to "approved". Outside of an approved apply, the execution role is never assumed.

Axiom presents the exact execution policy at the moment you enable an action class. Nothing speculative.

Azure connector ships via Service Principal + role assignment:

• Read-only scan: Reader built-in role at subscription or resource-group scope
• Plus a custom read-only role for Azure Cost Management + Activity Log analytics
• Execution: separate custom role created per action class (preview Q2 2026)
• No client secret stored — Axiom uses federated identity (workload identity federation) where available

Subscription/resource-group scoping is enforced at the role assignment level — you control exactly which scopes Axiom sees.

GCP connector ships via Service Account + IAM role binding:

• Read-only scan: roles/viewer + roles/iam.securityReviewer at project or folder scope
• Plus custom roles for Cloud Billing + Cloud Audit analytics
• Execution: per-action-class custom roles (preview Q3 2026)
• Authentication via workload identity federation — no JSON key files stored on Axiom's side

Permission classifications drive approval routing:

• Low risk (contained blast radius, idempotent) — single approver. Can be Trust-Ladder-promoted to auto-apply after measured success.
• Medium risk (moderate blast, reversible) — single approver. Pre-verified rollback required. Never auto-applied.
• High risk (broad blast or hard-to-reverse) — multi-party approval. Cannot be auto-applied regardless of Trust Ladder state.

See approval workflow.

• AWS — delete the IAM role in your AWS console. Axiom loses all access on next assume attempt.
• Azure — delete the role assignment for the Axiom Service Principal, or disable the SP entirely.
• GCP — remove the IAM binding from the Service Account, or disable the SA.
• Org-wide — disconnect from Dashboard → Settings → Connections → Disconnect all. Stops Axiom from attempting future assumptions across all providers.