Security
Answers for your information security team — before they ask
Your security team will ask what exactly goes outside, who sees it and what can come back. Below are the answers point by point: what you can see in the app and the documentation, and what we confirm in writing in our answer to your questionnaire.
Objection 01
“What exactly goes outside, and what do you store on your side?”
The first question of any security questionnaire. The answer should be short and verifiable.
A copy of the code — and the token is your choice
The work needs only the code — and a space without code needs only the selected documents. Keys, the database, personal data and access to your network stay with you; the git token is your choice: with the connector it never reaches us.
Comes to us
- A copy of the code — a mirror of only the repositories you connected — whole, with the full change history: a secret or a staging address that ever got into a commit goes along with the code, even if it was deleted later
- A repository access token — if you work without the connector: with write access — to push the task branch and open a pull request; stored encrypted
- Your tasks and questions — what you write in the app yourself
- What is read from connected sources — pages, tickets and documents the model read for a specific answer — for the duration of the work
Stays with you
- The production database and its contents
- Keys, passwords and service secrets
- Personal data of your product’s customers — from the production database
- Access to servers, staging environments and the internal network
- The git access token — if the connector does the transfer
← scroll the diagram →
Stored in Russia
Code mirrors, organisation materials, user data and backups are on servers in the Russian Federation. The list of mirrors and their state is in the “Repositories” section.
Deleted on request within 30 days
The code mirror and all organisation materials — tasks, analyses, research — are deleted at the owner’s written request within 30 days, and from backups within 90. We confirm in writing.
Objection 02
“To take the code, do you need a token with access to our git?”
A token with repository permissions is the most sensitive secret in this setup. There are two ways, and in one of them the token never reaches us.
The token can stay in your network
The connector is a small agent you run on your side. It only calls out, touches your git for a task and carries repositories to us and pull requests back; the access token stays on the agent. Pairing uses a one-time code that lives for 15 minutes. It works both with servers in your network and with cloud GitHub, GitLab and Bitbucket — and for those too you need not give us the token at all.
If you do hand over the token
You need a token with write access to this repository — push and creating a pull request (in GitLab, at least the Developer role and the write_repository scope); administrator rights and access to other repositories and settings are not needed. The token is personal: it is added by the person who approves changes, and the pull request in your git is opened on behalf of the token’s owner. Protect the main branch with branch rules on your side.
How the token is stored
Encrypted (AES-256-GCM), with the key kept separately from the database. It is never shown in the interface and is decrypted only while working with your repository.
Integrations with your systems follow the same rules
An integration with a tracker or an internal service installs into the connector and runs as a separate process under its own OS user; it sees neither the connector’s key nor your tokens (the one exception is the network folder password), and goes outside only through the connector — to the addresses in its settings, and for the internet within your lists. What exactly it will get is visible before installation, not after.
← scroll the frame →
Objection 03
“What comes back into our repository, and who decides?”
Automation that writes to the main branch is what security fears most. There is none here.
Only a pull request comes back, and only after your decision
There is one way back: a pull request after the “Approve” decision. What that means in practice is below.
Synchronisation is one-way
Changes from your repository are pulled to us on your command. In the other direction synchronisation writes nothing.
Existing branches do not change
A change arrives as a separate new task branch together with a pull request. Your existing branches, including the main one, are not touched.
You do the merge
We do not merge pull requests — the merge decision stays with your engineer.
Nothing goes out without a decision
A task cannot be approved with open findings. Sending it back for rework restarts the work rather than publishing it.
← scroll the frame →
Objection 04
“Where is our code processed, and which models see it?”
A question that often gets an evasive answer. We answer plan by plan.
The plan decides where the AI runs — and you choose it
We do not use customer data for training on any plan. If you need a guarantee within Russian jurisdiction, choose dedicated capacity in Russia or a custom setup; on a limited budget, dedicated capacity outside Russia. Below, for each plan: where the model runs and whether code goes to a third-party provider; we confirm the providers’ terms on training and on storing requests in writing in our answer to your questionnaire.
Through a model provider
The “OpenRouter (Balanced models)” and “OpenRouter (your choice of model)” plans: code, your tasks and questions go through OpenRouter to models hosted by third-party providers. We select only providers and models flagged as “does not train on requests” — including when you choose the model.
Dedicated capacity outside Russia
A separate machine for your organisation outside Russian jurisdiction: code does not go to a model provider. The machine opens no ports to the outside — nobody can connect to the model from outside. Who owns the machine and who has access to it we confirm in writing in our answer to your questionnaire.
Dedicated capacity in Russia
The same, but within Russian jurisdiction and under an NDA: the guarantee that code does not go to a third-party model provider and is not used for training applies under Russian law. Connected on request; terms are agreed individually.
Custom setup
A separate environment for your company with access over VPN: code does not go to a third-party model provider and is not used for training — the same guarantee as on dedicated capacity in Russia. We sign an NDA. Terms are agreed individually.
Objection 05
“Where do code and tests run? Will the runners take anything they shouldn’t?”
An autonomous runner with broad rights is a risk in itself. So it has no rights.
Each task in its own environment, without keys and without your database
The environment is created for the task and deleted after it. Runners work outside your network and have no access to your infrastructure.
A separate environment for each task
One task cannot see another’s environment; once a task is finished, nothing of its environment remains.
Runners outside your network
They have no passwords, no keys and no staging addresses. They cannot be run with the restrictions lifted.
Tests without your database
Test data is generated from the database structure, not copied from production.
Objection 06
“Who inside the service sees our code?”
Isolation between customers and permissions within the team are what security checks next.
Your organisation, your roles, your sign-in
Each organisation has its own space: data and traffic do not cross with others. Within the organisation the owner grants access — by role, on the organisation, a project, a space or a single repository.
Single sign-on through your provider
OIDC or SAML 2.0: Keycloak, AD FS, Entra ID, Avanpost and any other. The owner sets it up on their own; accounts are created at first sign-in with the right role, and password sign-in can be closed for members. Employees’ passwords never leave your company.
The audit log is yours, not on request
Who signed in and from where, who changed permissions, submitted a task, approved a publication, what the pipeline did and what we did with your organisation — including refusals. Entries cannot be edited, are chained by hashes and export in full to CSV and JSON Lines. The owner reads it; a security officer gets a separate right.
Buff staff do not enter your code
Without your request, Buff staff do not enter your code; the exceptions are an incident and checking a breach of terms, about which you are notified. On your request access is granted narrowly — and revoked when the request is closed. We confirm in writing in our answer to your questionnaire.
← scroll the frame →
Objection 07
“What do you not promise?”
A security questionnaire values an honest “no” more than a vague “yes”.
We say plainly what is not there
Three things worth knowing before the conversation with your security team, not after.
The cloud is our service; your perimeter is your installation
Everything said here is about the buff.systems cloud and the separate environment we deploy and run. If code must not leave your network, Buff is installed on your side: the free Community Edition or Enterprise on-premise.
Through OpenRouter, third-party models see the code
On both OpenRouter plans, code, tasks and questions are processed by models at third-party providers. How it is limited.
An NDA is not available on every plan
On both OpenRouter plans and on dedicated capacity outside Russia, the contract is with a legal entity and we do not sign a separate NDA. An NDA is available only with a custom setup and dedicated capacity in Russia.
Objection 08
“We have no code — only documents in Notion, on Drive and in folders. What goes outside?”
A question from the security team of a company that has no development but does have a knowledge space.
Only what is read for a specific answer — and only from the selected sections
The connection reads only the sections, folders and servers your IT specialist selected, and only at the moment of the question: nothing is indexed or copied in advance. What comes to us for the duration of the work is the text read for the answer and the question itself; the documents stay with you and are not edited. On plans through an external provider (OpenRouter) that text is processed by its models — just like code; on dedicated capacity and in a custom setup it is not.
You set the boundary
The Notion and Confluence sections, Figma files, Drive and network folders and tracker projects named in the connection. If nothing is selected in Notion, Confluence, Figma, Drive or the folders, everything the AI agent’s account can see is open; for trackers an empty list means “nowhere”. So your IT specialist selects the sections explicitly. For Figma without a list, questions from comments arrive only by a webhook from the Figma cloud — which means opening the connector’s event receiver to the internet.
Nothing is changed
The AI agent has no writing tools: an answer arrives as a comment, a requested document as a new page or file alongside. Existing documents are not edited.
The account is yours
The connection runs under an account you created and restricted: read access to the sections needed only, plus permission to comment and create pages for answers and research. Its password stays in the connector on your side.
Permissions by department
A space is a permission scope: support does not see the HR space unless it has been given access. Who asked questions and when is in the organisation’s audit log.
Personal data
Connect documents with personal data only on plans where the text does not go to a third-party model provider — or do not connect them at all: the AI agent will answer from what you attach to the question.
Your own tool is yours
A system outside the catalogue your IT specialist connects with your own tool — a separate piece of IT work following our documentation; what the tool reads and where it goes is visible in the connector (the program in your network) before it is turned on, as with any integration from the catalogue.
Objection 09
“Employees will want to answer from their phones. Is that a hole in the perimeter?”
A phone is a personal device, outside the company network, and it can be lost.
The phone does not go into your network, and the gateway does not read messages
The phone and the installation meet at the buff.systems gateway and talk in a cipher whose keys only they hold: the gateway passes on the envelopes and cannot open them. The installation needs no open ports to the outside — it reaches the gateway itself.
A person confirms the pairing
A phone is paired from the workspace or from Buff Code: by matching six digits or with a QR code whose secret never goes to the server. Without confirmation on the computer the phone receives nothing.
No more rights than the employee has
The phone acts on behalf of the person who paired it and with their rights; when their rights change, so do the phone’s. There is no workspace password on the phone — only its own key, created on the device.
You set the policy
The organisation owner can forbid phones and sees all paired ones; in Buff Community and Enterprise the administrator decides who can pair phones and whether push notifications are sent.
A lost phone is cut off in a minute
From the workspace — by its owner or an administrator: access ends at once, and the installation’s data is wiped from the phone as soon as it goes online.
Security team questions
What people ask next
How do we revoke access?
The repository token is deleted in the app settings; revoke it in your GitHub, GitLab, Bitbucket or Gitea as well — that is more reliable than any button on our side. The connector is revoked with the “Revoke” button: access ends at once, and the agent can return only through a new pairing; when removing the agent, delete both its config and its state directory — they hold the git token and the agent’s key. Our copy of the code remains — we delete it permanently at the written request of the organisation owner within 30 days, and from backups within 90.
Where is the data stored and who has access to it?
Code copies, organisation materials and user data are stored on servers in the Russian Federation. For the duration of the work, the model of the chosen plan receives the code (with its change history, authors’ names and addresses), tasks, questions, research with attachments, documents read for an answer, the organisation identifier and the project name. On OpenRouter plans these are third-party model providers outside Russia. On dedicated capacity outside Russia it is a machine rented for your organisation: nothing goes to third-party model providers. On dedicated capacity in Russia and in a custom setup the materials do not leave Russia. Our staff are not given access to the materials without your request, except in the cases of clause 8.5 of the agreement — technical operations without viewing the content, incident investigation and legal requirements. Details are in the personal data processing policy.
An employee has left the company. What do we do?
The organisation owner removes the member — access to projects, repositories and tasks ends. Everything they did before stays in the organisation’s audit log: sign-ins with addresses, tasks, reviews, exports.
Is there single sign-on through our corporate provider?
Yes. The organisation owner connects the provider over OIDC or SAML 2.0 — Keycloak, AD FS, Entra ID, Avanpost and others — on their own, in the settings, in a few minutes. Employees’ passwords stay with you, accounts are created at first sign-in with the right role, and password sign-in can be closed for members. A departed employee who is disabled in the provider cannot open a new session.
Can we get an activity log for our security team?
You already have it — in the organisation settings, the “Audit log” section: who did what, when and from where, including refused sign-ins and actions without permission. It exports in full to CSV and JSON Lines, with no limit on depth; entries cannot be edited and are chained by hashes, and integrity is checked with a button or your own script. There is nothing to request from us; a security officer can be given a separate right to the log without being made an owner.
How do we make sure the downloaded agent is genuine?
Before installing, check the agent’s checksum and signature — the procedure is in the documentation, “Connector → Installation”.
Security questionnaire
Test us with your questionnaire
Send your security team’s questions to info@buff.systems — we will answer in writing, point by point, with links to the documentation. And you can start without a single change to your code or documents: connect a repository or create a knowledge space and ask your first question.
Companies and sole traders can pay by bank transfer and receive closing documents