How data processing actually works

The operator of the data from the forms on capyagent.ru and capyagent.com is sole proprietor ИП Смольников Кирилл Георгиевич, who is also the rights holder of CapyAgent.

• What we collect. Your name, Telegram, phone or e-mail, the text of the request and the optional answers about your CRM and team size. The request also carries the page of the site it was sent from, the previous page (referrer) and the tags of an advertising link (UTM), if there were any.
• Why. To answer the request and to see which page it came from. There are no mailings.
• Where it goes. The request arrives in the owner's Telegram, and he reads it himself.
• Consent. The form is sent only with the consent box ticked.
• Contact. Questions and withdrawal of consent go to hello@capyagent.com.

You are the controller. These are your clients, your staff and your consents. You decide why the data is processed and you answer for it before the person whose data it is.

We are the processor. We process on your instruction and in your interest. We have no purposes of our own: the data does not go into advertising, is not sold and does not train models.

That is why a separate processing instruction is attached to the contract, as part 3 of article 6 of 152-FZ requires. We hand the template over together with the invoice.

If you installed the agent yourself, CapyAgent does not receive your local files or history. They remain on your machine; what is sent out is the material required by the model, channels and services you connected and, from version 1.3.8, anonymous install statistics (see the "Install statistics" section). Legal roles depend on your specific processing setup.

Apart from the anonymous install statistics from version 1.3.8 (a separate section below), every external address comes from the model, channel or service selected by the owner of the installation.

• To the model provider goes the content of the conversation: the question, the history, memory notes, document texts and images if the model can see. This happens on every reply, otherwise the agent does not think.
• To speech recognition goes the voice recording, if voice is on. By default this is Yandex, inside Russia.
• To the channel goes the agent's reply: Telegram, Discord or a Bitrix24 portal, wherever you talk to it.
• To your own systems goes the work itself: letters, deals, calls, documents.

About the border. If a foreign model is chosen, the content of the conversation leaves Russia, and that is a cross-border transfer with everything 152-FZ attaches to it: the notification and the legal ground are the controller's duty, that is yours. If that does not suit you, a Russian model is chosen in the settings - GigaChat or YandexGPT - and the agent works just the same.

The full list of addresses the core can ever reach lies in plain text in deploy/egress-allowlist.txt. It is not documentation: the build fails if an address appears in the code that is not on the list, or if the list still names an address the code no longer uses.

The CapyAgent side panel is a thin client for the core that runs on your own machine. It has no server of its own, creates no account with us and never reaches out: the only address the browser lets it call is http://127.0.0.1/*, that is, your computer. This is not a promise but the host_permissions field in the manifest, enforced by the browser itself.

What it reads, and when

• The content of the open tab - only when you press the button, only with the "Attach the open page" checkbox ticked, and only from the tab in front of you. It takes the address, the title, the selected text and up to 20,000 characters of visible page text.
• Without that press the extension does not read tabs at all: there is no background collection. Browser service pages (chrome://, about:, extension pages) are never read.
• Your question to the assistant and the tool arguments - exactly what you typed into the panel.

Where it goes

• To the CapyAgent core at the address you entered in the panel settings: by default http://127.0.0.1:18800, that is, the same computer. The request is signed with the access token the core prints at startup.
• What happens next is decided by the core, not by the extension. If you have a model connected, the request text together with the attached page goes to the model provider you chose, under the rules described in "Where the data goes" above.
• Nothing from the panel reaches us in any form: the extension has no address outside your machine.

What the extension stores in your browser

• The core address and the access token - the addr and token keys, so you do not retype them every time the panel opens.
• A panel conversation id - the chat key, a random string such as ext-a1b2c3d4, so the browser history does not mix with the Telegram one.
• Nothing else. The extension does not store the conversation you see in the panel: the feed lives in the open panel window, and the next time you open the panel it starts empty. There are exactly three keys in the storage, the ones named above.
• All of it lives in the extension storage (chrome.storage.local) on your computer, inside the browser profile. Removing the extension removes the core address, the access token and the conversation id - and only those. The conversation itself does not go with them: it is kept by the core on your machine, in its own data directory, and that is where it is deleted.

What the extension does not do

• It collects nothing and sends nothing anywhere except your core: there is no sending code in it. The install statistics from version 1.3.8 are sent by the app, not by the extension.
• It does not read or transmit passwords, cookies or the contents of input fields.
• It loads no remote code: everything ships inside the package, with no eval, no external scripts and no CDN.
• It does not sell data, does not pass it to third parties and does not use it for creditworthiness assessment.

Why each permission

• activeTab - to read the current tab when you press the button, and only that tab.
• scripting - to run a short function on that tab which collects the visible text. No other code reaches the page.
• sidePanel - to show the panel beside the page.
• storage - to remember on your machine the three values named above: the core address (addr), the access token (token) and the panel conversation id (chat). Nothing else is put into the storage.
• host_permissions: http://127.0.0.1/* - to talk to the core on your computer. There is no external address on this list, and the extension cannot add one by itself.

Versions up to 1.3.7 send nothing. From 1.3.8 the app sends anonymous install statistics. They contain no conversation text, files, keys, paths, user name or computer name.

The fields

• id - a random installation number: 32 characters from random bytes, created at install time and kept in the .install-stats-id file in the data directory. It belongs to the installation, not to a person or a computer.
• event - what happened: install, first_run, update_check, updated or rollback.
• version - the app version.
• os and arch - the system and architecture, for example linux and amd64.
• channel - stable or test.
• kind - the install type: cli, desktop or cell.

There are no other fields.

Why

To count how many installations are alive and on which versions and systems, and to decide what to support.

When and where

At the end of an install, on the first launch of the desktop app, and when an update is checked or applied. There is no separate send on every launch. Each send is one GET request to https://capyagent.ru/dl/ping, or to https://capyagent.com/dl/ping if that one fails. The server answers with an empty 204. If there is no answer within a couple of seconds, the send is dropped and nothing waits for it.

How long it is kept

The request lands in the web server log: the address it came from, the time, the fields above and the program name. The log is kept for 14 days and then deleted. While a record sits in the log it has an IP address, so saying that no address is stored anywhere would be wrong. The counters are computed by a separate program: it counts unique installations per day by installation number and writes only numbers into its result files, with no addresses and no installation numbers.

How to turn it off

• The environment variable CAPYAGENT_NO_STATS=1: installers, the core and the desktop app all honour it. The core and install.sh also honour NO_STATS=1.
• In the desktop app, the "Anonymous statistics enabled" switch in the About section. It is on by default. If CAPYAGENT_NO_STATS=1 is set, the switch cannot turn statistics back on.
• The command line has no switch in the settings, only the variable. There is no question at install time either: sending is on until you turn it off.

The update check contacts our server only if the owner has turned on updating over the network.

This section exists because a document without it reads as advertising.

• There is no encryption of data at rest. Files are readable only by the service user: the file is 0600, the directory 0700. Anyone who gets administrator rights on the machine reads everything. In the cloud the nightly copy is encrypted before it leaves, but the live disk is not.
• Conversations, notes and the profile have no retention period. They stay until you delete them with a command. There is no automatic cleanup for them, and that is a deliberate design of personal memory, not an oversight.
• Deleted things live on in copies. A note erased with the forget command remains in memory rollback points and in every backup taken before that. To remove it from there the copies have to be deleted separately.
• The log masks secrets but not personal data. Keys and tokens never reach the log, while a name, a phone number and an error text containing an e-mail address do.

This page is updated when the machinery changes, not once a year. What changed and when is in the changelog.