Skip to main content
A prompt that says “only run SELECT” is a suggestion. A connection that physically cannot write is a guarantee. A production data agent answers from a read-only engine and isolates any writes to a schema it owns. The boundary holds even when the model goes off-script.
A connection bound to a read-only database role means a generated DROP TABLE fails at the database, before it reaches your data. Defense does not depend on the model behaving.

Split the roles

Most data-agent questions are read-only. Writes (building a summary table, recording a correction) are rarer and riskier. Separate them into different agents on different connections. The Engineer’s writes are scoped to a schema (for example dash) that the Analyst never touches. Even prompted into DROP TABLE public.users, its engine refuses, because the connection has no write grant on public.

Gate the writes that remain

For writes you do allow, add a human in the loop. requires_confirmation pauses the run until someone approves the action.
Approval everywhere kills adoption. Gate the irreversible actions, not the reads.

Layers of defense

Next steps

Developer Resources