# Security and privacy

> Isolation, access, publishing, and what integrations in your network add.

Autonomy does not cancel control. The key principles:

- **Two-factor sign-in** with a code sent by email — or **single sign-on through your corporate provider**
  (OIDC / SAML 2.0): employees’ passwords stay with you, accounts are created on first sign-in,
  password sign-in can be closed for members. See [Single sign-on](/en/docs/sso).
- **Audit log** — who did what in the organisation, when and from where, including refusals;
  records are not edited or deleted, and each is linked to the previous one by a hash. The owner
  reads and exports it themselves, without a support request. See [Audit log](/en/docs/audit-log).
- **Isolation by organisation** — a separate space for every organisation; data
  and traffic do not mix.
- **Role-based access** — you decide who can do what in a project.
- **Nothing is published without approval** — changes reach your repository
  only after an “approve” decision in review.
- **Write-only tokens** — the keys to your repositories are stored write-only
  and cannot be read back.
- **The connector instead of handing over tokens.** If git must not be reachable by us at all,
  [run the agent on your side](/en/docs/connector): the token stays in your network.

## Mobile app

The [Buff app](/en/docs/mobile) for iPhone and Android does not widen the installation’s perimeter:

- The phone and the installation meet at the buff.systems gateway and encrypt every message with keys only they have; the gateway passes envelopes along and cannot read them. The text of push notifications is also encrypted for the phone — Apple and Google do not see it.
- The installation does not need to open ports to the outside — it connects out to the gateway itself.
- Pairing is confirmed by a person at the computer, the phone gets the permissions of whoever paired it, and there is no workspace password on the phone.
- The organisation owner or the installation administrator decides whether phones may be paired and sees all paired ones; a disconnected phone wipes the installation’s data.

In detail — [What buff.systems sees](/en/docs/mobile/trust) and [Access policy](/en/docs/mobile/policy).

## What integrations add

An integration is code that runs **on your machine**, so the question “what exactly
widens the attack surface” is a fair one. Three things widen it, and each has a boundary:

| What is added | What limits it |
|---|---|
| **Third-party code on your machine** | the bundle is signed with our key; the public key is built into the agent, and the signature is checked **before** unpacking. A version is revoked through a signed revocation list |
| **Access to your systems** | the account you created for the bot, and the connection’s scope: for trackers an empty list means “nowhere”; for Notion, Confluence, Google Drive, Figma and files — everything available to that account (see [boundaries for sources](/en/docs/connector/knowledge)) |
| **Inbound connections** | not needed, except for an event receiver for the two scenarios that arrive only by webhook: GitLab commit comments, and Figma without a list of files and projects (the Figma webhook comes from its cloud, that is, from the internet). The receiver’s link contains a secret ([how it works](/en/docs/connector/trackers#events-polling-and-webhooks)) |
| **Outbound requests** | a rule from the manifest: the host is taken from **your own field** in the form, plus the allowed methods and path prefixes. Link-local addresses (cloud metadata) are always forbidden |

The mechanics point by point, including directory permissions, OS users and what isolation
does **not** give you: [“Isolation and access boundaries”](/en/docs/connector/isolation).

Two properties worth knowing in advance:

- **An integration does not see secrets.** The connector builds the outbound request and inserts
  the credentials itself; an authorisation header set by the integration is stripped.
  The only exception is the SMB network share password of the “Files” integration: the protocol does not
  allow inserting it from outside, and this is noted in the catalogue.
- **No writing tool is ever given to the model** — at any stage. The reply in a
  ticket is written by the connector on the platform’s command, not by the model
  ([why](/en/docs/connector/tools#writing-tools-are-never-given-to-the-model)).

If there are no integrations and no [custom MCP servers](/en/docs/connector/custom-mcp), none of this
appears: without them the connector is a git bridge and nothing more. Custom MCP servers have different
boundaries: their outbound requests are not restricted by the connector’s gateway.

## Documents: what leaves and what does not

For the owner of a department’s documents — without technical detail. A space reads documents where they are: in Notion, Confluence, on Google Drive, on a server, in Figma. Nothing is copied or indexed in advance.

| | |
|---|---|
| **Never leaves** | passwords and tokens of your systems — they stay on the connector in the company network; documents outside the selected sections and folders; folders that were excluded |
| **Leaves at the AI agent’s request** | exactly the pages and files it opened for a specific answer — and only into that answer; every read is recorded in the connection’s log |
| **Leaves when someone asks from Notion, Drive or a ticket** | the text of the request, the title and link of the page or ticket, the author’s name |
| **Leaves continuously** | the connector’s state: whether it is online, which connections are running and what they are allowed — what you see in the “Connectors” section |
| **Then — to the model** | depends on the plan: on OpenRouter plans — a third-party provider’s models; on dedicated capacity and in an individual setup — models on a dedicated machine, nothing goes to third-party providers |

What this means in practice:

- **Read-only.** The AI agent does not edit documents, spreadsheets, pages or tickets — at any stage; it has no writing tools. The only things that appear in your systems are a reply comment and, if research was requested, a document next to it.
- **Two boundaries.** The outer one is the permissions of the account under which the connector reads your systems: a folder that was not shared is invisible. The inner one is the connection’s selected sections and folders. It is sensible to have both; do not connect folders with personal data — personnel files, medical certificates.
- **Who sees the answers.** In the app, a space is a permission scope: the HR space’s conversations and research are read only by members with permission on it; support does not see them until it is granted access. See [Scopes](/en/docs/teams/scopes). A question from a comment in an external system works differently: the bot answers whoever addressed it in a selected place — whether they are a Buff member is not checked; the answer draws on all of the space’s connections and is published as an ordinary comment visible to everyone who can see the page or ticket. So connect to a space only sections that outsiders — customers, contractors, guests — neither see nor comment on; more in [Ask from a document or ticket](/en/docs/ask-from-your-tools#who-can-ask-and-who-sees-the-answer).
- **Who reads the text.** It depends on the plan: on OpenRouter plans the text read is processed by third-party providers’ models outside Russia; on dedicated capacity and in an individual setup it does not go to third-party model providers, and in the Russian jurisdiction it stays on dedicated capacity in Russia and in the individual setup — see [Plans](/en/docs/tariffs).
- **Who asked and when** — in the organisation’s [audit log](/en/docs/audit-log): the creation of a conversation and of a research in the app is recorded with the member’s name; the texts of questions and answers do not go into the log. Questions from external systems go into the log only on failure; who asked is visible in the comment itself.

In detail, from the administrator’s side — [Connector: what goes out and what does not](/en/docs/connector#what-leaves-and-what-does-not).

## Data retention and deletion

Imported code is kept in your organisation’s isolated space. A copy is deleted
within 30 days of a written request from the organisation owner, and from backups
within 90.