Your filesCSV, Excel, Parquet, PBIX — picked locally
→
DuckDB warehouseOne file on disk; read-only for analysis
→
Your LLMLocal (Ollama) or a provider you chose
→
Nowhere elseNo telemetry from the app, no background sync

The entire data path, start to finish.

Local-first by default

The warehouse is a DuckDB file on your disk. The web UI, API, and ETL run as one process on your machine. Nothing is uploaded unless you configure an external LLM provider yourself.

Auth & sessions

JWT-based authentication with bcrypt-hashed passwords. Signing keys live in a gitignored key file — never in the repo, never in logs, never in model context.

Safe SQL by construction

All queries are parameterized; user input never gets concatenated into SQL. Every generated query runs against a read-only connection, so the assistant can explore but not mutate.

Input validation at the boundary

Every API endpoint validates payloads with schemas before business logic runs. File uploads are checked for size and type. Error responses stay generic; details stay in server logs.

Secrets hygiene

Credentials, JWT material, and OAuth state live in gitignored runtime files. Redaction rules keep them out of chat, logs, and any context sent to a model.

Single-writer warehouse

Analysis opens the warehouse read-only; ETL writes go through one dedicated process. Fewer writers means fewer corruption risks and a clear audit trail for every write.

The promises

What we never do

  • Ship telemetry or phone-home analytics
  • Send your rows to a model provider you didn't configure
  • Store your warehouse in someone else's cloud
  • Log credentials, tokens, or signing keys
  • Ship third-party code inside the build without review
  • Run writes from multiple processes at once
  • Require a cloud connection to open your own data
  • Hide the SQL behind the answer

Found a vulnerability? We take reports seriously.

Report securely Read the docs
Full disclosure

Every place DataAgent talks to the network

We would rather you hear this from us than find it. Below is the complete list of outbound connections the app can make, what triggers each one, and what data, if any, is included.

Every install
  • Update check — one HTTPS GET to api.github.com on launch to compare the installed version against the latest release. Sends your IP address and a User-Agent string. No data and no identifiers are included, and the app makes no telemetry calls.
  • Your LLM provider — the prompt and whatever schema context the question needs, sent to whichever provider you configured. With a local Ollama model, this never leaves the machine.
  • Cloud provider sign-in — only if you use Google login or a cloud LLM provider.
Paid features only
  • Entitlement service — the billing server is asked whether your plan is current. Sends your email address and a signed request; returns a signed plan assertion.
  • IP rotation proxy pool — the IP rotation feature routes LLM traffic through third-party public proxies. Your prompts may transit machines you do not control. This is the one feature where a third party can see traffic, and it is off unless you enable it.
  • Cloud vision model — the recreate from image feature sends the screenshot you pick to your configured model provider. A local vision model keeps it on the machine; a cloud model does not.
What is never sent

The desktop app sends no telemetry, no analytics, no crash reporting, no product usage tracking, no advertising identifiers, and no server-side copy of your data. Your warehouse is a single file on your disk. There is no code path in this application that uploads it anywhere.

DataAgent ships as a local-first desktop app — there is no hosted multi-tenant service in this release, so no row of your data is ever processed on our infrastructure. The only outbound traffic the app can make is listed above: the update check, the LLM provider you configured, cloud sign-in, and the entitlement service that a paid plan uses to confirm that your licence is current.

One thing we will not overstate: single sign-on and row-level security are implemented in the code base but ship disabled by default (config/settings.yaml). If your policy depends on them, switch them on deliberately and test them — do not assume they are running in a fresh install. The same goes for the release itself: the installer is not code-signed yet, so SmartScreen shows “Unknown publisher” until a certificate is in place.

Want the machine-readable version, or to run a check of your own?

Read the security docs Download and inspect the source