One row per dimension, one column per cloud — the identity used, the role granted, how long the credential lives, and every API called. Read it against your own policy and the answer to “what can this thing actually do?” is on the page rather than in a support thread.
Write access: none requested. In all three clouds. Not scoped-down write, not write-with-approval — none. There is no code path in the product that mutates a customer resource, which is why remediation is recommended with an estimated saving and run by you, in your own console.
The policy is published, not described. The exact permission set for each cloud is versioned and published verbatim. A change to it ships as a new template you apply deliberately — permissions never widen underneath you.
No standing access, no stored secret. No long-lived credential is issued, stored or even accepted. A role or identity created in each account is the only supported path — assumed by the collector on AWS, Entra workload identity federation on Azure, Google Workload Identity Federation on Google Cloud — and it runs inside your own tenant boundary, minting a short-lived credential per run.
Revocation is yours alone. Remove the role, the app registration or the service account. Access ends at the next scheduled run — no ticket, no vendor involvement, and nothing left on our side to purge. The scan cycle shows where each of these APIs is called, and the compliance page carries the same commitments in prose.
Need the policy documents themselves for a security review? Email support@cloud-vex.com.
Join the waitlist