Safata is a desktop and command-line application that runs on your own computer. It has no server component, no user accounts, and no analytics. This policy explains what that means in practice, and what happens to the data you connect to it.
Safata is built by Victor Zhang, an individual developer in Barcelona, Spain. "I" and "me" in this document mean that person. "You" means anyone who installs and runs Safata.
This policy covers the Safata application and this website. It does not cover the third-party services you may choose to connect it to — those are governed by your own agreements with them.
Nothing. Safata contains no telemetry: no usage analytics, no crash reporting, no update check, no remote feature flags, no error beacons. The application makes network requests only to the model vendors you configured, the services you explicitly connected, and the URLs you ask the agent to fetch.
Every one of those requests is written to a log file on your own disk, so the claim above is one you can check rather than one you have to take on trust. Bugs reach me because people write to me, not because a dashboard told me.
This website is a static page. It sets no cookies and runs no analytics script. Web fonts are loaded from Google Fonts, which means your browser makes a request to Google's font servers when the page loads; nothing else on this page contacts a third party.
If you connect Google Drive, Safata requests a single OAuth scope:
https://www.googleapis.com/auth/drive.file.
What that scope grants. Access to the specific files you select in Google's own file picker during the connection flow, and to files Safata itself creates. It does not grant the ability to list, search, browse, or read anything else in your Drive. Files you have not picked are inaccessible to the application.
How that data is used. Solely to provide the feature you asked for: letting the agent read the documents you picked so it can answer questions about them and produce the work you requested. Files are fetched from Google directly by the application on your machine, at the moment you ask for them.
Where it is stored. Content read from Drive is held in memory during the session and may be written into that session's transcript in the Safata folder on your own disk, so you can search your own history later. It is not stored anywhere else, and it is never transmitted to me.
What it is never used for. I do not sell, rent, or share Google user data. I do not use it for advertising or profiling, I do not use it to train any model, and no human at my end reads it — none of which is a promise about restraint, but a consequence of the architecture: the data never reaches me.
Revoking access. You can disconnect Google Drive inside Safata at any time, which deletes the stored credentials from your keychain. You can also revoke access independently at myaccount.google.com/permissions, which takes effect immediately regardless of what the application does.
Safata is bring-your-own-key. You supply an API key for the model vendor you prefer, and the application calls that vendor directly from your machine. I am not a party to that relationship and never see the traffic.
This is the transfer to be clear-eyed about: when you ask the agent to work on a document, the content it needs is sent to that vendor — including content read from Google Drive, if that is what you asked it to work on. This is the same transfer that happens when you paste a document into a vendor's own chat window, and it happens under your own account and key.
What that vendor then does with the content is governed by your agreement with them, not by this policy. If it matters to you whether your content can be used to improve their models, that is a setting and a contract on their side, and worth checking.
Safata records each outbound request — where it went and when — in a log on your disk, so this transfer is auditable after the fact rather than a matter of belief.
API keys, OAuth tokens, and service passwords are stored in your operating system's credential store — Keychain on macOS, Credential Manager on Windows — not in Safata's configuration files. They are attached to a request only at the moment it leaves the machine, and only for the specific host each credential belongs to.
Sessions, summaries, the local search index, the spend ledger and the request log live in a folder in your home directory, readable by your user account only. They are ordinary files.
To delete everything, delete that folder. To revoke a connected service, disconnect it in the application and, for Google, revoke it at your Google account as well. Because there is no server copy, deletion on your machine is deletion — there is nothing left elsewhere to request the removal of.
Protecting the folder against a lost or stolen computer is full-disk encryption, which is your operating system's job: FileVault on macOS, Device Encryption or BitLocker on Windows. An application cannot do it for you, and Safata does not pretend to.
Safata is a professional tool and is not directed at children under 16. I do not knowingly collect data from anyone — see above — and in particular not from children.
If the application's behaviour changes, this page changes with it, and the effective date at the top moves. A privacy policy that has drifted from the software it describes is worse than none, so the intent is to keep this page checkable against the shipped binary rather than aspirational.
Questions about this policy, about what the application does with your data, or a request about your rights under the GDPR: victor.zhang.eu@gmail.com. I answer these myself.