Trust · Security

Security

Last updated: [DATE OF PUBLICATION]

Draft for internal review. This describes controls that exist in the codebase today (RLS, secret isolation, MFA enforcement, audit logging). Before publishing, confirm nothing here overstates a control that’s only partially rolled out, and add the incident-response and subprocessor-security-review process once those are formalized.

Data isolation

Every table in ScopeGov’s database enforces row-level security scoped to workspace membership. A session belonging to one agency’s workspace cannot read or write another workspace’s data, regardless of application-layer code — the database itself enforces the boundary.

Secret isolation

Sensitive workspace secrets (such as signing keys) are stored in a dedicated table with a deny-all row-level security policy, reachable only by trusted server-side processes using elevated credentials — never by direct client queries, and never exposed as a column on a table that ordinary workspace members can already read.

Authentication & access

Passwords are hashed and managed by Supabase Auth; we never see or store them in plain text.
Two-factor authentication (TOTP) is available to every account and enforced automatically for permissions we classify as governance-sensitive — approving change orders, managing billing, or configuring workspace-wide settings.
Sessions are managed via secure, HTTP-only cookies with configurable assurance levels; a stolen session cookie alone is not sufficient to act on a governance-level permission if MFA is enrolled.

Audit trail

Governance-relevant actions — sending a SOW, approving or rejecting a change order, granting a scope exception, changing a team member’s role — are recorded in an append-only audit log, attributed to the acting user and timestamped, so workspace owners can reconstruct who decided what.

Data in transit & at rest

All traffic to ScopeGov is encrypted in transit (TLS). Data at rest is encrypted using our infrastructure provider’s standard encryption-at-rest for managed Postgres and object storage.

Subprocessor handling

Where we send data to a subprocessor to power a feature — for example, sending a SOW to Anthropic’s API to check scope, or an email to Resend to deliver a notification — we send only what that specific request needs, not a workspace’s full data set. See the subprocessor table in our Privacy Policy.

Reporting a concern

If you believe you’ve found a security issue in ScopeGov, please email security@scopegov.app with details and, if possible, steps to reproduce. We’ll acknowledge reports and keep you updated as we investigate. Please give us a reasonable window to fix an issue before disclosing it publicly.