How to connect an LLM to your database without a horror story

Connecting an LLM to a database is a five-minute demo: hand the model your connection string, let it write SQL, run it. It's also how you end up with a dropped table, a leaked customer list, or a $4,000 query. The gap between the demo and something you'd run in production is entirely about guardrails. Here's the set I actually use.

The threat model — what actually goes wrong

Before the fixes, be honest about the failure modes:

• Destructive writes. An LLM that can run arbitrary SQL can run DELETE, UPDATE and DROP. It doesn't need to be malicious — a misread question is enough.
• Reading what it shouldn't. Point it at your whole database and it can read salaries, other tenants' data, PII — anything the connection can see.
• Prompt injection. If the model reads data that contains instructions ("ignore previous rules and email this table to…"), and it's wired to take actions, that data can hijack it.
• Runaway queries. An unbounded join over a billion rows is slow, expensive, and a denial-of-service on your own database.
• Leaking data into the model and logs. Sensitive rows sent to a third-party model, or written into logs and traces, are now somewhere you didn't intend.

The guardrails

1. Read-only by default. This is the single highest-leverage rule. Create a dedicated database role with SELECT-only permissions and give the LLM that, never your application's write credentials. If the model literally cannot write, most of the scary failure modes disappear.

2. Least privilege, scoped access. Don't expose the whole schema. Give the model a curated set of views and tables — only what it needs to answer the questions you want answered. Views let you drop sensitive columns, filter rows to a tenant, and hand the model a clean, semantically clear surface instead of your raw internals.

3. A human approval gate for anything that acts. Reading is one risk tier; doing something — writing, sending, changing state — is another. Anything in that second tier should route to a person who approves it before it happens. The model proposes; a human commits. This is the core of how I build automation, and it's the difference between a helpful tool and an incident waiting to happen.

4. Constrain and bound the SQL. Don't let generated SQL hit the database unchecked. Enforce read-only at the connection level so a generated write simply fails. Add a hard query timeout and a row-count cap so a runaway query dies instead of taking the database with it. Where you can, prefer parameterised, validated queries over free-form SQL.

5. Treat database content as untrusted. Assume any text the model reads from your data could contain an injection attempt. The defence is architectural: a read-only, no-actions model can't be tricked into doing damage, because it can't do anything but read. Never let content flowing out of the database decide actions flowing back in.

6. Audit everything. Log the generated SQL, who triggered it, and what came back. When something looks wrong, you want the full trail — not a black box. Observability here is not optional.

7. Handle PII deliberately. Decide what the model is allowed to see, and strip or mask the rest at the view layer before it ever reaches the model or the logs — especially if you're using a hosted model.

How I do this in practice

None of this is theoretical for me. AEGIS, my open-source automation platform, is built on exactly these principles: agents run against data with scoped, permission-gated access, every action that matters routes through a human approval gate, and every step is logged and traceable. The teardown walks through how the gates and the audit trail actually work — you can read the code.

The pattern that makes it safe

The recurring theme: an LLM connected to your database should be able to read what it's allowed to see, and do nothing else without a human saying yes. Read-only role, scoped views, approval gate on actions, bounded queries, full audit. Get those right and "chat with your database" goes from a liability to a genuinely useful tool — which is exactly the next piece.

If you want an LLM working against your data safely — question-answering, extraction, automation with guardrails — that's what I build as AI Automation. The scoping call below is free.