Connecting your AWS account

Microsoft Entra ID and Azure are the live, proven surface. AWS coverage is in preview and rolls out per environment. The setup below is the path you follow once AWS is enabled for your account: you can prepare the role now, and verification switches on when Permafrost finishes provisioning AWS federation.

Permafrost reads your IAM users, groups, roles, policies, and permission boundaries so it can score every AWS principal against the access it actually uses, alongside Microsoft, in one identity attack surface. It reads by assuming a role you create in your account. It does not create an access key, and it holds no long-lived credential to your account.

The role grants Permafrost two things and nothing more: permission to read your IAM configuration, and a trust policy that names exactly one principal allowed to assume it. That principal is Permafrost, and the assumption only succeeds when the request carries your account's external id.

When you create the role, Permafrost shows an external id unique to your account. You place it in the role's trust-policy condition, and Permafrost sends it on every assume-role request. AWS only allows the assumption when both sides match.

This closes the confused-deputy gap. Without an external id, anyone who learned your role name could ask Permafrost to assume it on their behalf. The external id binds the role to your account specifically, so a role created for one account can never be assumed in the context of another. Permafrost recomputes the value server-side from your account and ignores any client-supplied id, so the binding cannot be substituted.

Permafrost attaches two AWS-managed read-only policies to the role. Both are maintained by AWS, so there is no inline policy document for your reviewers to audit line by line — they attach by ARN.

• SecurityAudit (arn:aws:iam::aws:policy/SecurityAudit) — reads security configuration across services, including the Organizations data Permafrost uses to see service control policies.
• IAMReadOnlyAccess (arn:aws:iam::aws:policy/IAMReadOnlyAccess) — reads IAM users, groups, roles, policies, and permission boundaries.

Together these cover the IAM surface Permafrost scores: principals, their attachments, the boundaries that cap them, and the service control policies that gate them. No write permission is requested, and no data-plane read (object contents, secrets values) is included.

The connect wizard generates a copy-ready CloudFormation template and a Terraform snippet that create the role named PermafrostReadOnly, attach the two managed policies, and write the trust policy with your external id in one step. Teams that manage IAM by hand can paste the trust policy directly and attach the policies in the console. Each artifact outputs the role ARN you paste back into Permafrost.

You finish by pasting the role ARN. Permafrost assumes the role with your external id and runs a single harmless read — iam:GetAccountSummary — to confirm access before the connection activates. There is no separate credential check, because there is no credential: the proof is that the read-only assumption works.

You hold the kill switch. Delete the role, or remove Permafrost from its trust policy, and access stops the moment AWS propagates the change. No coordination with Permafrost is required.