Your database stays yours
Connecting an AI tool to a production database is a real trust decision. Here is exactly how Dronk reaches your data, what we keep, and the controls that keep you in charge of every query.
Data handling
We sync your schema, not your tables
To write accurate SQL, Dronk needs to understand the shape of your database — table names, columns, types, and relationships. It does not need a copy of your data, and we do not keep one.
What we store
- Schema metadata. Table, column, index, constraint, and relationship definitions — so the assistant can reason about your data model.
- Results of queries you run. Only the rows returned by questions you choose to ask, kept so your conversations and dashboards persist. You can delete them at any time.
- Connection settings. Host, port, and database name, plus credentials that are encrypted at rest.
What we never do
- We never write to your database. Dronk only ever issues read queries. It cannot insert, update, or delete data — there is no setting that changes this.
- No bulk copies. We never clone, snapshot, or replicate your tables. There is no background sync of your data into our systems.
- No credentials in plain text. Database passwords and SSH keys are stored encrypted and never shown back to you after they are saved.
Connectivity
Connect on your terms
You decide how much of your network Dronk can see. Every option below works the same once connected — pick the one that matches your security posture.
Direct connection
A standard encrypted connection to a reachable database. The quickest way to get started.
Best for staging databases or hosts you are comfortable reaching over the internet.
IP allow-list
Dronk connects from a fixed set of static IP addresses, so you can lock your firewall down to just us.
Best when you want to keep your database private to everything except a known source.
SSH tunnel Recommended
Your database never has to touch the public internet. Dronk tunnels in over SSH with a key unique to your workspace — via a bastion host, or your database server directly on a VPS or dedicated box.
Best for production databases that should never be publicly reachable.
Query safety
Read-only, enforced three ways
An AI that writes SQL should never be able to change your data by accident. Dronk treats every generated query as untrusted and stops a write at three independent layers.
- Query inspection
- Before anything runs, the query is parsed and rejected unless it is a single read-only statement. Writes hidden inside comments, strings, or sub-queries are caught here.
- Read-only session
- The database session itself is forced into read-only mode for every generated query, so the engine refuses writes even if one slipped through.
- Statement timeout
- A per-statement timeout means a single query can never run unbounded against your production database and tie up resources.
For the strongest guarantee, we recommend connecting with a read-only database user. The layers above are defence-in-depth on top of whatever the credential itself permits.
Human in the loop
Nothing runs without your say-so
Turn on query approval and every AI-generated query waits for a person to review the exact SQL and approve it before it touches your database. Rejected queries are recorded, so you always have a trail of what was proposed and what was allowed.
- Review the precise SQL before it executes
- Approve or reject per query, per workspace
- Every decision is logged
SELECT email, last_seen_at
FROM users
WHERE plan = 'pro'
ORDER BY last_seen_at DESC;Access & accounts
Control who can do what
- Role-based access
- Grant teammates only the permissions they need with roles scoped to each workspace.
- Audit log
- Sensitive actions are recorded to a workspace audit trail you can review at any time.
- Two-factor auth
- Protect accounts with TOTP-based two-factor authentication and recovery codes.
- Encryption at rest
- Connection credentials and SSH private keys are encrypted in our database.
How the AI uses your data
Straight talk about the model
The model writes SQL from your schema alone. To check a query is sound it can run an EXPLAIN — which returns the database's query plan, never your rows. That is everything the model ever sees of your database.
When the query actually runs, it runs in a separate step that the model is not part of. The rows that come back are shown to you and used to build your charts — they are never sent back to the model, not while answering and not on later messages in the conversation.
Requests to our model provider go over their business API, which is contractually prohibited from training on your data, and we do not use your data to train any models ourselves.
FAQ
Security questions, answered
No. Dronk only ever issues read-only queries — it cannot insert, update, or delete data, and there is no setting that changes that. Generated queries are also parsed and rejected unless they are read-only, the database session is forced read-only, and a statement timeout is applied.
No. The model writes SQL from your schema and can run an EXPLAIN to validate it, which returns a query plan rather than rows. The query that returns data runs in a separate step the model is not part of, and those rows are never sent to the model.
No. You can lock your firewall to our static IP addresses, or use an SSH tunnel so your database is never publicly reachable at all — Dronk connects through a bastion host you control.
Database passwords and SSH private keys are encrypted at rest in our database and are never displayed again after you save them.
No. We sync your schema — table and column definitions — so the assistant can write correct SQL. The only row-level data we keep is the results of queries you choose to run, which you can delete at any time.
No. We do not train models on your data, and our model provider is contractually prohibited from doing so via their business API.
Yes. Turn on query approval and every AI-generated query waits for a person to review and approve the exact SQL before it executes. Rejections are logged.
Found a security issue?
We take responsible disclosure seriously. If you believe you have found a vulnerability, email us and we will respond quickly. Please give us a reasonable window to fix it before sharing publicly.