Connecting an AI agent to your database without regretting it
The database is the first thing people connect and the first thing that goes wrong. The failure modes are boring and avoidable.
The checklist
- Use a credential that the engine itself limits to reads, and prove it: attempt a write through the connector and confirm the database refuses. A connector that claims read-only on the strength of a string match is not read-only.
- Scope rows below the agent. Views or row-level security keyed to the person’s identity, so a query cannot widen what they may see.
- Bound every query. One page of results, a hard row limit, a statement timeout. An agent that can run a full table scan on the production primary will, eventually.
- No free-form SQL by default. Discovery and saved, reviewed queries first; free-form SQL only for engines where you have a guard that proves what it refuses.
- Keep the credential out of the model. The model composes a request; the runner holds the secret. The two should never be in the same process boundary as a prompt.
- Separate analytics from operations. A warehouse credential and an operational-database credential are different permissions with different blast radii; do not share one connection for both.
What GlowForm does here
Each database connector was run against a real server of its engine, with the read-only refusal tested against that engine rather than assumed. Free-form SQL is limited to PostgreSQL 16 and later, where every refusal the SQL guard makes has been checked against the real server. Reads return one bounded page and say when there is more. None of that is exotic; it is just the checklist, done.