Trust
Read-only access, verifiably.
HardenAxis exists to hold sensitive access to your AWS environment responsibly. This page describes exactly how that access works, what data we do and don’t touch, and what we design against — no marketing gloss.
How access works
Every connection starts with a CloudFormation template that creates a dedicated, cross-account IAM role in your account. We never ask for AdministratorAccess, ReadOnlyAccess or SecurityAudit as a shortcut — the role is scoped to only the permissions each capability needs.
- A unique ExternalId per installation, so a stolen role ARN alone is never enough to assume it
- Short-lived STS sessions — no long-lived credentials are ever stored
- You can revoke access at any time by deleting the CloudFormation stack in your account
- No secretsmanager:GetSecretValue, ssm:GetParameter, kms:Decrypt or s3:GetObject in the MVP permission set
Tenant isolation
Every scan job is bound to a tenant_id, an aws_connection_id and a scan_id, with strict logical isolation enforced in depth, not just at the API boundary. Scan workers are ephemeral and run per job — no workspace is ever reused across customers.
What we handle — and what we don’t
We touch
- Account and region identifiers
- ARNs and resource names, as needed for evidence
- Configuration and policy documents needed to evaluate a control
- Normalized findings
- Hashes and digests
We never touch, by default
- Secret values
- S3 object contents
- Database data
- Application payloads
- Business logs
- Temporary credentials
Raw AWS API responses are processed in memory and discarded once normalized — we don't keep a copy beyond what a specific evidence mode explicitly requires.
What we design against
Adapted from our internal threat model — the same document our engineering team works from, not a separate marketing version.
Platform compromise leading to role assumption
Defense in depth around anything that could let an attacker assume a customer's cross-account role.
Confused deputy via ExternalId
A unique ExternalId per installation, validated on every assume-role call.
Multi-tenant isolation failure
Strict tenant_id scoping enforced at every layer, not only the API.
Exfiltration via logs or reports
Secrets, tokens, ExternalIds and raw sensitive payloads are never logged.
Scan abuse to drive up cost
Rate limits and quotas on scan jobs per tenant.
Supply-chain compromise
Dependencies and container images pinned by version or digest, with SBOMs generated per build.
Excessive connector privilege
Least-privilege permission sets, reviewed as new capabilities are added — never a broad shortcut role.
Manipulated findings or scoring
Explainable scoring, traceable back to the underlying AWS evidence.
Unaudited internal admin access
Every privileged internal action is attributable and logged.
On certifications
HardenAxis does not hold SOC 2 or ISO 27001 certification today, and we won't imply otherwise. Compliance Evidence Export (in Hardening Advisor, currently a coming capability) is designed to support your own audits — it is not a claim that HardenAxis itself is certified.
Questions about a specific control?
If you're evaluating HardenAxis for a security review, we're glad to walk through the IAM role, the exact permission set, or our threat model in more depth.