Built like your regulator is watching
No badge theatre and no vague claims. This page describes exactly how your data is isolated and protected today, and what is still on the roadmap, in the language your vendor-risk review will use.
Every firm is its own workspace
Signing up provisions a fresh, isolated organization. Postgres row-level security runs with the caller's own token on every org-scoped table, so a session can only ever read its own firm's rows. Isolation is enforced at the database layer, not by UI hiding.
- Row-level security on obligations, gaps, controls, policies, tasks and alerts
- The API derives your org from the verified token and ignores client claims
- The shared regulation graph is common by design; everything firm-specific is org-scoped
Confirmed emails, invite-only teams
Accounts are confirmed by email through Supabase Auth. Teammates join only by invitation: an invited email joins the inviting firm's workspace at signup instead of getting a new one. Access is role-based, and the last admin of a workspace can never be demoted.
- Email confirmation before first login
- Admin-gated areas: document uploads and team management
- Last-admin guard prevents accidental lockout
Private storage, and no training on your data
Your policy documents live in a private storage bucket with no public access; only server-side code holding the service role can read them. Nothing you upload is ever used to train AI models, and nothing derived from your data is visible to any other firm.
- Documents in a private bucket, served through authenticated paths only
- Service-role credentials stay server-side; the browser holds only the public anon key
- No training on customer data, contractually and architecturally
Managed platforms, TLS everywhere
PolicyAI runs on Sevalla with data on Supabase's managed Postgres. All traffic is encrypted in transit with TLS, data is encrypted at rest, and secrets live in environment configuration, never in code or the client bundle.
- TLS in transit, encryption at rest on managed Postgres
- Secrets in env configuration, not in the repository
- Internal service endpoints guarded by a shared secret
Switchable providers, org-keyed caches
The AI layer is provider-switchable in one command, from frontier models to open-weight models, and Enterprise deployments can run an open-weight model on your own infrastructure. Prompt and result caching never crosses firms: caches are keyed per organization.
- Provider flexibility: frontier or open-weight models, your call
- On-prem open-weight option for Enterprise
- Cached extractions and answers are org-keyed; nothing leaks across workspaces
Found something? Tell us directly
If you believe you have found a vulnerability, write to us and include steps to reproduce. We acknowledge reports within one business day, keep you informed while we fix, and credit reporters who wish to be named.
- [email protected] for vulnerability reports
- Acknowledgement within one business day
- Vendor security questionnaires answered within one business week
What “isolated” means, concretely
A compliance buyer should not have to take tenancy on faith. These are the actual mechanics: the database policy runs with your token, and privileged operations never leave the server.
What we have not built yet
We claim no certifications we do not hold. These items are planned, not shipped; if one of them is a hard requirement for your firm, tell us and we will sequence it with you.
Running a vendor assessment? We answer security questionnaires within one business week.
Trust is earned in the details
Ask us anything about the architecture. We will walk your security team through the actual policies, not a badge wall.