sandbox · example data only · not your workspace
Cloud Operations Demo
Connect AWS → detect risk → recommend fix → human approves.
Shows the end-to-end loop from connector to safe remediation via human approval.
Steps
5
Est. time
~8 min
Audience
public
Reviewed
2026-05-23
engineer · Cloud Engineerconnector · AWS
data flow
scenario architecture
AWS ──assume-role──▶ Cloud Engineer ──scan──▶ finding
│
recommend (terraform diff + rollback)
│
▼
two-person approval ──tip──▶ apply
│ │
└────────audit row──────┘step 1/5·No approval needed
AWS connector live
Cross-account IAM role assumed.
visionxixlabs.com/dashboard/aws
AAxiom
Sign out
connectors · AWS primary
AWSlive
· auth · cross-account IAM role · sts:AssumeRole · externalId set
· region · us-east-1
· 142 resources visible
· last sync · 12s ago
invariantNo long-lived access keys stored. AWS assumes a role you create with an externalId we generate; Azure uses a service principal you control. You can revoke from the provider console without telling us.
Roles, not permissions
Roles compose into Permission sets via a pure permissionResolver kernel. Every dashboard route enforces it at the IO boundary; pages don't sprinkle their own auth checks.
safety invariants in play
- ✓Assume-role model — No long-lived access keys stored — workspace assumes a short-lived role you own and can revoke.
- ✓Closed-union types — Scope strings, event kinds, audit actions, approval rules are TypeScript closed unions — typos are compile errors, not runtime denial bugs.
expected result
Read-only access confirmed.
engineering principle
The whole loop — connector to apply — is gated by two human approvers and a verified rollback. Cost optimization, IAM hardening, drift correction all use the same kernel; the only thing that changes is which engineer proposed it.