Multi-cloud breadth is a marketing lever, not a depth lever. We made the call early to be AWS-only and to be deeper on AWS than any tool that has to also cover Azure and GCP. Here's the rationale.
What 'depth' looks like on AWS
- Org-aware reasoning — SCPs at the OU level, permissions boundaries, Identity Center permission sets. Cross-account audit roles via STS:AssumeRole with external-id rotation.
- Bedrock-native inference — we run the agent loop on Bedrock guardrails inside our isolated platform account. Customer prompts never leave the AWS Bedrock managed inference path.
- Reachability resolution — we walk SG → ENI → subnet → route table → IGW deterministically before flagging a 0.0.0.0/0 ingress as critical. Most checklist tools don't.
- Effective-permissions resolution — we wrap iam:SimulatePrincipalPolicy to give the deterministic answer to 'can this role actually create users?' instead of inferring it from the policy text.
Each of those takes weeks of AWS-specific engineering. Stretching those across three clouds means doing a less-deep version on each.
The bet: Cloud-by-cloud depth wins more deals than surface-broad coverage. The buyer with serious AWS Org concerns picks the tool that knows how to read SCPs.
When we'll change our mind
If we hit a market where the median customer runs production-critical workloads on Azure or GCP and would specifically value the same depth there, we'll re-evaluate. So far that customer hasn't shown up in our pipeline. The customer who DOES show up: regulated AWS-heavy teams who got burned by surface-broad tools that didn't know what an OU is.