What GuardKite needs from your account
GuardKite's access model is deliberately narrow: a single read-only IAM role in your AWS account.
This is the page to send to your security reviewer.
The IAM role
You deploy a CloudFormation stack that creates one IAM role in your account. GuardKite assumes that role to read configuration data.
The role:
- Is read-only. Its policy contains only
Describe*,List*, andGet*style permissions across the AWS services GuardKite scans. No create, modify, or delete permissions; no permissions to read application data inside resources. - Trusts only GuardKite's AWS account. The trust policy names GuardKite's own AWS account as the sole principal allowed to assume the role.
- Requires an External ID unique to your tenant. This prevents the confused-deputy problem — discovering the role's ARN isn't enough to assume it.
Review the role and its policies before deploying. The full CloudFormation template is on the Cross-account IAM role page.
What gets read during a scan
GuardKite reads configuration metadata — the kind of information AWS surfaces through Describe* / List* / Get* API calls.
| Resource | What's read | What isn't |
|---|---|---|
| S3 bucket | Name, region, encryption settings, public-access configuration, lifecycle rules, tags | The objects inside the bucket |
| IAM role | Managed and inline policies, trust policy, permission boundary, tags | Credentials of any session that assumed the role |
| EC2 instance | Instance metadata, security group associations, tags | EBS volume contents, anything running inside the instance |
| Secrets Manager secret | Resource policy, rotation configuration, tags | The secret value itself |
The rule: GuardKite reads how your account is configured. It never reads the data your applications store.
How scans run
Scans run automatically once a day. A scan assumes the IAM role using the External ID, makes the configuration API calls it needs, and stores findings against your tenant.
The configuration data is used only to produce the findings, IAM Risk signals, attack paths, and timeline events you see in the platform. It isn't sold, shared with third parties, or used to train any ML models.
Revoking access
The IAM role exists in your account, so revocation is entirely under your control. Two equivalent options:
- Delete the CloudFormation stack that created the role.
- Delete the IAM role directly from the IAM console.
The next scan's assume-role call fails, the account is marked disconnected, and no further scans run. Re-link any time by redeploying the stack.
Next steps
- Link your first AWS account — deploy the role and run your first scan.
- Cross-account IAM role — full policy reference and downloadable template.