Security, stated plainly.
One stack, one set of controls, across every Sable product. Here is what is in place today, what it runs on, and what we have not built yet. Send us your vendor questionnaire and we answer every line.
The same rules on every product.
Sable Pricing, Sable Charter, the Gov RFQ Service and Sable Law run on one stack and one set of controls. What follows is what is in place today, stated plainly, so you can check it against your own questionnaire.
Every connection is TLS. Data at rest is encrypted by the cloud provider. There is no plain-HTTP path to any Sable product.
Permissions are database rules (row-level security), not conditions hidden on a screen. A rep, a client, a crew member or an aircraft owner can only read the rows their role allows, even with direct API access.
Every licensed company is isolated from every other. Only Sable Labs can see across companies, for support, and that access is logged.
There is no public sign-up on any product. People get in when their company’s administrator invites them, and an invitation can be withdrawn at any time.
Available for every account. Sign-in is by password or emailed link; password resets never pass through us by hand.
Deals, trips, quotes, payments and statements carry a record of who changed what and when. The history is append-only and cannot be edited or deleted by any user.
Less to protect in the first place.
The simplest control is not holding the data at all.
Card details never touch a Sable product. Payments are handled by Stripe; we see the outcome, not the card. Wires are confirmed by your own staff.
Sable Pricing stores deal terms and contact names. It does not store SSNs, bank account numbers or credit reports.
Sable Charter sends from your own Microsoft 365 account. Sable Law drafts into your own Google Workspace, and nothing is sent until an attorney approves it.
Where a product uses a language model, it runs on Anthropic’s API under terms that keep your data out of model training. Zero data retention is available by arrangement; we confirm which features it covers before a build.
Each integration (Clio, Lawmatics, Google Workspace, Microsoft 365) gets only the access it needs. Credentials live in your accounts and are never placed in a prompt.
All data is stored and processed in the United States.
What it runs on.
Named, because you will ask.
| Layer | Provider | What it does |
|---|---|---|
| Hosting | Vercel | Serves the website and the applications over TLS |
| Database and sign-in | Supabase (PostgreSQL) | Stores application data with row-level security; issues sign-ins and two-step codes |
| Payments | Stripe | Takes card payments; Sable never sees card numbers |
| Transactional email | Resend | Delivers invitations, receipts and form acknowledgements |
| Language model | Anthropic API | Drafting and document reading, under no-training terms |
| Source control | GitHub | Private repositories; every change reviewed and deployed from a pull request |
Where we are, and where we are not yet.
Sable Labs is a small studio. We would rather tell you exactly what exists than imply a certification we don’t hold.
Everything on this page. A written security roadmap that decides what we add next. A named person who answers security questions within one business day.
No SOC 2 or ISO 27001 report of our own. Our providers (Vercel, Supabase, Stripe) publish theirs, and we can pass those along. If your procurement requires a Sable Labs report, tell us; it is on the roadmap and your requirement moves it up.
If you think you have found a security issue in any Sable product, email support@sablelabs.tech with “security” in the subject. We acknowledge within one business day and will not take action against good-faith research.
Send us your questionnaire.
Vendor security questionnaires, data-processing questions, a procurement checklist: send it as is. We answer every line in writing, usually within two business days, and we will say plainly where the answer is “not yet”.
Someone from Sable Labs will reply within one business day.