AskYourDatabase Security and Data Flow

AskYourDatabase's data handling depends on the product and deployment you choose. Desktop connects to your database from your computer; the hosted Website Chatbot connects through server-side services; a private deployment hosts the application in your environment. Each can still use an external AI model. Review the model destination and the information included in requests as well as where SQL runs.

Content reviewed September 26, 2026. This page describes product boundaries and evaluation steps. It is not a security audit report or a guarantee about every version, connector, or customer configuration. Contractual terms and your approved deployment configuration determine the applicable commitments.

Product data-flow comparison

The Desktop setup guide explains local connectivity. For Enterprise hosting, use the private deployment guide to choose application and model locations separately. Installing software locally does not establish offline inference.

What can be included in an AI request?

Natural-language database analysis can use a user's question, earlier messages, schema and column descriptions, training examples, generated SQL, and selected query or tool results. Follow-up explanations may require row values. The source database can stay in place while information from it is sent for inference.

For example, a monthly revenue question might only require aggregated totals, whereas an invoice investigation may return names or account-level details. Decide what the permitted reporting views expose before connecting them. A shortened result can still contain sensitive data; truncation is not anonymization.

Provider processing, retention, training use, and hosting location depend on the actual service, account, and agreement. Confirm those terms for the configured route. Do not infer zero retention or a particular processor solely from a model label. The sub-processors page is a starting reference; request the current applicable processor list and agreement during an Enterprise review.

Credentials, history, and results

Desktop's documented connection workflow keeps database credentials on the local computer. Keep credentials in the connection configuration, not in chat messages or training examples. Local device access and exported files still require protection.

For the hosted Chatbot, stored database connection secrets are encrypted by the application and decrypted when needed to connect. Encryption at rest does not remove the service's ability to use those credentials, and it does not replace a limited database account.

Hosted conversations and tool-result messages can be saved in application history. Query-result content included in those messages may therefore be retained; do not assume that only the user's question is stored. For any deployment, agree retention and deletion handling for conversation records, logs, backups, exports, and optional analysis files. Contact the team for data-handling or deletion requests under your applicable agreement.

Database transport and access boundaries

Database encryption and certificate verification depend on the connector, database server, and configuration. Current connectors include compatibility behavior that can permit connections without verified TLS. Do not assume every successful database connection is encrypted or verifies the server certificate. Have the deployment team validate the specific connection against your transport requirements before allowing sensitive data. If it does not meet policy, resolve the configuration or supported connection path; do not disable protections to make the test pass.

For a reporting workflow:

1. Use a database account limited to read-only access on approved tables or views. Avoid owner or administrator credentials.
2. Permit only the required network source and destination. Network allowlisting does not replace database authorization.
3. Configure the product's table and row access controls, then test the actual authenticated user and session path.
4. Test an unauthorized record request and a write attempt using disposable test data. Check database-side enforcement rather than relying on an AI refusal.
5. Review the information that reaches model messages, history, and exports, including follow-up and error paths.

Generated SQL and prompt instructions are not security boundaries. OWASP's prompt-injection guidance (opens in a new tab) recommends constraining privileges outside the language model. Read-only access prevents permitted-account writes but can still expose every readable row; scope the readable data too.

The PostgreSQL workflow, SQL Server workflow, and embedded chatbot guide provide concrete connection, result-validation, and user-isolation considerations.

Private deployment and security review

Private application hosting can give your team control over application infrastructure and stored records. If it calls an external model, information in the model requests still leaves that infrastructure. A self-hosted model requires a separately agreed endpoint, capacity plan, and full dependency review; see the deployment acceptance checks.

Before approval, record the application version, database privileges, model/provider destinations, transport configuration, permitted data categories, retained records, and operational owners. Test those assumptions with synthetic data in an authorized environment. These are evaluation steps, not claims of a completed penetration test or certification.

Audit evidence and procurement

Request the current security documentation and any available audit report through Enterprise contact. Verify the report's period, scope, covered service, and exceptions. This page does not assert that a SOC 2 Type 2 report has been issued; a previously published target date is not proof of a completed audit.

For the next step, compare product plans and select Desktop, hosted Chatbot, or a private evaluation based on the data path your organization can approve.

Frequently asked questions