Trust
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, experts, 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 expert’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.
Tool-execution governance#
Every write she prepares waits for your confirm.
On Home, your Chief of Staff can write into a connected tool for you. She never writes on her own: every write is a card you confirm. It arrives in the thread as a preview card — where it goes and what it says — with a confirm button. Nothing is written until you press it; dismiss the card and nothing is written at all. When you confirm, the write is re-checked from the card itself, never from what the page sends: your plan, the connection, then the same audited gateway every tool call goes through. Writes are on Pro and above. On Free she says so and gives you the words to paste yourself — no card. Reading your connected tools is never gated, on any plan.
For an action an expert proposes inside a room, you see a clean preview, and only then you approve. 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.