How Datarelix Keeps Database Credentials Out of the AI Model
Find out which information is used to answer a question, where connection secrets are used, and what to check before granting access.
By the Datarelix Team · Published · Updated · Last verified
Datarelix keeps database credentials out of the AI model. Backend connection services use them to check access, discover schema information and execute queries. The model receives the question and relevant context, proposes a structured plan, and leaves validation and execution to those services.
For business users and analysts connecting a database, the practical questions are which information the model processes, which results the service stores and what access the connection permits. Database owners can use the same data flow when reviewing the credential and permissions.
What information is processed
| Information | How Datarelix uses it |
|---|---|
| Database password, token or key | Encrypted at rest and decrypted by backend connection services when needed; not supplied to the model |
| Table and column names, types, relationships and descriptions | Used as model context to interpret the question and generate a query |
| Your question and conversation | Used to plan the answer and interpret follow-up requests |
| Query results and run artifacts | Stored by Datarelix so you can view results and reopen previous work |
| Selected values from a single-row result | May be included in follow-up model context; values can include text as well as numbers |
| Database error messages | May be passed to the model to revise a failed query |
The follow-up context mechanism does not send multirow result tables to the model. This distinction does not mean that no result data reaches the model or that Datarelix keeps no copy of results. See the privacy policy for the broader handling of service data.
For example, a one-row answer containing customer_name and revenue may contribute selected values to the next question. Do not assume that a one-row result contains only anonymous aggregates.
From connection to answer
- Add a connection using access details approved by the database owner. Datarelix tests the connection and reads schema information available to that identity.
- Ask a question. The model receives the question and relevant context, then proposes a structured plan.
- Datarelix validates the plan and generated query. Its query service uses the saved connection to run the permitted read.
- Review the answer, SQL, source tables, returned row count and runtime. Saved results let you return to the work without reconstructing the conversation.
- Ask a follow-up. Conversation context can carry selected single-row values forward as described above.
The SQL and result make the calculation inspectable; they do not establish that the business definition is right. Use the answer verification guide to check periods, filters and totals.
Grant access for the report you need
For revenue by region, a reporting view with dates, regions and amounts may be sufficient. The connection does not need customer addresses just because those fields exist elsewhere in the database.
Ask the database owner to review the identity’s effective access, including inherited permissions. Restricting the tables is useful, but it does not necessarily restrict all functions, public privileges or metadata visibility. Engine-specific steps are in the connection guides.
Credentials can be rotated at the source and updated in the Datarelix connection. Datarelix does not rotate your database credentials for you. Test the connection after changing a secret so a scheduled business review does not begin with an access failure.
Separate authentication from model context
A tool can use a database credential without including it in a prompt. The distinction is where authentication happens and which component receives the secret. When evaluating another product, ask for that data flow rather than inferring it from the presence of a chat interface or a query-execution tool.
In Datarelix, the backend authenticates to the database. The model’s proposed query goes through read-only validation before execution, described with its threat model in read-only AI analytics controls. Keeping credentials out of model context reduces one exposure route, but it does not remove the need to protect connection storage, administrative access and error handling.
Do not paste a connection string, password or private key into a question to explain a connection problem. Use the connection form for secrets. Table descriptions are model inputs too; describe what a field means without adding access credentials (schema context and business definitions shows what a useful description contains).
What changes when a query fails
A failed query can produce a database error describing an unknown column, an incompatible type or another execution problem. That error can be supplied to the model so it can propose a revision. Each revised query passes through validation again, within retry limits.
An error is part of the data-flow review because it may identify tables or other context. It is not an instruction to give the model the connection secret. For troubleshooting, retain the failed and successful query information where available, and verify that the final result answers the original question.
Maintain and revoke the connection
Choose a credential owner before a report becomes routine; the security checklist has a decision-record template for that ownership. That person should know which database identity the connection uses, which reporting views it can read and where to update the secret after rotation.
| Change | Check before returning to reporting |
|---|---|
| Password or token rotation | Update the connection and test it with the new credential |
| New reporting table | Confirm visibility and the intended grants, rather than expanding access to everything |
| Changed employee responsibilities | Reassess the data the connected identity may read |
| Revoked database identity | Confirm source access is stopped; assess stored results separately |
Stopping database access and deleting saved information are different operations. A revoked credential prevents new authorised reads with that identity; it does not by itself erase results already stored by a service. Use the documented deletion process and confirm applicable retention details in the privacy policy.
Match source access to the reporting task
An analyst investigating order delays may need order identifiers and timestamps but no payment details. A business user preparing regional sales may need only an approved aggregate view. Grant the fields and rows necessary for that work, then test the actual query under the chosen identity.
Review inherited roles, public privileges, functions and source policies with the database owner. A role granted SELECT on three tables may still have other effective permissions. Per-engine setup belongs in the connection documentation, where those requirements can be checked together.
Check the working arrangement
Connections, conversations and dashboards are private to the account that creates them. A Team plan pools monthly questions across its seats; it does not by itself create shared dashboards or shared connections. Confirm any Enterprise identity requirements separately.
Avoid putting secrets into questions or schema descriptions: those are model inputs. Review the security overview with the database owner, then use the quickstart to connect an approved source and ask a narrow first question.