Trust Centre
Security overview
How we protect the systems we build and the client data held in this platform.
- Isolation enforced in the database
- Client project data is separated by PostgreSQL row-level security with a deny-by-default posture. Access requires active organisation membership and explicit project membership. A missed authorisation check in application code cannot become a cross-tenant data leak, because the database refuses the query.
- Least privilege throughout
- Service-role credentials exist only on trusted server code and are never present in a client bundle. Privileged tables and functions live in schemas that are not exposed through the API. Staff access requires explicit internal permission grants rather than inheritance from an email domain.
- Tested access boundaries
- Every role has both positive and negative access tests: what it may reach, and what it must not. Tests cover tables, storage paths, realtime channels and error behaviour, because a cross-tenant leak through a count or an error message is still a leak.
- Secure defaults in the application
- Content Security Policy, strict transport security, frame denial, referrer policy and permissions policy are set on every response. Authenticated surfaces are served no-store and marked noindex so they cannot be cached in a shared cache or indexed.
- Secrets management
- Secrets are held in environment configuration per environment, never committed to source, and never written to logs, fixtures or screenshots. Development, preview and production use separate credentials.
- Upload safety
- Files are validated server-side by inspected type rather than by the extension or the client-declared MIME value, held in private buckets under tenant-scoped paths, and served only through short-lived signed URLs with download auditing.
Questions
Ask us anything about this
Security and privacy questions reach a person who works on the platform, not a sales inbox.