Security

Last reviewed 24 August 2026.

Sayble sits in the middle of real conversations — sales calls, interviews, support. That only works if the things you say to it stay yours. This page sets out, in plain language, what we actually do about that.

Your conversations

• We do not sell your data, and we do not use your conversations to train AI models.
• Conversation content is never displayed in our internal admin tools. Staff dashboards show counts, timings and account status — not what you said.
• Live audio is transcribed and discarded; we keep the transcript you can see in the app, not the recording.
• You can delete your account and your data from inside the app.

Encryption

• Everything travels over HTTPS/TLS. Plain HTTP is redirected, and we send HSTS so browsers refuse to downgrade.
• Data at rest is encrypted by our database provider (Supabase, on AWS).
• Our mail server publishes SPF and DKIM, and mail submission requires TLS and authentication.

Isolation between accounts

We test this rather than assume it. Before opening the beta more widely we created two accounts, gave both full access, stored a private playbook in one, then attacked it with the other account's real session:

• Reading another account's modes, prompts or reference files — blocked.
• Reaching any administrative endpoint — blocked (403 on every one).
• Granting yourself access or promoting yourself to admin — blocked, and nothing persisted.
• Tampering with the account identifier in the request — ignored; your identity is taken from your signed session, never from anything the request can claim.

We also retired an older sync endpoint in August 2026. Its address was derived from the account's email address alone, which meant someone who knew your email could have read the prompts and reference text stored there. It now refuses all requests, and every device syncs over an authenticated connection instead.

Who can reach your records

• Row-level security is enabled on every table in our database, so a query can only ever return rows belonging to the account that asked.
• Every API endpoint checks authorization on the server. The app is never trusted to decide what it is allowed to see.
• Your account identity is taken from your signed session token, never from data the client sends — so a request cannot claim to be someone else.
• Passwords are handled by our authentication provider and stored only as salted hashes. We never see, log, or store your password.

Keys and secrets

• AI provider keys and database service keys live only on our server, in a root-only configuration file. They are never shipped inside the desktop or mobile app.
• The app carries only a public, publishable key that is designed to be visible and is powerless on its own.

Abuse and availability

• Rate limiting is applied per endpoint class — sign-in, AI calls, speech, admin and general reads each have their own budget.
• An intrusion-prevention system watches the edge and bans hosts that probe or brute-force. It is active and banning continuously.
• Uploads are capped in size, accepted as text only, and require an authenticated, entitled account.
• Database access goes through a parameterized client — we build no SQL by string concatenation.

The desktop app

• The app runs with operating-system integration switched off in the page context and full context isolation, so a bad string can never reach your file system.
• Every window enforces a strict Content-Security-Policy that blocks loading or executing anything we did not ship.
• Links are opened through an allow-list — the app will hand only https: and mailto: addresses to your operating system.
• Updates are downloaded over HTTPS from our own domain, verified, staged, and rolled back automatically if the swap fails.

What we have not done yet

We would rather tell you than let you assume:

• The desktop apps are not yet code-signed, so Windows SmartScreen and macOS Gatekeeper will warn you on first install. Signing certificates are being obtained.
• No SOC 2, ISO 27001, or third-party penetration test has been completed.
• Two-factor authentication is not yet available on Sayble accounts.

Reporting a vulnerability

If you find a security problem, tell us and we will fix it. Email security@trysayble.com with enough detail to reproduce it.

• We will acknowledge your report within 5 business days.
• We will not pursue legal action against anyone who researches in good faith, stays within their own account, avoids privacy violations and service degradation, and gives us reasonable time to fix the issue before disclosing it.
• Please do not run automated scanners against our production systems, access another person\'s data, or exfiltrate more than the minimum needed to demonstrate the issue.

Questions

Anything else, write to support@trysayble.com. See also our Privacy Policy and AI Disclosure.