Trust & security

The Axiom security model.

Read-only by default. Assume-role over stored credentials. Multi-tenant isolation at the data layer. Immutable audit trail for every action. Revoke anytime by deleting one IAM role.

One sentence

Axiom never stores cloud credentials, never persists secrets, never has write access by default, and gives you a one-click way to remove all access at any time — by deleting the IAM role you created in your own AWS account.

01 · Credentials

How credentials work

Axiom never asks for, receives, or stores AWS access keys. We use AWS's assume-role model exclusively.

  • You create an IAM role in your account with a trust policy pointing at our AWS account + your unique External ID
  • For each scan, Axiom calls sts:AssumeRole and receives 1-hour temporary credentials
  • Credentials live in memory for the duration of the scan only — never persisted
  • When the scan completes, credentials are discarded; the next scan re-assumes fresh

The Role ARN itself is stored encrypted at rest. The ARN alone grants nothing — successful assumption requires (a) being our AWS account, (b) presenting the right External ID, (c) the role still existing in your account.

02 · Data

What Axiom stores — and what it doesn't

We store the minimum needed to operate as your cloud agent. We do not store anything we would need to ship product features without.

Resource metadata

Yes — instance types, regions, tags, configuration settings. This is what powers findings + recommendations.

Access keys / secrets

Never. Axiom uses assume-role and never sees access keys. Secrets Manager content is never decrypted.

Object content in S3 buckets

Never. We read bucket configuration (ACL, encryption, lifecycle), not file contents.

Database row contents

Never. We read RDS configuration metadata, not row data.

CloudTrail event history

Only configuration of the trail itself. We don't ingest CloudTrail events.

Reasoning + audit trail

Yes — every scan, finding, plan, approval, and execution is logged immutably. Required for SOC 2 / ISO 27001 audit evidence.

03 · Isolation

Multi-tenant isolation

Axiom is multi-tenant on shared infrastructure but logically isolated at every layer:

  • Database isolation: Every row is scoped to an organizationId. Every query joins through tenant scope. No cross-tenant read path exists.
  • Operational memory isolation: Each org's agent confidence, outcome history, and execution history is keyed independently. One org's outcomes never influence another's.
  • Credential isolation: Each connection has its own External ID. A malicious or compromised tenant cannot escalate to another tenant's cloud.
  • Audit isolation: AxiomAuditEvent is partitioned by organization. Audit-log export is scoped to your org only.

04 · Encryption

Encryption

  • In transit: TLS 1.2+ everywhere — between you and Axiom, between Axiom and AWS, between Axiom services.
  • At rest: Database encryption at rest (managed by the cloud database provider) plus application-level encryption for sensitive metadata (Role ARNs, connection state, audit event before/after states).
  • Key management: Customer-managed KMS keys available on enterprise plans.

05 · Execution model

Write access — only when you explicitly grant it

Read-only scans are the default. Execution (where Axiom can actually apply changes) requires a separate connection with a more-scoped role, and every execution goes through approval gates.

  • Execution role is opt-in per action class (cost optimization vs. security remediation vs. drift correction)
  • Approval is required by default for every production change. Blast-radius classification triggers multi-party approval for broad changes
  • Pre-flight snapshot + rollback path is captured before any modification
  • Every executed action writes an immutable AxiomAuditEvent with before-state, after-state, and rollback strategy
  • Auto-escalation of agent autonomy is blocked at the policy layer — the agent cannot grant itself more permissions over time

06 · Revocation

How to revoke all Axiom access

Two ways to remove Axiom access from your AWS account immediately:

  1. Delete the IAM role. In your AWS console → IAM → Roles → select the Axiom role → Delete. We immediately lose all access on the next assume attempt.
  2. Disconnect from the Axiom dashboard. Settings → Connections → Disconnect. This stops Axiom from attempting future assumptions but does not delete the IAM role itself. We recommend doing both.

Disconnection is also available from the desktop application (Settings → Connections) once installed.

07 · Compliance

Compliance posture

  • SOC 2 Type II — control mapping built into the audit layer; report available under NDA
  • ISO 27001 — control mapping in progress
  • HIPAA — BAA available on enterprise tier
  • GDPR — data processing addendum available; data residency on enterprise tier
  • SSO + SAML — supported on growth tier and above

Need a human?

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

Talk to Vision XIX Labs