Privacy Policy

Breno is self-hostable software. Who controls the data therefore depends on who runs the instance you are using:

• An instance your organization operates (on your own servers, or on infrastructure you rent). Your organization is the controller, and the operator of this instance is the party to ask about access, export and deletion. The vendor receives no content from it.
• An instance operated as a hosted service by [LEGAL ENTITY], [REGISTERED ADDRESS]. That entity is the controller for the purposes of applicable data protection law.

If you are not sure which applies to you, the administrator of your workspace can tell you — the answer is the same for everyone in a workspace.

• Account details. Your name, email address, and workspace membership and role. Passwords are stored only as a salted hash; if you sign in through a provider, we store the identifier that provider returns, not your password there.
• Content you put in.Documents you upload, notes captured through the API or MCP, and the derived data built from them: text chunks, embeddings, extracted entities and relationships, citations, and the history of questions you have asked.
• Content from connected sources. When you connect a source such as Slack, GitHub, Notion or Drive, Breno reads the material that source makes available to the credentials you granted, and keeps a copy of it with its provenance so it can be searched and cited. You choose the sources; disconnecting one stops future reads and leaves what was already ingested until you delete it.
• Connection credentials. OAuth tokens and API keys for connected sources, encrypted at rest with AES-256-GCM under a key held by the operator of the instance. They are used only to read from the source you connected.
• Usage records. Which answers were generated, the credits they consumed, and which model provider served them — needed for billing and for knowing what the instance has spent.
• Technical and audit records. Request logs (path, status, latency, IP address, and a trace identifier), and an audit log of administrative actions such as permission changes and deletions.

We do not use advertising or analytics trackers. See the Cookie Notice for the complete list of what the browser stores.

This is the part worth reading closely. An instance stores everything locally — documents, embeddings, the graph, memory records, audit logs. Exactly one class of traffic leaves it: the text needed to answer a question, and the text needed to compute an embedding, are sent to the model provider configured for that instance.

• For a search or an answer, the retrieved passages that the answer is built from are sent to the configured provider so it can generate the response and cite them.
• For ingestion, the text of an item is sent to the configured provider to compute the embedding that makes it searchable.
• Which provider that is — and whether it is a hosted service or a model running on your own infrastructure — is a configuration decision made by the operator of the instance, not by us. A self-hosted model means nothing leaves at all.

We do not use your content to train or fine-tune models, and we do not permit a provider to do so. Where a provider is used, the material is sent to it for the purpose of answering that one request.

If the instance is configured with connectors, it also makes ordinary outbound requests to those third-party APIs to read the sources you connected — that is the product working, and their own privacy policies govern their side of it.

• Items you delete go to the trash and are purged, with everything derived from them, 30 days later. You can purge an individual item immediately instead of waiting.
• Sync history (the record of what each connection fetched and when) is kept for 30 days, and the latest run for each connection is always kept.
• Finished sync jobs are kept for 90 days.
• Search history, answer traces and memory records are not swept on a timer; they stay until you delete them or delete the workspace. They are what makes an answer reproducible.
• Audit records are retained for the period the operator sets, because their purpose is to survive the events they describe.
• A workspace under legal hold is exempt from the scheduled purges above until the hold is lifted.

Deleting your account erases your personal data and, where you are the last owner of a workspace, the workspace and its content.

We do not sell personal data, and we do not share it for advertising.

• Model providers. As described in section 3, and only the text needed for the request in hand.
• Infrastructure the operator chose — hosting, the object storage that holds backups, and email delivery if it is configured. For a hosted instance these are named in the operator's subprocessor list; ask the administrator. For a self-hosted instance the operator is the only one who can answer, because the choices are theirs.
• Legal requirements. If we are compelled by law to disclose something, we will disclose the minimum required and, unless prohibited, tell the affected workspace.

• Credentials for connected sources are encrypted at rest; the key never leaves the operator's control.
• Tenant isolation is enforced in the database itself through row-level security, not only by application code, so a query that forgets to name a workspace returns nothing rather than someone else's rows.
• Sessions are held in httpOnly cookies, out of reach of page scripts.
• Administrative actions — permission changes, deletions, exports — are written to an audit log.
• Backups are encrypted before they leave the instance.

No system is perfect. If a breach affects your data, we will notify affected administrators without undue delay and describe what was exposed.

Depending on where you are, you may have the right to see the data held about you, correct it, export it, delete it, and object to or restrict certain processing.

• Export is self-service and complete: a workspace export produces a file with your items, their sources and their relationships, without needing to ask anyone.
• Deletion is self-service too — individual items, or the whole account.
• Access and correction are available through the product, or by contacting the administrator of your workspace.

If your organization operates the instance, requests go to that organization. For a hosted instance, contact [PRIVACY CONTACT EMAIL].

Everything an instance stores stays wherever that instance was deployed. A hosted instance is operated from [HOSTING REGION]; a self-hosted instance never transfers anything across a border as a result of using Breno, though the model provider it is configured with may be in another country, which the operator chooses.

Breno is a workplace product and is not directed at children. We do not knowingly collect personal data from anyone under 16.

When this policy changes materially, we will change the date at the top and tell workspace administrators before the change takes effect. Continuing to use the instance after that means you accept the updated policy.

Privacy questions: [PRIVACY CONTACT EMAIL]. If your organization runs the instance, start with your workspace administrator — they can answer most questions about what your instance stores and who can reach it.