PostureRadar asks you to let it look inside your AWS account, so you should be able to see exactly what that means. This page describes what we can access, how, and what we don't do yet. Where something is a limitation, we say so.
What access you grant
You deploy one CloudFormation stack that creates a single IAM role, PostureRadarScanRole, in each AWS account you connect. The template is public and short enough to read before you deploy it: customer-readonly-role.yaml.
- Read-only. Every permission is a
List,Describe, orGetaction. There are no write, delete, or modify permissions of any kind. - Metadata, not contents. The role has no
s3:GetObjectand no database or log read access. It can see that a bucket is public, not what's in it; it can see a security group's rules, not your traffic. - No long-lived credentials. We never receive an access key or password. Each scan assumes the role through AWS STS and gets temporary credentials.
- Scoped to us, and only us. The role trusts PostureRadar's AWS account and requires a random per-customer External ID, so nobody else can assume it even if they know the role's ARN (the standard protection against the "confused deputy" problem).
You stay in control
- Deleting the CloudFormation stack removes the role and immediately ends our access to that account.
- Because the role is in your account, your own CloudTrail records every time we assume it and every API call we make.
- Cancelling your subscription stops future scans. The role stays until you delete the stack.
How we protect our side
- Narrow assume-role permission. The scanning function is allowed to assume roles named
PostureRadarScanRoleand nothing else. - Payments are handled by Stripe. We never see or store card numbers.
- Signed, expiring links. Account-connection and "scan again" links are signed and time-limited, and "scan again" is rate-limited per account.
- Throttled public API. Every public endpoint sits behind request throttling.
- Our own account hygiene. Our AWS account has MFA on the root user, no root access keys, and a multi-region CloudTrail trail.
Where your data goes
We store your email, connected role ARN(s), and subscription state. We don't keep an archive of past findings. Each report is generated for that scan and emailed to you. A short list of providers process data on our behalf:
| Provider | Purpose | Data involved |
|---|---|---|
| Amazon Web Services | Hosting, database, report email delivery (SES), logs | Account records, report emails in transit |
| Anthropic | Drafts the remediation guidance in each report | Finding summaries (resource IDs, check names, regions); never credentials or the contents of your data |
| Stripe | Payments and the billing portal | Billing details, handled by Stripe directly |
| Cloudflare | DNS and CDN for postureradar.com | Website traffic |
See the Privacy Policy for retention periods and your rights.
What we don't have yet
- No SOC 2 or other audit report. PostureRadar is a young product and hasn't been through a SOC 2 or ISO 27001 audit. If that's a requirement for you, we'd rather you know now than find out later.
- Reports arrive by email. We send mail through Amazon SES, which uses TLS when the receiving mail server supports it, but email is not end-to-end encrypted and we don't currently force TLS delivery. Findings are metadata about your configuration, but they're still sensitive. If that's a concern, use a mailbox you control, and consider connecting a non-production account first.
- No dashboard yet. There's no web dashboard or findings archive. We're considering keeping findings behind a login and sending only a notification by email.
Reporting a vulnerability
If you find a security issue in PostureRadar, please email [email protected] with the affected URL or component, what you observed, and steps to reproduce. Our contact is also published at /.well-known/security.txt. We don't run a paid bounty program, but we read every report.