Privacy Policy

Who we are

Brain is operated by PLACEHOLDER_BEFORE_LAUNCH — registered company name, a company registered in PLACEHOLDER_BEFORE_LAUNCH — place of registration (UK Ltd vs Delaware C-Corp) (Company No. PLACEHOLDER_BEFORE_LAUNCH — company number), registered office PLACEHOLDER_BEFORE_LAUNCH — registered office address. Our ICO registration number is PLACEHOLDER_BEFORE_LAUNCH — ICO registration number.

For anything in this policy, contact hello@brayn.tech.

Read this part first

Brain works by connecting to tools your team already uses — Slack, GitHub, Jira, Zendesk, Gmail, ClickUp, Discourse — and reading the conversations in them. Those conversations contain personal data about people who never signed up for Brain: colleagues, ticket reporters, email correspondents, open-source contributors.

If you connect a source, you are asking us to process that data on your behalf. You are responsible for having a lawful basis to do so, and for telling the people concerned. We tell you plainly what we do with it.

The two roles

• You are the controller of the content we ingest from your connected sources. You decide which sources to connect and what they contain. We process that content only to provide Brain to you.
• We are the controller of your account data — the identity and workspace records needed to run the service.

What we collect

Account data

Handled by our authentication provider, Clerk: your name, email address, authentication metadata, IP address, and the timestamp at which you accepted these terms. We store a workspace record linking your organisation to your data.

Content from connected sources

When you connect a source, we mirror the material you have scoped us to. For each message, issue, ticket, pull request or post, we store:

• The author's display name, their source-native user ID, and — for Gmail, Zendesk and Jira — their email address, which we use to recognise the same person across different tools.
• The full text of the message, comment or description.
• The title or subject, and structured fields such as labels, status and priority.
• The complete original API response, kept so we can reprocess without re-fetching. For Gmail this includes the full set of message headers, such as To, Cc and Reply-To. This copy is emptied 30 days after we ingest it — see "How long we keep it".

We also generate and store vector embeddings of message text, and the knowledge graph and Skills distilled from it. Everything we derive carries a provenance reference back to the source events it came from.

What we do not collect

No advertising or analytics cookies. No tracking pixels. No session replay. No cross-site tracking. No profiling. We run no analytics product of any kind — see the Cookie Policy.

Where your data goes

Hosting

All customer data is stored on a single server in London, United Kingdom, in a PostgreSQL database with per-workspace row-level isolation enforced by the database itself. Traffic is encrypted in transit with TLS.

Language model processing — please read this

Distilling Skills requires sending your content to a large language model. Today:

• The full text of your conversations, together with author display names, is sent to OpenRouter, which routes it to the model we have configured — currently DeepSeek.
• The same applies to the text we embed for search.
• Sensitive values are masked before this happens, where your workspace has rules configured — see "Redaction, and its limits" below. Everything else in the text is sent as written.
• OpenRouter is a router: the underlying provider that ultimately serves a request, and the country it is served from, can vary per request.
• Content already sent to a model provider cannot be recalled, including after you delete your workspace.

This is an international transfer of personal data outside the UK. We describe the specific recipients in the Sub-processor list.

You can stop this from happening at all. See "Keeping your data out of our hands" below.

Redaction, and its limits

Your workspace's profile carries sensitivity rules — a data class (payment cards, credentials, health identifiers) and how to handle it. Those rules are enforced, in two places:

1. At ingestion, before the row is written. A masked value is never stored, so the accurate statement is that we never held it — not that we hid it later.
2. Again before anything is sent to a language model, which catches content that arrived before a rule existed.

Be clear about what this is and is not:

• Detection is pattern-and-checksum based, not an understanding of your text. It reliably finds structured values: payment card numbers that pass a checksum, IBANs, national insurance and social security numbers, email addresses, phone numbers, IP addresses, API keys and tokens. It does not find sensitive information expressed in prose — "we agreed to pay her £95,000" is not a pattern, and will not be masked.
• A data class we have no detector for enforces nothing. Your workspace's Settings page lists every rule alongside the detectors that actually run for it, and says "not enforced — no detector" where there are none. That page is the truth; the rule list on its own is not.
• A workspace with no rules configured gets no redaction. We do not impose a default policy on your content.
• Masking is irreversible. We do not keep the original.

So: this materially reduces what reaches a model provider. It is not a guarantee, and it is not a substitute for not connecting a source you should not connect.

Keeping your data out of our hands

If sending your content to our model provider is not acceptable to you, there are two options that do not require you to trust us on it:

• Use your own model provider. We will point your workspace at your endpoint and your API key. Your content then goes to your provider and never reaches our account. Your key is stored encrypted and is never displayed back, including to you.
• Zero-retention processing. Your content is ingested, distilled, and emptied in the same job — the Skills and knowledge graph survive, the underlying text does not. The trade-off is real and we would rather state it: the evidence behind a Skill cannot be re-examined afterwards, and confidence in a Skill builds more slowly, because there is nothing left to compare a later conversation against.

Both are configured by us on request — email hello@brayn.tech. Your Settings page always shows which of these is in force.

What Brain does not do yet

We would rather tell you this than have you discover it.

• Redaction does not read prose. It matches structured values, so sensitive information written as ordinary sentences is not masked. See "Redaction, and its limits" above for what this does and does not cover.
• Deletion is not self-service. It is handled by us on written request — see below.
• Content is not encrypted at rest. The capability exists in the product and is not currently switched on for any workspace, so today your content sits in the database protected by access control and per-workspace isolation, not by encryption. Backups are encrypted. We will change this line the day that changes, not before.
• Our backups are not yet held off-site. They are encrypted, and they are on the same machine as the database, which means they protect against a bad deployment and not against the loss of the machine.

We will update this section as these change.

How long we keep it

Two different clocks, because the two things are not equivalent:

• The original API responses we mirror from your sources are emptied 30 days after ingestion. Nothing in the product reads them after processing, so this costs you nothing and removes the largest store of verbatim third-party text.
• The message text itself is kept for the life of your workspace by default. It is what provenance and search read, so expiring it would visibly degrade the product. If you want a limit on it, ask us and we will set one for your workspace.

When either clock empties something, the event record survives so that a Skill can still show you which conversation it came from — you will see "evidence aged out" in place of the text, rather than a Skill whose sources point at nothing.

Workspaces on zero-retention processing (above) are a separate case: their content is emptied as soon as it is distilled, and never reaches either clock.

Deleting your data

Email hello@brayn.tech from an address that is an administrator of your workspace. We will delete the workspace and everything in it — raw events, normalised events, embeddings, the knowledge graph, emitted Skills and access tokens — within 30 days, and confirm in writing when it is done.

Three honest caveats:

1. We will delete the OAuth connection we hold for each source, but you should also revoke Brain's access from within Slack, GitHub, Google or Atlassian directly — that is the only way to be certain.
2. Your user and organisation records live with Clerk and are deleted separately as part of the same request.
3. Content already sent to a language model provider cannot be recalled.

Your rights

Under UK GDPR you have the right to access, rectify, erase, restrict, or object to processing of your personal data, and the right to data portability. Where we act as processor for content from your connected sources, requests from the people in that content should go to you as controller — we will assist you in responding.

We do not use your data for automated decision-making with legal or similarly significant effects, and we do not sell it.

To exercise any right, email hello@brayn.tech. If you are unhappy with our response you can complain to the Information Commissioner's Office at ico.org.uk.

Sub-processors

The third parties who process data on our behalf are listed, with what each one receives, in the Sub-processor list. We will update that page before adding a new one.

The public demo workspace

We operate a public demonstration workspace built from openly licensed community forum data. It contains no customer content, and its access token is published deliberately. Nothing in your workspace is ever exposed through it.

Changes

Material changes will be notified by email to workspace administrators. The effective date and version at the top of this page identify which version applies.