Security
StationChief reads how your infrastructure is configured. It has no permission to read anything stored in it, and asks for none.
The audit role
ReadOnlyAccess is the policy most tools ask for, and it grants s3:GetObject and friends — actual customer data. The audit role is SecurityAudit plus ViewOnlyAccess with an explicit Deny on data-plane reads layered over the top. The template that creates it is published, and it is verbatim what the StackSet delivers.
Every tenant-scoped table carries row-level security, bound per transaction. Application-level filters are ergonomics, never the guarantee — the database refuses a cross-tenant read whether or not the query remembered to ask correctly. Tests assert that cross-tenant reads are impossible and run against real Postgres, not a mock. For a system holding many organisations’ security posture, that is not optional.
StationChief holds no long-lived credentials for your AWS accounts. Access is a cross-account role assumption into a role that you create and that you own. Delete the CloudFormation stack and our access ends the same minute — there is nothing for us to revoke, and nothing to ask us to delete.
What we read is how your infrastructure is configured. What we do not read is anything in it. That distinction is enforced by an explicit Deny rather than by policy or intent, and the template that encodes it is published.
Your data is hosted in US regions and is not used to train any model, ours or anyone else’s. You set retention. It is not an upsell and not a setting we hope you never find.
SSO/SAML and SCIM are included at every tier, free included. Role-based access governs what each person in your organisation sees, and access to your data is logged and signed.
Security questionnaire, or a question not answered here? Email us.
The template is published, and it is verbatim what the StackSet delivers.