Skip to content
datarelix.ai docs

Security & Read-Only Controls

This page describes what Datarelix can do with your data and what the model is given, at the level of mechanism — the limits, caps, and error codes you need while setting things up. The customer-facing summary lives at datarelix.ai/security, and how we handle personal data is in the privacy policy.

Running a vendor security review rather than a setup? The threat model behind these mechanisms — what each control stops, and the risks that survive all of them — is in read-only AI analytics, and the questions to put to any vendor in this category are in the AI analytics security checklist.

The model plans; it does not execute

The model never runs anything. It receives your question plus schema metadata and returns a structured plan. A separate execution layer checks that plan against a strict schema and then runs each step itself.

That boundary is the reason a bad or hallucinated instruction has nowhere to go: there is no tool the model can call, no connection it holds, and no path from its output to your database that skips validation.

Every query is validated before it runs

Generated queries are checked before execution, not after:

  • SQL engines — the statement is parsed into a full syntax tree and rejected unless it is a read. SELECT, CTEs, and set operations pass; anything that writes, changes structure, or administers the server does not.
  • KQL (Kusto) and ES|QL (Elasticsearch) — these aren’t SQL, so each has its own validator that requires a read-shaped query and blocks mutating and administrative commands.
  • Scope — queries are confined to the schemas, datasets, or index patterns you allowed on the connection.
  • Caps — every query carries a row cap (5,000 rows) and a 30-second time limit.

A query that fails validation never reaches your database. You see it as a SQL_VALIDATION error — see error codes.

Credentials stay away from the model

Connection credentials are encrypted at rest and decrypted only at the moment a connection is opened to run a query. They are held by the execution layer, never placed in a prompt, and never returned in an API response.

The model is given the question, schema metadata, and conversation context. It is not given a connection string, a host, a username, a password, a token, or a key — and there is no code path that would let it request one.

You can narrow what any of this can reach by connecting a read-only, scope-limited database user. Every connection guide includes the grants for exactly that, and it is the setup we recommend. Two facts to be honest about: Datarelix can read whatever the credential you connect can read, and a scoped read-only user is the control that changes that. The read-only enforcement above holds either way.

Generated analysis runs in an isolated sandbox

When a question needs Python — a statistic, a transformation, a chart input — the generated code runs in an isolated runtime, not in the application:

  • No internet. Outbound traffic is blocked at the network layer by an egress firewall, not by a check inside the code that is being run.
  • Hard resource caps. 512 MB of memory and a 90-second wall clock; exceeding either fails the step rather than the service.
  • No credentials, no database. The sandbox receives the query results it was given and nothing else. It cannot open a connection.

More on what this runtime is for in Python analysis.

Your data is scoped to your account

Connections, runs, conversations, dashboards, and artifacts belong to the account that created them. Two mechanisms enforce that: every read is filtered by owner in the query itself, and every endpoint checks ownership — for a result or a chart, by walking back to the run that produced it — before returning anything. On the user-data tables, database row-level security sits behind both as a backstop.

There is no sharing model today — no way to hand a connection, conversation, or dashboard to another user, and no shared-workspace data. A Team plan shares the subscription and the question pool, not the data: each member keeps their own private connections and history. See Billing & plans.

What actually reaches the model

  • Your question, as you typed it.
  • Schema metadata — table and column names, types, keys, relationships, and any descriptions you’ve curated. AI schema analysis works from structure; it isn’t sent sample rows.
  • Conversation context on follow-up questions — earlier questions in the thread, the queries that ran, and their row counts. Where an earlier turn returned a single-row result, the values in that row can be carried forward as context so that “and what about last month?” resolves correctly. So: bulk results are never sent back to the model, but a scalar answer you already saw on screen can be.
  • Derived column information when building a chart — the shape of a column (a role hint, how many distinct values it has), not its values.

Results themselves are returned to you and stored with the run. They are not fed back to the model as data to reason over.

Every run keeps its trace

A run is stored as a step-by-step record: the question, the plan that came back, the query that actually executed, the tables it touched, the row count, and the runtime. You can reopen any of it from your history, which means an answer can be checked after the fact rather than trusted on sight.

This is a per-account run history, not an organization-wide audit log, and there are no admin roles or permission tiers — every account holds its own data and sees its own runs.

What we don’t claim

  • No organization-wide audit log, role-based access control, or user provisioning (SCIM). Not built.
  • No data-residency selection. You don’t choose a region for processing today.
  • No guarantee that an answer is the answer you meant. A question can be read differently than you intended; the query still runs, it just measures something adjacent. This is exactly why every answer ships with its query and sources — a glance tells you what was measured. Whatever the reading, it can only ever read.
  • An AI model processes your questions. We manage the provider, keys, and configuration; the privacy policy names who processes what.

If you have a security review to run or requirements beyond this, talk to us.

Last updated:

Privacy