Security

Every workspace has its own organization identifier. Access to rows is controlled by PostgreSQL row-level security (RLS) policies that check membership before allowing any read or write. Users cannot access data from a workspace they do not belong to, and membership checks use SECURITY DEFINER helper functions to prevent policy recursion.

Workspace membership has two roles: admin and member. Admins can manage members and configure the workspace; members can work with service accounts, campaigns, and attestations. Users cannot add themselves to another workspace or elevate their own role — both are enforced at the database level.

Every meaningful action — account imports, ownership assignments, campaign creation, attestation responses, reviewer decisions — is recorded in an immutable audit log with the actor, timestamp, action type, and before/after values. The audit log is exportable.

Attestation requests are sent as time-limited, single-use links. Each link is tied to a specific account and campaign. Links expire after the campaign deadline and cannot be reused once an attestation has been submitted.

We store service account metadata (names, environments, owner assignments), review campaign data, attestation responses, and audit events. We do not store passwords, API keys, access tokens, or any credentials for the service accounts you track.

Transactional emails (attestation requests, reminders) are sent through SendGrid. Email addresses are used only for delivering attestation requests and account notifications. See our privacy policy for details.