Trust and security
What you are actually granting
You are being asked to give a third party read access to your AWS account. That is a reasonable thing to hesitate over. This page is written to be forwarded to whoever has to approve it.
You hold the off switch
Access is a CloudFormation stack in your account. Delete it and our access ends that second - no email to us, no offboarding request, no waiting on a support queue. That is the whole revocation process.
No credentials change hands
The stack creates a cross-account IAM role guarded by an external ID unique to you. You never send us a key, because there is no key to send. Reconnecting mints a fresh external ID, so a link from an old invitation stops working.
Two AWS-managed policies, nothing bespoke
SecurityAudit and ViewOnlyAccess, both written and maintained by AWS. We did not author a permission set and ask you to trust our judgement about its scope.
Every action lands in your CloudTrail
Each call we make appears in your own logs, attributed to the role you created. You can audit exactly what we read, when, and how often - without taking our word for any of it.
The permission set
Read-only means read-only. Here is the boundary.
The template is public. Read it before you deploy it rather than after, and check the two policy ARNs against AWS's own documentation.
What the role can read
- List and describe resources: instances, buckets, databases, security groups, IAM roles
- Read configuration: encryption settings, logging state, network rules, retention policies
- Read CloudWatch metrics, to tell an idle resource from a busy one
- Read AWS public price list data, which is a catalogue and says nothing about your account
What it cannot do
- Create, modify, delete or restart anything
- Read the contents of your S3 objects, database rows, logs or secrets
- Read Secrets Manager or Parameter Store values
- Access anything after you delete the CloudFormation stack
If this feels like a lot to grant
It is the same mechanism Vanta and Drata use
A cross-account IAM role with an external ID is how every compliance and cloud security platform connects to AWS. Vanta, Drata and Comp AI all ask for exactly this, because AWS designed it as the alternative to sharing credentials. If your team has onboarded any of them, this is a decision they have already made once.
Where we differ is scope. Those platforms monitor continuously and hold their access indefinitely. Ours runs when you ask it to, and most people delete the stack when the audit is done. That is a supported way to use this, not a workaround.
Data handling
What we keep, and for how long
- What we store
- Findings, your risk score, and the resource identifiers each finding refers to. Not the contents of any resource.
- Where it lives
- A managed Postgres database on AWS, isolated per account by row-level security so one customer cannot read another. Scans run on AWS Fargate in our own account and retain nothing once the task exits. If your organisation has a data residency requirement, ask us and we will confirm the region in writing.
- Who can read it
- You, and the engineer who runs your walkthrough. Access outside your own account is restricted to an allowlist and every such view is logged with the address that made it.
- How long we keep it
- Until you ask us to remove it. Removing a connected account from your dashboard deletes its scans and findings immediately.
- Subprocessors
- AWS (compute and scanning), Supabase (database and authentication), Vercel (application hosting), Resend (transactional email). No analytics or advertising tooling runs on signed-in pages.
Questions your security team needs answered?
Send them over. A senior engineer will answer them directly, before you deploy anything.