Create a Read-Only DB Role for Agents

A pattern used at DeepAPI. A SELECT-only role kills catastrophic writes at the permission level. Residual risks (data leaks, heavy queries) are handled by a denylist and timeouts. Agents stop being blind on prod; the human stops being the SQL bottleneck.

The SQL, timeouts, grants, denylist, RLS setting, role name, and connection steps below are customizable examples for your own system. Adapt them. They are not a copy of any live production setup.

The pattern — 3 layers

1. Hard wall — grants. The role gets SELECT and nothing else. Writes are impossible, not just discouraged.
2. Denylist, not allowlist. Grant SELECT on ALL current + future tables in public (via default privileges), then revoke tables that hold secrets or PII. Never grant the auth schema. Future tables are auto-readable by design; new sensitive tables need a manual revoke.
3. Soft guardrails. Example: default_transaction_read_only = on plus a short statement_timeout. Tune both for your workload.

RLS trap: if tables have Row Level Security and no policy mentions the new role, every SELECT returns 0 rows. One common fix is alter role ... bypassrls — this only skips row filtering. The SELECT-only grants and denylist still apply. Use it only if it fits your security model.

Workflow