How to Give AI Read-Only Access to Your Database (2026)

Before you connect any AI tool to your database — an assistant, an agent, or a natural language query product — you should hand it credentials that physically cannot modify your data. Not credentials you trust it not to misuse. Credentials where writes fail at the database level, no matter what SQL gets generated.

This takes about five minutes and it's the single most effective safety measure for AI database access. Here are copy-paste steps for PostgreSQL, MySQL, and Supabase, plus what read-only access does and doesn't protect you from.

Why read-only access is non-negotiable for AI tools

AI tools that query your database generate SQL from natural language. Modern tools are good at this, but the correct security posture is to assume any generated query could be wrong. If the connection can only SELECT, the worst case of a bad query is a wrong answer or a slow scan — never a dropped table, an overwritten column, or a deleted customer.

Application credentials are the wrong thing to paste into an AI tool. Your app's database user typically has INSERT, UPDATE, DELETE, and often DDL rights because the app needs them. An analytics or AI connection needs none of that. Separate user, SELECT-only, done.

There's a second benefit: auditability. When your AI tool has its own database user, its queries show up under that user in your database logs. You can see exactly what it ran, rate-limit it, or revoke it in one command without touching your application.

PostgreSQL: create a read-only user

Connect as a superuser (or the database owner) and run the following, replacing the password and database name:

CREATE ROLE ai_readonly WITH LOGIN PASSWORD 'use-a-long-random-password';

GRANT CONNECT ON DATABASE your_db TO ai_readonly;

GRANT USAGE ON SCHEMA public TO ai_readonly;

GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;

ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ai_readonly;

The last line matters and is the step most guides skip: it makes sure tables created in the future are also readable, so your AI connection doesn't silently go blind on new tables.

If you use multiple schemas, repeat the USAGE and SELECT grants per schema. To be extra safe on Postgres 14+, you can also set the role to default to read-only transactions: ALTER ROLE ai_readonly SET default_transaction_read_only = on;

MySQL: create a read-only user

Connect as root or an admin user and run:

CREATE USER 'ai_readonly'@'%' IDENTIFIED BY 'use-a-long-random-password';

GRANT SELECT ON your_db.* TO 'ai_readonly'@'%';

FLUSH PRIVILEGES;

That's it — MySQL grants apply to future tables in the database automatically, so there's no default-privileges step. If your database is only reachable from known IPs, replace '%' with that IP range to narrow the surface further.

Supabase: use a dedicated Postgres role, not your service key

Supabase is Postgres underneath, so the PostgreSQL steps above work as-is — open the SQL Editor in your Supabase dashboard and run them there. Two Supabase-specific notes:

First, never hand an AI tool your service_role key. It bypasses Row Level Security entirely and can read and write everything. A scoped Postgres role is the right credential for analytics access.

Second, connect through the connection pooler (the aws-…pooler.supabase.com host on your project's connect page) rather than the direct database host. Pooled connections keep your AI tool from exhausting connection slots your application needs, and the pooler host works from IPv4-only environments where the direct host sometimes doesn't.

Connecting an AI tool with your read-only user

Once the role exists, connecting is the easy part. In AI for Database, you paste the same host, database name, and your new ai_readonly credentials into the connection form, hit test, and start asking questions in plain English — 'what was signup growth last month?', 'which customers haven't logged in for 30 days?'. The tool generates SELECT queries against your read-only role, shows you the SQL it ran, and turns answers into self-refreshing dashboards your team can share.

Because the credentials can't write, you can hand this to non-technical teammates — customer success, ops, marketing — without a review process for every question they ask. The database enforces the boundary, not policy.

The same principle applies whatever tool you connect: ChatGPT with a plugin, a custom agent, a BI tool. The read-only role is tool-agnostic. Set it up once and reuse it.

What read-only access does NOT protect against

Read-only is necessary, not sufficient. Three things it doesn't cover:

Data exposure. A SELECT-only user can still read sensitive columns. If your users table has password hashes or PII the AI tool has no business seeing, don't grant SELECT on the whole schema — grant table by table, or create views that exclude sensitive columns and grant SELECT only on the views.

Expensive queries. A bad SELECT can still scan a billion rows and spike your CPU. Set a statement timeout for the role: ALTER ROLE ai_readonly SET statement_timeout = '30s'; on Postgres. On MySQL, set max_execution_time for the session or user.

Credential leakage. Treat the read-only password like any secret: long, random, stored in a secrets manager, rotated if a tool is decommissioned. Read-only limits the blast radius of a leak; it doesn't make leaks fine.

Common questions about AI database access

The FAQ below answers the questions we hear most from teams setting this up for the first time.