Security
The controls AllRoles runs today — hosting, database-level access rules, hashed API keys, signed webhooks — and, just as plainly, the certifications and audits that are not in place yet.
DRAFT — NOT YET REVIEWED BY COUNSEL
This document is a working draft published for transparency. It has not been reviewed by a lawyer, it is not legal advice, and it is not yet a binding offer or final contract term. AllRoles currently operates without a formed legal entity; bracketed placeholders mark the points that will be completed when an entity exists and counsel has reviewed the text.
Security at AllRoles
A factual one-pager on the controls in place today
Scope of this page — read this first
DRAFT — NOT YET REVIEWED BY COUNSEL. This page describes the security controls AllRoles actually operates today, in plain language, for customers doing vendor review. It deliberately claims nothing beyond that: AllRoles has no SOC 2 report, no ISO 27001 certification, and no independent security audit yet. If your procurement process requires one of those today, AllRoles cannot meet that requirement yet, and this page will not pretend otherwise. Controls described here are current as of October 2026 and will be updated as they change.
Hosting and data layer
AllRoles is hosted on the Lovable platform with a Supabase (Postgres) database. Customer and account data lives in Postgres tables protected by row-level security: workspace tables (watchlists, saved reports, API keys, webhooks) carry policies that restrict each row to its owning account, enforced by the database itself rather than by application code alone. Public posting data is world-readable by design; everything account-scoped is not.
Access control
Business data access is entitlement-gated: a signed-in account sees the data workspace, exports, and API management only when its profile carries data access for a paid plan, and every workspace and export request re-checks that entitlement server-side — hiding a page in the browser is never the control. Database service-role credentials, which bypass row-level security, exist only in the server environment and are never shipped to browsers or embedded in client code. Administrative access to the platform and database is limited to the operator.
API keys and webhooks
Developer API keys are shown to the customer exactly once, at creation. Only a SHA-256 hash of each key is stored, alongside a short display prefix; a database leak would not expose usable keys. Keys can be revoked instantly by the customer, and each key carries its own per-minute rate limit. Outbound webhook deliveries are signed with HMAC-SHA256 using a per-webhook secret so receivers can verify that payloads genuinely came from AllRoles.
Transport, passwords, and payments
All traffic between browsers, the API, and AllRoles is encrypted in transit over TLS. Account passwords are handled by Supabase Auth and stored by that platform as hashes — AllRoles never stores or sees plaintext passwords. When card payments are enabled, they are processed by Stripe: card numbers go to Stripe and never touch AllRoles servers or storage.
The data pipeline
The postings dataset is refreshed by a scheduled pipeline that runs twice daily. Dataset history is append-only in effect: daily snapshots are written once and never restated, which also makes unauthorised alteration of historical data visible rather than silent. Pipeline failures are logged per source board so a broken feed degrades to stale data for that board, not corrupt data for everyone.
Backups and recovery
Database backups are provided at the platform level by the hosting provider (Supabase), and the application itself is version-controlled and redeployable from source. Recovery from a platform incident therefore depends on the provider's backup cycle; AllRoles does not operate a separate offline backup of customer workspace data today — another honest limitation for larger deployments to weigh.
Reporting a vulnerability
If you believe you have found a security vulnerability in AllRoles, please report it through the contact form on this site with enough detail to reproduce it. Reports are read by the operator directly. Please give a reasonable window to fix an issue before disclosing it publicly.
DRAFT — NOT YET REVIEWED BY COUNSEL. The Data Processing Addendum covers how these controls apply to customer data. For questions about this document, contact us via the contact options on this site.