AI Analytics Security Checklist: 10 Vendor Questions

If you want an AI tool to report on sales or operations data, first agree on the information it may read and where the answers may be stored. A useful evaluation produces an access decision and evidence for that decision, not a collection of reassuring adjectives.

Datarelix publishes this AI analytics security checklist and sells an analytics product. The questions apply to our service and to alternatives; they are not a certification or legal assessment.

Essential checks before connecting data

Check	Evidence to request	Decision to record
Access to the source	Effective roles, table or view scope, row and column policies	Which information may this user query?
Credentials	Storage, decryption and rotation workflow; whether secrets enter model inputs	Who provisions and maintains access?
Model inputs	Examples covering questions, schema, descriptions, errors and follow-ups	Which sensitive information could reach a model provider?
Stored information	Result storage, logs, retention and deletion process	Is the proposed handling acceptable?
Query execution	Validation rules, allowed statements, limits and failure behavior	Are the permitted actions appropriate?
Answer review	A sample showing the query, source, result and execution details	Can someone check the calculation before relying on it?
Account access	Login controls and access to saved conversations or reports	Who can see or reuse the work?
Compute and cost	Query-job limits, timeouts and billing responsibilities	What controls the cost of repeated reads?
Generated analysis	Network and resource controls for generated code	Where can analysis code send information?
Operational ownership	Support route and a procedure to revoke access	Who acts when access or a result is wrong?

Ask for examples at the boundaries. A statement that credentials stay outside the model says nothing about result values. A statement that queries are read-only says nothing about their cost or whether the user should see every readable field. For Datarelix, the security page states what flows where and what is stored.

Requirements that depend on your environment

Some buyers need SSO, per-user database permissions, a private network route, a contractual residency commitment, audit exports or a specific certification. Record these as requirements when they apply to your organisation. Confirm availability for the exact plan, connector, deployment and region; do not infer it from a general security page.

For a single analyst using an approved reporting view, a shared enterprise identity system may not be the deciding factor. For a regulated team handling personal records, retention, access review and contractual requirements may determine whether a trial can start. Your security or legal reviewer should define those requirements.

A small evaluation exercise

Use approved sample data and ask for monthly revenue with refunds excluded. Keep a reference total prepared independently. Review the generated query for the period, status filter and join keys, then compare the result; verify AI-generated SQL and results lists those checks.

Next, use a test identity whose permissions exclude a sensitive table and confirm that the tool cannot read it. Run access checks only in an authorised test setting. Save the observed result with the identity and configuration used; one successful check is evidence for that setup, not proof of every control.

Finally, reopen the saved answer. Confirm who can access it and how it can be deleted. A product that connects directly to a database can still store the returned results.

Detailed questions by domain

Use the relevant domains in follow-up security calls. These are questions to establish requirements and evidence; an unavailable feature is not automatically a failed evaluation when your environment does not require it.

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?

Datarelix’s answers, with the threat model behind them, are in read-only AI analytics controls.

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?

For Datarelix, see how database credentials stay out of the AI model.

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?

The security and data-handling reference describes what a Datarelix run record contains.

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?

Evidence and a decision record

Request a data-flow description that distinguishes source data, model inputs, stored results and connection secrets. Pair written answers with a demonstration using an approved test dataset. The query displayed in a demonstration can support review of that calculation; it cannot establish how credentials are encrypted or prove account isolation.

Keep a short record for each requirement:

Field	Example
Requirement	The trial identity can read approved sales views only
Evidence	Grants reviewed by the database owner and an access test
Configuration	Connector, database role, product plan and test date
Unresolved point	Whether a newly added view receives the intended grant
Owner and next review	Database owner; review when reporting views change

Classify an answer as documented, demonstrated for the tested setup, unresolved or outside your requirements. A product demonstration and contractual evidence answer different questions. Avoid a single overall score that hides an unresolved requirement your organisation considers essential.

Missing detail is a reason to request evidence. A vendor saying “read-only” without explaining enforcement, omitting result storage from its data flow, or giving inconsistent retention answers leaves a specific gap to resolve. Record the gap instead of inferring an undocumented capability or vulnerability.

Revisit applicable requirements when the connector, model provider, authentication method or deployment changes. Also test answer quality separately: correct access controls do not establish the correct definition of revenue, the correct join or a complete source load.

Datarelix facts to include in your review

Datarelix validates generated reads before execution and keeps database credentials out of model context. It stores results and run artifacts. Questions, schema information and descriptions are model inputs; selected single-row result values and database errors can also enter context. These qualifications matter when deciding which source to connect.

Saved connections, conversations and dashboards are private to their creator’s account. Team pools monthly questions across seats and does not itself provide shared dashboards. Review data handling, read-only controls and the privacy policy alongside any requirements specific to your organisation.

Record the source, review date, unresolved requirement and responsible person for each decision. If the access fits, begin with the quickstart and one report whose expected result you can check.