AI Analytics Security Checklist: 10 Vendor Questions

A conversational analytics tool asks for something few SaaS products do: a live connection to your database, with an AI model in the loop. This checklist is the security questionnaire for that decision — ten pass/fail questions, the domain probes behind them, and the artifacts worth demanding. It is vendor-neutral, so security, procurement, and data teams can evaluate the risk on evidence rather than on assurances.

Who should run this checklist

Security engineers and CISOs reviewing a conversational-analytics purchase. Procurement teams who need structured questions instead of a vendor-supplied deck. Data platform leads who will own the database connection. The checklist applies to any vendor in the category — including Datarelix — because it tests what the architecture enforces rather than what a vendor asserts.

Is it safe to connect an AI tool to your database?

Every product in this category has the same shape: a user asks a question in plain language, an AI model turns it into a query or analysis, and something executes that against a real database. The risk runs along two axes:

1. What flows to the model. Schema structure? Sample values? Raw result tables? The credentials themselves?
2. What the model can cause to execute. Can its output mutate data, reach the network, escape a row limit — or is every proposed action checked by a component the model cannot influence?

Separate policy from architecture as you go. A policy control is an instruction: “the model is told not to write data.” An architectural control is a missing path: “mutating statements have no execution route.” Instructions fail through model error and through deliberate prompt injection, which is why the second kind is what these questions look for. The full argument for architectural read-only enforcement is in read-only AI analytics; the equivalent argument for credentials is in how credentials stay out of the model.

Three terms: the executed query is the literal statement that ran, not a paraphrase; a run record is the stored, reopenable trail of one question — what was asked, planned, executed, and returned; a scoped credential is a database user with read access to only the schemas you choose to expose.

Ten critical pass/fail questions

Put these to every vendor in the first call; treat any fail as a stop until it is resolved in writing.

#	Question	What a pass looks like
1	Can you show the exact executed query with every answer?	The literal query text, source tables, and row count ship with every answer — visible in the product, not available on request.
2	Is write access impossible by architecture rather than policy?	Statements are parsed and validated by a component the model cannot influence; mutations have no execution path. Not “the model is instructed to only read.”
3	Where do database credentials live, and does the model ever receive them?	Credentials are held by an execution component, encrypted at rest, decrypted only to run a query — never in model context.
4	What exactly is sent to the AI model?	A precise enumeration (for example: the question plus schema structure — names, types, keys), edge cases included.
5	Is generated analysis code isolated from the network?	Egress blocked at the network layer, with hard resource caps — not a code check, not a prompt rule.
6	How are accounts isolated from each other?	A named mechanism — scoping enforced on every query, ideally backstopped at the database layer — not “logical separation.”
7	Can we trial with a scoped read-only credential?	The vendor encourages it and documents the least-privilege setup.
8	What is recorded per run, and can we review it later?	Question, plan, executed statements, and results — reopenable from history.
9	How are failures and retries handled?	Retries are bounded, and every retry passes through the same validation as the first attempt — never a bypass.
10	Can you demonstrate all of this live?	A working session on a question you choose, showing the evidence in the product — not a slide describing it.

Question 1 is the anchor: a system that shows its executed query makes the other claims checkable by your own team; one that hides it makes every answer a matter of trust. The reviewing habit this enables is covered in how to verify AI data answers.

Detailed questions by domain

Use these in follow-up security calls.

Database identity and permissions

• What database principal do queries run as — a shared service account, or the signed-in user’s own database permissions?
• Can a connection be scoped to specific schemas or datasets rather than the whole database?
• What are the minimum grants required to connect?
• Do you document a least-privilege setup with a read-only database user?
• If the connected credential has broader access than intended, what limits still apply on your side?

Query validation and execution

• Is generated SQL parsed into a full syntax tree, or matched against keywords and patterns?
• Which statement types are permitted — an allowlist of reads, or a blocklist of known-bad commands?
• For non-SQL query languages you support (KQL, ES|QL, and similar), is there a dedicated validator per language?
• Are row limits applied automatically to every query?
• Does the query execute in a service isolated from the component that calls the model?
• Can validation be weakened or disabled per connection, per user, or by support staff?

Model data flow

• What is in the model’s context: the question, schema structure, sample values, previous results?
• Are raw query results ever passed back to the model — and if any result value can enter follow-up context, which ones, exactly?
• Which model provider processes requests, and under what data-use terms — is anything used for training?
• What does the model provider retain, and for how long?
• Are schema descriptions curated by users, or sampled automatically from the data?

Credential handling

• How are credentials encrypted at rest — is there application-level encryption on top of storage encryption?
• Which component decrypts them, at what moment, and for how long do they exist in plaintext memory?
• Can credentials appear in logs, error messages, or support tooling?
• What is the rotation procedure, and what breaks when we rotate?
• Do you support identity-based, per-user authentication as an alternative to stored database passwords?

Isolation of generated code

• Does the product execute model-generated code at all — and if so, what language, and where?
• Is network egress blocked at the network layer, or prevented only in code?
• What CPU, memory, and time caps apply to a sandboxed run?
• Can sandboxed code reach the database directly, or only the result sets handed to it?
• What happens when sandboxed code crashes or exceeds its caps?

Run records and reviewability

• What does a run record contain — question, plan, executed statements, results?
• Can a past run be reopened and its executed query read verbatim?
• How long are run records and stored result sets retained, and can they be deleted on request?
• Who at the vendor can access run records, and under what controls?
• Is the record complete enough that our team could reproduce the answer independently?

Account access and authentication

• Which identity providers are supported for sign-in, and can we require a specific one?
• Is automated provisioning and deprovisioning (SCIM) available if our organization requires it?
• What roles or permission levels exist within an account today — and which are roadmap items rather than shipped features?
• Is audit logging of administrative actions (connections created, credentials changed, sign-ins) available to our security team?
• How is one account’s data isolated from another’s — application checks alone, or enforced at the database layer as well?

Operations

• What are your incident-notification commitments, and are they in the contract?
• Is your subprocessor list published, and how are changes communicated?
• In which regions is customer data processed and stored?
• Is there a vulnerability-disclosure channel, and do you commission independent security testing?
• Will you complete our security questionnaire, and is third-party attestation evidence available under NDA?
• What is deleted when we offboard, and how is deletion confirmed?

Artifacts to request

Request these four before contract:

1. A written architecture and data-flow description — specific enough that your team can draw the diagram from it.
2. A live demonstration of the evidence. Ask your own question in the vendor’s product and watch where the executed query, source tables, and row count appear.
3. Completed security questionnaire responses. Vague answers in writing predict vague answers during an incident.
4. A trial with a scoped credential. Create a read-only database user limited to a non-sensitive schema and run the evaluation yourself. Illustrative setup on a fictional retail schema:

-- Illustrative (PostgreSQL, fictional demo schema): a scoped read-only trial user
CREATE ROLE analytics_trial LOGIN PASSWORD '<generated>';
GRANT USAGE ON SCHEMA sales TO analytics_trial;
GRANT SELECT ON sales.orders, sales.customers, sales.order_items TO analytics_trial;

A simple scoring model

Keep scoring blunt:

• The ten critical questions are pass/fail. Any fail is a stop: the vendor resolves it in writing, or the evaluation ends.
• Score each domain satisfactory or unsatisfactory on the specificity and consistency of answers. How many satisfactory domains you require depends on your data’s sensitivity — but fix the number before the calls start.
• Weight artifacts over answers. One live demonstration of a boundary outweighs a page of prose about it.

Red flags

Red flag	What it usually means
The vendor cannot show the executed query behind an answer	Answers are unverifiable by design; every result is a trust exercise.
”Read-only” is enforced by prompt instructions	The guarantee fails exactly when the model misbehaves — the case it exists for.
Credentials are embedded in prompts or model context	Connection details are one injection away from extraction.
Answers stay at “we’re secure” under specific questioning	No mechanism behind the adjective — assume the architecture matches the answer.
Refusal to trial with a scoped read-only credential	The vendor wants more access than the evaluation needs, at the moment trust is lowest.

Run this checklist against Datarelix

Our answers are on the security page: what is sent to the model, what is stored, what is never done, and how each boundary is enforced. Rather than restate them here, run the evaluation directly:

1. Read that page against the ten critical questions.
2. Start a trial with a scoped read-only credential, following the connection guides for your engine. Ask a question, then open the run and read its evidence — every run stays reopenable from history.
3. Send your security questionnaire, compliance-status questions, or DPA requests through the contact page.

What this checklist does not test

• This checklist evaluates security architecture, not answer quality. A vendor can pass every question and still misread your schema’s business logic. Evaluate correctness separately, with your own questions on your own data.
• Pass/fail flattens nuance. Some failures are gaps a vendor can close quickly; distinguish “cannot” from “does not yet,” and get the latter in writing with a date.
• Answers age. Architectures and subprocessors change — re-run the critical ten at renewal, not just at purchase.
• It does not replace legal review. DPAs, liability, and data-transfer terms are legal work this checklist does not attempt.
• Regulated data raises the bar. Specific regulatory obligations on the connected data come before and on top of anything here.
• If your policy prohibits any third-party model processing of schema metadata, no vendor answer changes that — the category itself may not fit, and it is better to establish that on day one.

Scope and provenance

Product statements describe Datarelix as shipped in August 2026; the security page is canonical. The checklist itself is vendor-neutral and makes no claims about any other vendor. The SQL example uses a fictional retail demo schema and is illustrative only. The ten questions and the scoring model are ours; this guide cites no external sources.