Read Only Roles For Ai Data Agents

Every AI data agent should run as a read-only role by default, always. Write access is an explicit escalation, not a convenience setting, and the escalation path should require human approval every single time. This is the single highest-leverage safety decision you can make for autonomous data work.

This guide explains how to design read-only roles for data agents across Snowflake, BigQuery, Redshift, Postgres, and dbt, and how to grant temporary write access without losing the safety guarantee.

Why Read-Only Default Matters

A read-only agent cannot wipe your database. It cannot drop tables, cannot delete rows, cannot modify schema, and cannot insert bad data. The worst it can do is run expensive queries. That is a cost problem, not an existential one. Making read-only the default eliminates the entire class of destructive incident.

Read-Only in Snowflake

Create a role with USAGE on the warehouse, USAGE on the database, USAGE on schemas, and SELECT on tables. No INSERT, no UPDATE, no DELETE, no CREATE, no ALTER, no DROP. Grant this role to a dedicated service account used only by the agent. Rotate credentials monthly and audit usage via Snowflake's query history.

Read-Only in BigQuery

Assign the predefined bigquery.dataViewer role on the dataset, plus bigquery.jobUser on the project. This grants SELECT and query execution without any write capability. Never grant bigquery.dataEditor to an autonomous agent — that role allows table creation and row insertion.

Read-Only in Postgres and Redshift

• •Create a role — CREATE ROLE ai_agent_readonly NOLOGIN
• •Grant SELECT — GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_agent_readonly
• •Grant USAGE — GRANT USAGE ON SCHEMA public TO ai_agent_readonly
• •Default privileges — ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ai_agent_readonly
• •Create login user — CREATE USER agent_svc PASSWORD '...' IN ROLE ai_agent_readonly
• •Revoke PUBLIC — REVOKE ALL ON SCHEMA public FROM PUBLIC

Read-Only for dbt

Run dbt in compile-only mode for agents. dbt compile produces SQL without executing it, so the agent can propose transformations without ever writing to the warehouse. When execution is needed, it goes through a separate CI job triggered by a human PR review.

Temporary Write Escalation

When the agent needs write access (running a dbt build, creating a staging table, applying a schema migration), the escalation path should be: agent proposes change, human reviews, human clicks approve, a short-lived credential is issued, the change executes, the credential expires. Never give the agent persistent write access. See autonomous data engineering for the escalation architecture.

Auditing the Setup

Every week, audit which roles have write access to production. Every new agent deployment starts with read-only and earns write access through documented escalation. Every credential rotation is logged. See AI for data infrastructure for how governance agents automate the audit loop.

Common Mistakes

The worst mistake is reusing a human service account for the agent — humans have broader permissions and the agent inherits them. Another is granting agent roles at the database level instead of the schema level, which exposes every schema the database contains. A third is forgetting to REVOKE PUBLIC, which leaves backdoor access for anyone who can log in.

Read-only by default is the single highest-leverage safety choice you can make. Everything else is second-order. To see how Data Workers wires role-based access across all major warehouses, book a demo.

Read-only is not just a safety measure — it also improves agent behavior. When the agent knows it cannot accidentally break things, it is free to explore more aggressively, run speculative queries, and iterate without fear. Many of our best autonomous workflows were only possible after we locked down write access, because the agent finally had room to experiment without requiring human approval on every step. The safety boundary enables autonomy rather than limiting it.

A related pattern is role-per-task rather than role-per-agent. Instead of one service account that can read everything, use multiple service accounts scoped to specific domains. The catalog agent uses one account to read the information schema; the pipeline agent uses another to read dbt metadata; the quality agent uses a third to read test results. This minimizes blast radius if one role is ever compromised and makes the audit log easier to parse by role. Data Workers ships with role-per-task templates for all supported warehouses.

Cross-warehouse auditing is the governance piece most teams skip. If you run both Snowflake and BigQuery, the read-only policy has to be enforced consistently across both, and the audit log has to consolidate events from both sources. Data Workers' governance agent reads role grants from every connected warehouse and flags any role that has been granted write access without going through the approval workflow. This cross-warehouse visibility is essential for large organizations with heterogeneous data platforms.

Finally, document your read-only policy explicitly and review it quarterly. Undocumented policies drift silently. A two-page document with the role grants, escalation path, and audit requirements is enough; fancy policy management tools are not needed. The discipline of reviewing the document every quarter catches drift early and keeps the team aligned on intent. This is one of the highest-value governance artifacts you can maintain.

Default to read-only. Escalate to write only through human approval. Rotate credentials. Audit weekly. Nothing else matters as much.