Read-Only AI Analytics: Architecture, Controls, and Threat Model
Before connecting a database, check which reads are allowed, which actions are blocked, and who can see the resulting answers.
By the Datarelix Team · Published · Updated · Last verified
For a sales report, an analytics tool needs to read orders and calculate totals. It does not need permission to delete orders, change prices, or create database users. Read-only access limits those actions, but it still permits reading sensitive information and running queries that consume database resources.
This guide helps business users and analysts understand the access their reporting needs, and gives database owners and security reviewers the detail needed to evaluate it. Datarelix provides the product examples; the checklist is not an independent certification.
Start with the database identity
Use a dedicated identity scoped to the tables or reporting views the user needs. Ask the database owner to review inherited roles, public privileges, callable functions, and row-level policies as well as direct table grants. A short list of SELECT grants alone does not establish the identity’s complete effective permissions.
For example, PostgreSQL grants some privileges to PUBLIC by default, including database TEMPORARY and function EXECUTE. Review these in the context of the existing database; changing public privileges can affect other applications. PostgreSQL privilege documentation
Use the connection documentation for setup. For Enterprise connections that support per-user database authentication, confirm the specific connector and identity arrangement with Datarelix before relying on it.
What Datarelix checks before execution
The model proposes a structured plan rather than executing anything itself; how text-to-SQL generates database queries follows one question through that flow. Datarelix validates the plan and checks generated queries before its query service executes them. SQL validation parses the statement; KQL and ES|QL use their own validation rules. Result limits constrain returned rows. They do not, by themselves, limit the amount of data the database scans.
One useful review case is a write nested inside an apparently readable statement. The following is a deliberately unsafe example, not a query to run:
WITH removed AS (
DELETE FROM orders WHERE status = 'test' RETURNING order_id
)
SELECT COUNT(*) FROM removed;
The outer SELECT does not make the nested DELETE a read. Datarelix’s SQL validation rejects this kind of modifying statement. Database permissions remain a separate control whose coverage depends on the role you configure.
Match each concern to a control and a remaining question
| Concern | Relevant Datarelix control | What to review as well |
|---|---|---|
| Generated SQL attempts a write | Read-only query validation | Effective database privileges, including functions and inherited roles |
| A permitted read exposes sensitive fields | Connection access scope | Which tables, columns and rows this identity can read |
| Generated Python tries to send data elsewhere | Analysis sandbox with network egress blocked and resource limits | The wider data flow outside that sandbox |
| A prompt requests a database password | Credentials are kept out of model context | Who can manage the connection and rotate its secret |
| A user requests another account’s saved work | Account scoping and database access policies | Identity configuration and the intended sharing model |
| A read consumes substantial compute | Connector timeouts and result limits | Query plans, warehouse settings and billing controls |
These controls address different concerns. A CPU limit, for example, is not a substitute for a network restriction, and encryption at rest does not determine which service may decrypt a credential.
Review what leaves the source database
Datarelix stores query results and run artifacts so users can reopen their work. The model receives questions, schema information, descriptions and conversation context. Follow-up context can include selected values from a single-row result, including text. Database error text can also be used to revise a failed query. Multirow result tables are not included through that follow-up context mechanism.
Database credentials are encrypted at rest and used by backend connection services for connection checks, schema discovery and query execution. They are not supplied to the model. See the credential and data-flow guide, the security overview and the privacy policy when assessing information handling.
The threat model
These five scenarios are a starting point for review. Add risks specific to your data and deployment; this is not an exhaustive threat model.
| # | Threat | Vector | What failure looks like |
|---|---|---|---|
| T1 | Prompt-injection-driven write attempt | Adversarial text in a question, or in curated table descriptions, steers the model into proposing a mutating statement | The system executes a write the user never intended |
| T2 | Destructive SQL | The model emits DROP, DELETE, TRUNCATE, or DDL — hallucinated or induced | Data loss or schema damage in the connected database |
| T3 | Exfiltration via generated analysis code | Generated Python tries to send query results to an external host | Result data leaves the environment over the network |
| T4 | Credential exposure to the model | A crafted prompt coaxes connection details into a model response | Connection strings or secrets surface in conversation |
| T5 | Cross-account access | A request from one account reaches another account’s connections, runs, or dashboards | One customer’s data is visible to another |
T1 and T2 differ in intent — one adversarial, one a model error — but converge on the same choke point.
Why the controls need separate review
Query validation and database permissions examine different things. The validator checks generated syntax and permitted operations. The database applies effective privileges for the connected identity, including inherited roles and policies. A mistake in either configuration deserves investigation; calling them two layers does not establish that their failure modes are independent.
A SELECT can still read more information than a report needs, perform an expensive join, or call a function. Review callable functions and their permissions with the database owner. For large sources, inspect source-side query history and execution plans alongside the application’s returned-row limit.
Plan validation separates a proposed action from its execution. It restricts what a generated plan can request, but prompt injection can still influence which permitted read is proposed or how a question is interpreted. A plan record supports investigation; recording an action does not prevent it.
Generated code and the wider data flow
When a question uses generated Python, the hosted analysis sandbox blocks network egress and imposes resource limits. Review those controls for that execution environment. CPU or memory caps limit resource use; they do not independently block disclosure.
The sandbox is only part of the system. Results also travel through the service to the user and are stored with run artifacts. Questions, schema descriptions, database error text and selected single-row values may be processed by the model. A network restriction on analysis code does not mean no information leaves the source database or reaches a model provider.
Ordinary charts do not require generated Python. When reviewing a workflow, establish which execution path it uses rather than assuming every chart ran sandboxed code. The Python documentation describes the analysis environment.
Review a representative reporting workflow
Choose an approved test dataset and an identity whose access matches the proposed use. A business user should identify the report and sensitive fields it needs; an analyst should inspect the generated query; the database owner should confirm effective permissions and source-side limits.
- Ask a question with a known answer and confirm the tables, filters and returned result.
- In the authorised test environment, check a table the identity is not permitted to read. Record the permission outcome and configuration.
- Review the handling of a failed query and whether revised SQL passes validation again.
- Reopen the answer and establish which account can access the stored result.
- Document revocation and credential rotation with the person who manages the connection.
Successful tests support conclusions about that configuration. They do not prove resistance to every input or replace a broader security assessment. Keep evidence for the controls your use case depends on, and use the security checklist to track unresolved requirements.
Decide whether the access fits the work
For a monthly sales summary, a view containing approved sales fields may be enough. For an investigation involving customer contact details, the same access decision needs a separate review. Read-only status does not settle either decision and does not establish that an answer is correct.
Ask one representative reporting question, inspect the source and result, and have a SQL reviewer check the calculation. Use the security checklist to record the access and evidence your organisation requires.