Legal
Security
How Brain is built and operated, what protections are actually in place today, and — just as importantly — what is not yet.
Brain is an early-stage product operated by a small team. This page describes what is true today rather than what we intend. If you are evaluating Brain for sensitive data, read the limitations section first.
Reporting a vulnerability
Email hello@brayn.tech. We will acknowledge within five working days. Please give us reasonable time to fix an issue before disclosing it publicly. We do not currently run a paid bounty programme.
Machine-readable contact: /.well-known/security.txt.
Tenant isolation
This is the protection we have invested in most.
- Every workspace-scoped table carries a workspace ID and is protected by PostgreSQL row-level security, with the policy set to
FORCEso it applies even to the table owner. - The application connects as a dedicated least-privilege database role that is explicitly not permitted to bypass row-level security. If application code ever forgot a workspace filter, the database would still refuse to return another workspace's rows.
- Cross-workspace isolation is covered by an automated regression test.
Authentication
- Human sign-in is handled by Clerk. Session tokens are verified as RS256 JWTs against Clerk's published keys, checking issuer and expiry on every request.
- Your workspace is resolved only from the cryptographically verified organisation claim in the token — never from a client-supplied value.
- The session token is exchanged server-side and never exposed to browser JavaScript.
- Agent access over MCP uses per-workspace tokens, either issued to you directly or obtained by a chat application through OAuth 2.1 with PKCE. Either way we store only a SHA-256 hash of the token; the plaintext is shown once at creation and never again, and any token can be revoked at any time.
Source credentials
OAuth tokens for your connected sources are held by an instance of Nango that we run ourselves, on our own infrastructure. They are never sent to a third-party OAuth service, and Brain's application code reads them only at the moment it makes a request on your behalf.
To be precise rather than flattering: that broker stores its credentials in its own database on the same server as the rest of the platform, encrypted at the application layer with a key held in our environment configuration. You can revoke Brain's access from within your own provider at any time, and that is the strongest guarantee available to you.
Access we request
We request read-only access, scoped as narrowly as each provider allows. For GitHub we use a GitHub App restricted to the repositories you select, with read-only permissions on metadata, contents, pull requests and issues. For Slack we request read access to public channels and the user directory only.
Infrastructure
- All customer data resides on a single server in London, United Kingdom.
- All traffic is served over TLS with automatically renewed certificates. Plain HTTP redirects.
- The database and queue publish no ports to the public internet; only the web tier is reachable.
- Application containers run as an unprivileged user.
- Secrets are held in environment configuration on the host and are not committed to source control.
Current limitations
Stated plainly, because you would find them in diligence anyway.
- Redaction matches patterns, not meaning. Sensitive values are masked before storage and before anything reaches a model provider, but detection is checksum-and-pattern based: card numbers, national IDs, emails, phone numbers, API keys. Sensitive information written as ordinary prose is not masked, and a data class we have no detector for enforces nothing. See the Privacy Policy.
- Content is not encrypted at rest. The capability is built and is not switched on for any workspace today; content is protected by access control and per-workspace database isolation, not encryption. Backups are encrypted.
- Backups are not yet off-site. They are encrypted and they sit on the same machine as the database, which protects against a bad deployment but not against losing the machine. This is our highest-priority operational gap.
- No uptime or error alerting yet.
- No formal certification. We are not SOC 2 or ISO 27001 certified and do not claim to be.
- Agent write operations are not rate limited.
- No self-service deletion. Deletion is performed by us on written request within 30 days.
The public demo workspace
We run a public demonstration workspace built from openly licensed community forum data, and publish its access token deliberately so anyone can evaluate the MCP interface. It contains no customer content and is isolated from every real workspace by the same row-level security described above.
Responsible disclosure
We will not pursue legal action against researchers who act in good faith, avoid privacy violations and service degradation, and give us a reasonable opportunity to respond. Please do not test against the accounts or data of other users — use the public demo workspace.