Skip to content
security

The model plans. It executes nothing.

The AI model holds no credentials and runs no queries. A separate execution layer validates every step, enforces read-only access, and records the whole run so you can check it.

Boundaries enforced in the architecture

None of these depend on prompting the model to behave. They hold even when it doesn’t.

  • 01

    The model executes nothing.

    It returns a structured plan. A separate execution layer checks that plan against a strict schema and runs each step itself — so a hallucinated action has no path to your database or the network.

  • 02

    Every query is validated before it runs.

    SQL is parsed into a full syntax tree — not pattern-matched — and rejected unless it is a read: SELECT, CTEs, and set operations only. KQL and ES|QL go through dedicated validators that block every mutating or administrative command. Row limits are applied to every query.

  • 03

    Analysis code has no internet.

    Generated Python runs in an isolated sandbox with hard CPU and memory caps. Outbound traffic is blocked at the network layer — an egress firewall, not a code-level check.

  • 04

    Credentials never reach the model.

    Connection credentials are encrypted at rest and decrypted only at the moment a query executes. The model sees your question and schema metadata — never connection details, never your tables.

  • 05

    Every account is isolated.

    Every record is scoped to your account in every query, backstopped by database row-level security. Runs, connections, and dashboards are visible only to the account that created them.

  • 06

    Every run is recorded, step by step.

    The question, the model’s plan, what actually executed, and what came back — reopenable from your history, so any answer can be audited after the fact.

The guide to read-only AI analytics: architecture, controls, and threat model walks through each boundary and the threats it stops.

What flows where

  1. 01

    Question

    Goes to the model with schema metadata: table and column names, types, keys, and any descriptions you’ve curated. Raw query results are never passed back to the model.

  2. 02

    Plan

    The model returns a structured plan. The execution layer validates it against a strict schema before anything runs.

  3. 03

    Execution

    Each step runs in an isolated service: read-only query execution against your database, or Python in the no-network sandbox.

  4. 04

    Result

    Tables and charts come back to you and are stored with the run trace. Only the result set for the question you asked is stored — your tables are never copied.

For the full data-flow walkthrough — what the model receives, who holds the connection, and where secrets live — see how Datarelix keeps database credentials out of the AI model.

What we store — and what we don’t do

Stored

  • Account basics: name, email, sign-in method.
  • Connection metadata: host, port, dialect, schema scope.
  • Connection credentials — encrypted at rest, decrypted only to execute a query.
  • Run traces: the question, the plan, the executed query, and the result set for that question.
  • Aggregated usage telemetry. No row contents.

Never done

  • We do not copy your tables to our infrastructure.
  • We do not pass raw query results to the model.
  • We do not give the model credentials, or let it call your database directly.
  • We do not let analysis code reach the internet.
  • We do not share your data with third parties beyond the model provider and the cloud infrastructure that runs the service.

The service runs on Google Cloud. Traffic is encrypted in transit, storage is encrypted at rest, and connection credentials carry an additional layer of application-level encryption.

Authentication and access

Sign-in

Google, Microsoft (single- or multi-tenant, with optional tenant allowlisting), or email and password with verification and reset.

Your permissions, per user

On Azure SQL, Databricks, and Kusto, connections can run with the signed-in user’s own database permissions (per-user On-Behalf-Of) instead of a shared service account.

Least privilege, recommended

Connect with a read-only database user scoped to the schemas you want to ask about. Read-only is enforced at the query layer either way — a scoped user makes it defense in depth.

Known limits

Where the system can still get an answer wrong, and the control that contains it.

  • If a question is ambiguous

    The model can read an ambiguous question differently than you meant it — the query runs, but measures something slightly different. Every answer shows its query and sources, so a glance tells you exactly what was measured. And whatever the interpretation, it can only ever read data — never change it.

  • Access follows what you connect

    Datarelix can read what the connected credential can read — and nothing more. The guardrails hold either way: read-only validation on every statement, automatic row limits, and no write path at all. Connecting a scoped, read-only database user adds one more layer on top, and our guides show how.

  • An AI model processes your questions

    Your question and schema metadata are processed by the AI model behind the service. We manage the provider, the keys, and the configuration — there is nothing for you to set up, and your tables are not part of that exchange.

Questions, reviews, and reports

Security questionnaires, SOC 2 status, and DPAs go through the contact page. Vulnerability reports go straight to support@datarelix.ai. If you are running an evaluation, start from the vendor-neutral AI analytics security checklist.

See the guardrails for yourself.

Connect a database, ask a question, and read the query that ran.

Start free trial Talk to us

14 days free · no credit card required