How climpt handles your data

Most teams reaching for AI on their data do one of two things: paste a connection string into a chat tool, or grant an autonomous agent direct database access. Both give a language model unbounded reach into production, with nothing between the model and your data but its own judgement. climpt is built the other way round.

• The model proposes SQL. It never executes anything and never sees a credential
• We validate that SQL mechanically, then run it under a scoped read-only credential you issue
• The model sees the result, not the database — it cannot widen its own access, browse other tables, or retry against something it was not granted

That is the substance of the claim that this is safer than the alternative. It is not that we are more careful. It is that the model is structurally unable to do the thing you are worried about, on every query, with no exception for a clever prompt.

There is no ingestion step. climpt does not copy, sync or mirror your data into our infrastructure — not at setup, not on a schedule, not ever. Analysis happens on demand: you ask a question, we generate SQL, and it executes against your database.

• Supported: BigQuery, Snowflake, Amazon Redshift, PostgreSQL, MySQL, and GA4 or Firestore via BigQuery export
• Queries run on your infrastructure, under credentials you issue and can revoke
• Revoking the credential ends our access immediately — there is no second copy to chase
• Queries name the columns they need, so a query reads the fields that answer your question and leaves the rest of the row untouched
• Queries are written to aggregate rather than extract, and anything over 300,000 rows must aggregate — it cannot be pulled back at all
• A hard 300,000-row ceiling sits behind both as a backstop against a runaway query, not as a target

This is the difference that matters most and the one that is hardest to reverse. A tool that ingests your warehouse has a permanent copy of your business inside someone else's system. We do not have one, so there is nothing to leak, subpoena or forget about.

Some data does reach our model provider, and we would rather be specific than reassuring. Interpreting a result requires a model to see enough of it to reason about. What we send is deliberately the smallest representation that answers your question.

• In chat: the generated SQL, your table and column names, and up to 20 rows of the result — a hard cap in code, not a setting
• In scheduled briefings: a columnar summary and a statistical profile rather than raw rows
• For computational analysis: the dataset is placed in a sandbox, described below
• Full result sets are never handed to a model

Who the provider is, and under what terms

We use OpenAI's API, not ChatGPT, under a Data Processing Agreement in which OpenAI acts as a processor. Data submitted through the API is not used to train their models. That is a contractual control rather than a technical one, and we would rather you weigh it as such than take a vague assurance from us.

OpenAI — how your data is used with the API

Questions that need real computation — a forecast, a clustering run, a chart over a full result set — execute in an isolated code sandbox. We treat that sandbox as ephemeral by design, and the expiry is set at upload time rather than left to a cleanup script to remember.

• Every file is uploaded with an expiry attached — four hours by default — so the provider enforces it independently of anything we do
• A scheduled sweep removes expired assets from both storage layers
• Deletion is confirmed in both places before the reference is dropped, so a partial failure retries rather than silently leaving data behind
• Sandboxes are per analysis. Nothing is shared between workspaces or pooled across customers

The window is deliberately short: long enough for a working session to finish inside it, short enough that nothing lingers overnight. It is a configured default rather than a contractual maximum, which is why this page says "within hours" rather than quoting a number we might one day tune.

climpt keeps no copy of your warehouse. No ingestion, no sync, no mirrored dataset going stale in our infrastructure.

• Query results are returned to you and rendered in the conversation, not warehoused on our side
• We hold no historical replica of your tables
• Nothing is pooled across customers, and your data never trains a model we or our provider operate

Note the boundary, because it is narrower than the version a vendor would prefer you assume. "We keep no copy of your warehouse" is true. "We store nothing" is not — the next section is the full list of what is kept, which is your own work rather than your business data.

What is stored is the work you do in climpt, not the data it reads. Being specific is more useful than being reassuring, so here is the actual list — including the parts that are less flattering:

• Account and organisation details — name, email, workspace membership
• Connection metadata — the schema, table and column names discovered during setup
• Generated SQL and your conversation history, so results stay reproducible. Conversations expire automatically, 14 days by default
• Analyses you create and their outputs, which persist until you delete them
• Files you upload, and documents you add to the Knowledge Hub
• A short-lived cache of files sent for analysis, held in our own storage so previews work without a round trip — cleared by the same sweep
• Connection credentials, held as described below

Everything in the list above can be removed, and removal is real deletion rather than a flag that hides it.

• Delete a connection and its stored credential is destroyed in Secret Manager, not merely unlinked
• Delete an analysis, a conversation or a Knowledge Hub document and it goes, individually
• Conversations remove themselves anyway, 14 days by default
• Delete the workspace and everything under it goes with it — records and stored files together, including every connection credential. Owner-only, and irreversible

There is nothing to reclaim from your warehouse afterwards, because climpt never held a copy of it. Revoking the database credential is the other half, and it takes effect immediately.

Database credentials are the most sensitive thing you hand us, so they are handled apart from everything else — and, as above, never exposed to a model.

• Stored in Google Secret Manager, not in our application database
• Encrypted a second time with a separately held key, so a Secret Manager read alone is not sufficient
• Scoped per connection, so one credential cannot reach another workspace's data

We recommend issuing a read-only user limited to the schemas you want reachable. The architecture assumes least privilege rather than asking you to trust that it will not be abused.

An AI writing SQL against production is only as safe as what stands between it and your database. Every generated query is parsed into an abstract syntax tree and checked before execution — never pattern-matched with regular expressions, which comments and string literals defeat trivially.

• Read-only: statements that would write, drop or alter are rejected, not sanitised
• No wildcard columns: SELECT *, table.* and schema.table.* are all rejected on the parsed tree, so a query cannot quietly widen what it reads
• One statement per query, so nothing can be chained after a valid SELECT
• The row limit is enforced on the parsed tree, not appended as text a model could undo
• Rejected queries fail closed — the model is told why and retries, and your database never sees them

The workspace is the trust boundary. Connections, documents, analyses and conversations belong to a workspace, and membership is what grants access.

• Authentication through Firebase Auth, verified server-side on every request
• Workspace membership checked on the server, not merely hidden in the interface
• HTTPS throughout the product, and encrypted connections to cloud data warehouses
• Encrypted at rest — Knowledge Hub documents and connection credentials are additionally encrypted by us before they reach storage
• For self-hosted databases we recommend a TLS-enforcing configuration; our connection guides cover the settings for each engine

We are an early-stage company and it would be easy to imply more than is true. You should hear this from us rather than find it during a review:

• SOC 2 — we have not begun a Type I or Type II audit
• Penetration testing — no third-party test has been performed

We hold no other security certifications either; at our stage that would be unusual rather than expected.

What we offer instead is specificity. Every claim above describes what the system does today and can be walked through with your security team in as much detail as they want. If a certification is a hard requirement for your organisation, tell us — it is genuinely useful to know, and we will be straight about the timeline rather than inventing one to win a deal.