Security at Responsible with AI
Our commitment to rigorous data protection standards.
Encryption in transit and at rest, access control, secure development, and infrastructure hosted with providers that meet high security standards.
Core security measures
Encryption
Data is secured in transit and at rest. In transit, all traffic is restricted to TLS/SSL (HTTPS). At rest, application and learning data are stored in a managed PostgreSQL database with encryption at rest. Sensitive data is never transmitted or stored in plain text.
Staged releases
Software is only released after being qualified in development and staging environments. Production deployments follow a controlled pipeline to reduce risk of regressions and security issues in live systems.
Data security & access control
Personnel and systems have access only to the data required to perform their function (principle of least privilege). User and tenant data are isolated where applicable via row-level security (RLS). Projects and data are stored with cloud providers that maintain top-tier physical and logical security controls.
Secure development practice
Code is peer-reviewed and tested prior to release, including manual and automated checks for security issues. Dependencies are kept up to date; database and API credentials are confined to the server and never exposed to the client or public bundles.
Hosted on Vercel & Supabase
The application is hosted on Vercel with automatic HTTPS and DDoS mitigation. Data is stored in Supabase (PostgreSQL) with encryption at rest and in transit. Customer data is primarily hosted in the EEA (e.g. eu-west-1) in professionally operated data centres.
Passwordless authentication
Authentication is magic-link (email) based; no passwords are stored or processed. Sessions use HTTP-only, secure cookies with configurable expiry, reducing credential and session-hijack exposure.
Platform security controls
Additional technical controls applied at the application and network layer.
Security headers
We enforce X-Frame-Options: DENY (clickjacking protection), X-Content-Type-Options: nosniff (MIME sniffing protection), and Referrer-Policy: strict-origin-when-cross-origin on all responses.
Rate limiting
Sensitive endpoints (e.g. waitlist, contact, auth) are subject to per-IP rate limiting. When limits are exceeded, the API returns HTTP 429 with a Retry-After header. This mitigates abuse and automated attacks.
Input validation & sanitisation
All incoming request payloads are validated and sanitised. This reduces the risk of injection (e.g. SQL, XSS) and malformed input affecting availability or data integrity.
Secrets management
Database connection strings, API keys, and authentication secrets are used only on the server. They are never included in client bundles or exposed via public environment variables.
