Security
Read-only by construction.
Infrox reads your AWS configuration and never touches your data. This page is the detail behind that sentence — what the grant covers, how it is gated, and how you take it away.
Free to sign up and connect an account. Payment starts when you run a scan.
The grant
An AWS-managed read-only policy, plus a short supplement.
The base of the role is a read-only policy maintained by AWS — a describe-and-list grant spanning roughly 32 services. Because AWS maintains it, new checks in those services need no change on your side.
It cannot
Read the contents of your data
No object bodies from S3, no rows from your databases, no application data of any kind. The grant covers configuration metadata only.
It cannot
Read secret values
No Secrets Manager secret values, no SSM parameter values, no environment variables carrying credentials.
It cannot
Change anything at all
No write, create, modify or delete permission anywhere in the grant. Every fix we recommend is applied by you, in your own account, when you choose.
It cannot
Hold a credential of yours
There is no access key to store, rotate or lose. Access is a cross-account role assumption, and nothing long-lived of yours ever reaches us.
A small supplement covers read-only calls the managed policy does not reach — cost, backup and resilience metadata for the checks in those pillars. It is the same shape as the base: describe and list, no data-plane access, no writes.
How it is gated
Three conditions, all of which must hold.
Connecting an account takes one click, but the access it creates is narrow by construction rather than by policy.
A role that lives in your account
You create it by deploying a CloudFormation stack we publish. It is your stack, in your account, and you can read every line of it before you launch it.
Trust scoped to two named roles
The role does not trust the Infrox account as a whole. It trusts two specific role ARNs — the scanner and the registration callback — so a compromise of any other principal on our side still cannot reach you.
An external ID unique to your tenant
Assumption is refused unless it carries an external ID that belongs to you alone. This is what stops one customer’s identifier being replayed against another customer’s role.
Revocation
Taking it away does not involve us.
Delete the stack in your AWS account and the role goes with it. Access ends at that moment, whatever the state of your Infrox account — there is nothing on our side to ask us to remove, and no ticket to raise.
You can also remove the connected account from inside Infrox, which stops us assuming the role while leaving the stack in place.
What leaves your account
Findings, not data.
A scan produces configuration findings. Those findings, and the reports built from them, are what we hold — all of it in the US East (N. Virginia) region.
The optional AI step
If you run a scan with the narrative layer, the findings are sent to the Anthropic API to be written up. For a single report that is your account ID, the region, the scan timestamp, the pillars in scope, and per non-passing finding its check identifier, risk level, title, resource type, resource identifier, detail and the recommended fix.
A combined report across several accounts sends less: the group and account labels you chose, each account’s score, its critical and high counts and its weakest pillar — no account IDs and no resource identifiers.
You can run a scan without it. The scoring is identical either way — risk levels come from the checks, never from a model.
Your Infrox account
Optional two-step verification via any authenticator app. Four roles — owner, admin, member and viewer — so an external client can be given a viewer seat without seeing your other accounts.
Card details are entered on Stripe’s own pages and never reach our servers. The privacy policy lists every sub-processor and what each one receives.
Something not covered here? Write to support@infrox.io and a person will answer.
Start free