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.
- 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.
- 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: the token stays in your network.
Mobile app
The Buff app 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 and Access 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) |
| 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) |
| 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”.
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).
If there are no integrations and no custom MCP servers, 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. 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.
- 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.
- Who asked and when — in the organisation’s 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.
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.