Connect a cloud account¶
A connection tells your organization which cloud account a deployment runs in, and gives untrust a scoped, read-only identity there that it can test. Registering a connection does not start a scan: untrust does not scan your account from its own servers. Scans run with your credentials, on your workstation or in CI, and you upload the report. See How CLI and cloud fit together.
Who: an organization administrator, with permission to create a role, service account or app registration in the cloud account.
1. Register the connection¶
Open setup (or Assets & environments › Environments) and choose the platform:
| Platform | You enter |
|---|---|
| AWS Nitro Enclaves | The 12-digit account ID, the name of the IAM role untrust will assume (in that account), and one to ten regions. |
| GCP Confidential Space | The project ID, a user-managed service account in that project, and one to ten regions. |
| Azure confidential VMs | The Entra tenant, the subscription, and a single-tenant app registration with no secret. |
Choose Read-only (passive posture checks only, safe for production) or Active (adds the bootstrap write probe and host command checks) for the scan commands the console prepares for you.
The scope you register is fixed. To change it, register a new connection and archive the old one. An organization can hold up to 20 active connections.
2. Grant read-only access¶
The setup shows the exact grant to apply in your account with your usual tooling:
- AWS: a trust policy that lets untrust's connection-specific identity assume your role, bound to an external ID unique to this connection, and the read-only permissions the checks need.
- GCP: permission for untrust's connection-specific delegate to impersonate your service account, and the read-only roles the checks need.
- Azure: a federated credential on your app registration that only this connection's untrust delegate can use, and Reader-level role assignments.
No access keys, private keys or client secrets are ever requested or stored. The connection form rejects them.
3. Test the connection¶
Choose Test connection & permissions. Verification runs read-only access probes and reports one of:
| State | Meaning |
|---|---|
| verified | untrust can read what the checks need. |
| partial | Some capabilities verified and some did not; the result lists each one. |
| denied | Access was refused. IAM changes can take a few seconds to propagate; the console retries once. |
| error | The probe could not complete. |
| stale | The last result is older than the freshness window, or no longer matches the grant. Test again. |
For AWS, verification also confirms that your role refuses a wrong external ID, so the grant cannot be used by another tenant's connection.
A verified connection means read access works. It does not mean the deployment is secure, and it is not a scan result.
4. Scan and upload¶
The console prefills the scan command for the connection. Run it where your credentials
are, then upload the report (Scan now › Choose report.json, or
untrust report-upload):
untrust scan --platform nitro --region <region> \
--target-bucket <state-bucket> --instance-id <instance-id> --kms-key-id <kms-key-id> \
--output report.json
Add --read-only to skip the active checks. See Scan a deployment for
each platform's flags and permissions.
Archive a connection¶
Archiving keeps the connection's configuration and history and frees its slot. It takes effect immediately. Connections cannot be edited; register a replacement instead.