Security posture
How we protect your data — authentication, isolation, encryption, audit trails, and how to report a vulnerability.
Authentication#
How we verify it’s really you.
- Web UI
OAuth social or email and password. Session cookies are
HttpOnly+Secure. - REST API
Bearer API keys (prefix
sb_live_), cryptographically hashed at rest, scoped to specific permissions, IP-allowlistable, with daily caps. - MCP server
OAuth 2.1 with PKCE, RFC 8707 audience binding, RFC 9728 Protected Resource Metadata, RFC 7591 dynamic client registration, and rotating refresh tokens.
Data isolation#
Every row belongs to one account, enforced at the database layer.
Per-user data isolation is enforced at the database layer, not just in application code. A request from one account cannot read or write another account’s sessions, synths, integrations, or audit entries — the database itself blocks it before the query returns.
Encryption & key handling#
In transit, at rest, and in storage.
- HTTPS with HSTS preload across every public surface.
- Encryption at rest on the database for every table.
- API keys cryptographically hashed before storage. Only the non-secret prefix (
sb_live_xxx) is kept readable, for display in the console. - Webhook signing secrets and OAuth registry keys stored with database-enforced access controls — only privileged server code can read them.
Network hardening#
Defence-in-depth across every public-facing surface.
- Strict Content-Security-Policy and Permissions-Policy headers.
X-Frame-Options: DENYto block click-jacking.- Outbound webhook delivery validates target URLs through an SSRF guard — RFC 1918 ranges, loopback, link-local, and cloud metadata IPs are blocked.
Audit trail#
Every API and tool call is recorded with sensitive fields redacted.
Every API key call and every OAuth-authenticated tool execution is logged: tool name, parameters with sensitive fields redacted, status, HTTP code, correlation ID, duration, and source IP. MCP audit entries retain for 12 months; tool-execution events retain for 90 days. Inspect your own log at /mcp/console → Audit.
Prompt-injection defence#
Hostile content in user input cannot override the synth’s instructions.
- User-input sandboxing
Free-text fields are wrapped in explicit boundary markers before composition into prompts. Instruction-style text in a user message cannot escape and re-author the system instructions.
- Upload sanitisation
File uploads pass through content sanitisation and prompt-injection scanning before any text reaches a model.
- Skeptic review
Every destructive tool action is reviewed by a Skeptic model before it can execute — designed to catch the “the AI decided on its own to send money” class of failures.
Tool-execution governance#
You stay in the loop on anything destructive.
For any action that writes to one of your connected tools, the synth proposes the action, the Skeptic reviews it, you see a clean preview, and only then you approve. After execution you have a 30-second undo window. You can disable tool execution per session, or restrict to specific tool slugs (e.g. only Gmail drafts, only Linear reads).
Third-party data flow#
Where your prompt and data go after you hit run.
Prompts and session data flow to the model providers listed in our privacy policy §3.1. None of the providers train on your data. Composio handles OAuth and tool execution for our integration providers — see Composio documentation for their handling.
Responsible disclosure#
How to report a vulnerability.