---
title: "How Datarelix Keeps Database Credentials Out of the AI Model"
description: "Where the database password lives when an AI tool queries your data: the data flow, what the model receives, who executes the query, and what the boundary does not cover."
canonical: https://datarelix.ai/resources/guides/credentials-away-from-the-model/
publishDate: 2026-08-07
updatedDate: 2026-08-17
lastVerified: 2026-08-17
---

# How Datarelix Keeps Database Credentials Out of the AI Model

Datarelix keeps database credentials out of the AI model by never placing them in the model's context. The model receives your question and the structure of your schema, and returns a structured plan. It executes nothing. The credential is encrypted at rest, held by a separate execution layer, and decrypted only at the moment a query executes inside an isolated query service. A prompt cannot extract a secret that was never there.

## Who needs this answer

Security engineers and platform teams reviewing a conversational-analytics vendor before any database goes near it. Database administrators asked to provision a connection and deciding what to grant. Anyone who has read "the AI connects to your database" on a product page and wants to know precisely which component holds the password — because that one fact sets the shape of the threat model.

## Two ways to wire an AI model to a database

The naive design puts the model in the loop: it holds a connection string in its context, or it can call a "run this query" function directly. In that design the credential is part of the model's world, and every defense against a misleading instruction — in a prompt, in a document, even in a column description — becomes load-bearing, because a model that can be steered by its input can be steered into revealing or misusing what it holds.

The design Datarelix uses separates proposing from executing. The model proposes: it returns a structured plan describing what should run. A separate execution layer decides whether that plan is valid, runs each step itself, and records what happened. In this design the credential lives entirely on the execution side of the line. The same separation is what enforces read-only access — the case for that half of the boundary is in [read-only AI analytics](/resources/guides/read-only-ai-analytics/). This guide covers the credential half.

## The data flow, step by step

1. **You ask a question in plain English.** The service assembles the model's context: your question, the conversation so far, and the structure of the connected schema — table and column names, types, keys, and any descriptions you have curated. Structure only: no sample values, no rows, and no connection details of any kind.
2. **The model returns a structured plan.** The plan describes the steps to take, including the query to run. The model itself executes nothing — it holds no connection, no credential, and no function that reaches your database.
3. **The execution layer validates the plan.** The plan is checked against a strict schema before anything runs, and generated statements are parsed into a syntax tree and rejected unless they are reads — [how the validator works](/resources/guides/read-only-ai-analytics/). Automatic row limits are applied to every query.
4. **An isolated query service runs the query.** This service is the only component that holds the database connection. The credential is decrypted at this moment, used to execute the validated query, and the result is captured. The model plays no part in this step.
5. **The answer returns to you, with its evidence.** The result carries the query that ran, the tables it read, the row count, and the runtime — [what each of the four tells you](/resources/guides/what-is-verifiable-conversational-analytics/). Result tables are not passed back to the model. The whole run is recorded step by step and reopenable from history, which is what makes the checking habit in [how to verify AI data answers](/resources/guides/verify-ai-data-answers/) practical.

## Does the AI see my data? What the model receives

| The model receives | The model never receives |
|---|---|
| Your question, as you typed it | Connection credentials: passwords, tokens, keys |
| Schema structure: table and column names, types, keys, and curated descriptions — structure only, no sample values | Hostnames, ports, or any other connection detail |
| Conversation context from the current chat | Raw result tables from your queries |
| A single-row answer value, carried into follow-up context (see below) | Copies of your tables — your data is never replicated into the model's context |

One nuance, stated plainly: when an answer is a single value — one revenue figure, one count — that value can be carried into the follow-up conversation so that "and how does that compare to last quarter?" makes sense. Questions, schema structure, and single answer values flow toward the model; credentials and result tables do not.

## Where the secrets actually live

When you create a connection, the credential is encrypted at rest — application-level encryption on top of encrypted storage — and held on the execution side of the boundary. It is decrypted only at the moment a query executes, inside the isolated query service, and only for that execution.

You can replace a credential at any time: rotate the password or token on the database side on whatever schedule your team runs, then update the connection with the new secret. Datarelix does not rotate credentials for you.

## Connections are private to the account that created them

Connections, runs, and dashboards are private to the account that created them. A connection you create cannot be seen or used from any other account, and neither can the runs or dashboards built on it. There is no mechanism that would move a credential — or anything derived from it — across an account boundary.

## When a query fails

Real schemas produce real errors: a misspelled column, a type mismatch, a dialect quirk. When a query fails, the database's error message goes back to the model, which revises the query and retries automatically, within strict limits, each attempt passing through the same read-only validation as the first. Nothing about failure changes the credential boundary. A retry is a new plan submitted to the same execution layer and the same validation: the model sees the error text, never the connection that produced it.

## Your side of the boundary: grant a scoped, read-only credential

Datarelix can read what the connected credential can read, and nothing more. Read-only validation and automatic row limits hold regardless of what you grant — but a scoped credential turns one layer of protection into two. Connect with a database user that can read only the schemas you want to ask about.

On PostgreSQL, against a fictional retailer's demo schema, that grant looks like this (illustrative, not captured from a live system):

```sql
CREATE ROLE datarelix_reader LOGIN PASSWORD '<generated-secret>';
GRANT USAGE ON SCHEMA demo_retail TO datarelix_reader;
GRANT SELECT ON demo_retail.customers,
               demo_retail.orders,
               demo_retail.order_items
TO datarelix_reader;
```

This user can read three tables and do nothing else — no writes, no DDL, no visibility into other schemas. On Azure SQL, Databricks, and Kusto, Enterprise arrangements can go further: connections can run with the signed-in user's own database permissions (per-user On-Behalf-Of), so what each person can ask is bounded by what their own account can already read. Per-engine setup steps, including the read-only-user pattern for each supported engine, are in the [connection guides](https://docs.datarelix.ai/guides/connections/).

## What this boundary does not cover

The boundary covers credentials and result tables, not the question itself. Your questions, schema structure, and single answer values are processed by the AI model behind the service; we manage the provider, the keys, and the configuration, and the [privacy policy](/privacy/) documents the providers involved in operating the service. If your requirement is that no external model processes even table and column names, a hosted service of this design is the wrong tool.

Column names and curated descriptions sometimes encode institutional knowledge, so write descriptions knowing the model reads them. The credential boundary also does not compensate for over-broad grants: a credential that can read every schema makes every schema askable, so scope it as shown above.

Accounts are isolated: connections, runs, and dashboards stay with the account that created them ([account isolation](/security/)). In practice that means each person connects with their own credential, or with their own permissions via On-Behalf-Of on the engines that support it. Handing an analysis to a teammate means exporting it.

## Notes and provenance

Product statements describe Datarelix as shipped in August 2026; the [security page](/security/) is canonical. The SQL example uses a fictional retailer's demo schema and is illustrative. The two-designs framing is ours, and no external citations are used.

## Send a security questionnaire

If you are evaluating Datarelix for a security review, send questionnaires and compliance-status requests through the [contact page](/contact/). The [vendor-neutral security checklist](/resources/guides/conversational-analytics-security-checklist/) lists the artifacts worth asking any vendor in this category to produce.