Security model

Your data stays where it is

Registering a catalog does not copy anything. Queries execute against your source, and only the rows a query returns pass through the platform — deleted after a day unless saved.

Credentials

Connection secrets live in AWS Secrets Manager. Our database stores a reference, never a value, and no API response, console page or AI tool returns one. They are resolved at the moment a query runs, inside the container that runs it.

Two consequences: nothing that holds your credentials is reachable from the internet, and a leaked API token cannot be turned into your database password.

Isolation between companies

Every query, catalog and stored result is scoped to one company, enforced in the query layer — a rewritten reference to another company's namespace is rejected before execution, not merely hidden in the interface. Results are stored under per-company prefixes, and metadata is collected per company.

Shared catalogs are the deliberate exception: they are visible to everyone they are shared with, so treat their contents as public to that audience.

Query execution

Each query runs in a fresh, isolated container that is discarded afterwards. Nothing persists between queries except what you asked to keep — the result, and the history entry.

Engine isolation

Queries run in a DuckDB session locked to your company's own storage prefixes: the object-storage buckets of your catalogs that carry their own credentials, flat-file catalog bases, remote Nessie warehouses, ClickHouse origins, your Iceberg warehouse and result prefixes, the prefixes of shared catalogs you can see, and the pod's own profile and scratch directories. File and URL access outside them is refused by the engine, and a query cannot change those settings. The lock does not cover credentials, though: creating or dropping a secret, and per-URL S3 options in a path's query string (?s3_endpoint=…), would change where a signed request goes. Both are refused by the SQL guard below, not by the engine lock.

SQL is also guarded twice: before rewriting, paths must name one of your catalogs; after rewriting, the final SQL is checked against your allowed prefixes. If a deployment supplies no lock, the session runs unlocked with a logged warning until a fail-closed follow-up lands. Dbt pipeline runs use a separate image and are not covered yet.

What we record

The SQL you submit, who submitted it, timings, CPU and memory used, row counts and any error message. This drives your history, cost reporting and support. We do not use your query data, or your customers' data, to train models.

Access to production

Limited to Thunderduck staff who need it to run and support the service. Data at rest is encrypted; all traffic is TLS.

AI assistants

An assistant receives what a tool returns, which for a query means the rows. From that point the data is governed by the assistant provider's policy and may remain in your conversation history there. Tokens are scoped: a read-only token cannot write, whatever the assistant is asked to do.

Full detail in the privacy policy (opens in a new tab).