Before you give any external tool access to your database, there are a handful of questions worth asking. Not out of paranoia — but because the answers reveal how seriously the tool takes security, and what the realistic blast radius is if something goes wrong.
This checklist applies to any tool: BI platforms, query assistants, analytics services, data visualization tools, or anything else that needs a database connection.
1. Does it enforce read-only access?
What to ask: Does the tool guarantee that only SELECT queries will ever run against your database? Is this enforced at the application layer, not just at the UI?
Why it matters: A tool that only presents a read-only interface at the UI level is not the same as one that validates queries before execution. If there’s a bug in the query generation, or if the tool has a mode that allows writes for “power users,” the UI guarantee may not hold.
What a good answer looks like: “We validate all generated queries and reject anything that isn’t a SELECT. INSERT, UPDATE, DELETE, DROP, ALTER, and TRUNCATE are blocked at the application layer before the query reaches your database.”
What to do regardless: Create a read-only database user. Application-level enforcement is a second layer; database-level permissions are the foundation.
2. How are database credentials stored?
What to ask: How does the tool store the database password I provide? Is it encrypted? What algorithm and key size? Where is the encryption key stored?
Why it matters: Database credentials are the most sensitive thing you share with a tool. If they’re stored in plain text — or encrypted but with the key stored alongside them — a breach of the tool’s database exposes your credentials directly.
What a good answer looks like: “Credentials are encrypted with AES-256. The encryption key is stored in a separate secrets management system, isolated from the application database. Plain-text credentials are never persisted.”
Red flags: Vague answers like “we store your credentials securely” without specifics. No mention of key separation.
3. Does the tool send your schema to a third party?
What to ask: When the tool reads your database schema, where does that information go? Is it sent to an AI provider? Is it retained? Is it used for training?
Why it matters: Your schema describes your data model — table names, column names, relationships. This reveals business logic and data inventory even without any row-level data. See what your schema exposes.
What a good answer looks like: “Schema context is sent to our LLM provider as part of generating queries. It is not retained after the session, not used for model training, and not accessible across accounts.”
What to do: Connect with a read-only user scoped to only the tables relevant to your use case. Limit schema exposure to what’s necessary.
4. Is there an audit log?
What to ask: Can I see a log of every query that was executed through the tool? Does it include who ran it, when, and what the exact SQL was?
Why it matters: Even if queries are read-only, you want visibility into what data was accessed and by whom. This matters for compliance, for investigating data incidents, and for understanding usage patterns.
What a good answer looks like: “Every query is logged with the user, timestamp, generated SQL, and result row count. Logs are retained for [X] days and are available to account admins.”
What to do regardless: Enable query logging at the database level. See how to audit query history in PostgreSQL for the database-side controls.
5. What happens if the vendor is breached?
What to ask: If your servers were compromised tomorrow, what could an attacker get from my account?
Why it matters: This is the question that tests whether the answers to the previous questions are actually meaningful. A vendor can say “we encrypt credentials” — but if the breach also exposed the encryption keys, the encryption was ineffective.
What a good answer looks like: “An attacker who accessed our database would get encrypted credential values. The encryption keys are in a separate system with separate access controls. They would need to compromise both systems independently to obtain plain-text credentials.”
What is always true: No security measure is perfect. Your risk is reduced but not eliminated. This is why connecting with a read-only, scoped database user is so important — it limits the consequences of a breach to read access on specific tables, not full database control.
6. Can you revoke access instantly?
What to ask: If I need to disconnect the tool today, what do I do? How quickly does that take effect?
Why it matters: Offboarding a tool, responding to a security incident, or simply changing your mind should be fast and deterministic. You shouldn’t have to wait for a support ticket to revoke access.
What to do: Keep the database user password in your own records. If you need to revoke access immediately, change the password on the database side — this invalidates all connections regardless of what the tool has stored.
7. What is the network exposure?
What to ask: Does my database need to be publicly accessible to use this tool? Or does it support VPC peering, IP allowlisting, or private networking?
Why it matters: Publicly accessible databases are a significant attack surface. If your database is in a private VPC, connecting it to an external tool may require opening it to the public internet.
What a good answer looks like: “We support IP allowlisting so you can restrict database access to our egress IP ranges. We can also provide documentation for VPC peering if you’re on AWS or GCP.”
What to do: If the tool requires public access, restrict it to the tool’s specific egress IPs. If your security posture doesn’t allow public database access, look for tools that support private networking options.
The short version
Before connecting any tool to your production database:
- Create a dedicated read-only database user (not root, not your app user)
- Scope the user to only the tables the tool needs
- Confirm the tool enforces read-only at the application layer
- Understand how credentials are encrypted and where the key is stored
- Enable database-level query logging
- Know how to revoke access instantly if needed
- Understand the network exposure required
These questions aren’t hard to ask. The answers tell you a lot.