How to Connect an AI Agent to Your Database Safely (2026 Guide)

How to Connect an AI Agent to Your Database Safely (2026 Guide)
Postgres, Supabase, MCP and text-to-SQL: the options, the risks, and how Claix gives agents controlled, typed access to your data
To connect an AI agent to a database safely, don't hand the model a raw database connection. Give it a read-only database role limited to the tables and columns it needs, run every query through validation and limits, and return typed answers instead of free text. A managed layer such as Claix does all of this without code to host: you connect Postgres or Supabase, choose what each agent can use, and the agent gets its answers through its own endpoint.
Updated October 2026. This guide comes from the team that builds Claix, so we say clearly where Claix is the right fit and where it isn't.
The short version
• A language model never connects to a database by itself. It calls a tool: an MCP server, an API, or code you wrote. What that tool allows is what matters.
• A prompt is not a permission. A rule written in a prompt can be overridden, and a privilege in the database can't.
• A read-only Postgres role is necessary, and it is not enough on its own.
• Text-to-SQL is safe for production only with query validation, limits and logging around it.
• Database MCP servers are excellent for development. Supabase says its own is designed for development and testing.
• For production agents, use a controlled layer between the agent and the database. Claix is built for that job.
What does it mean to connect an AI agent to a database?
Connecting an AI agent to a database means giving the agent a way to get information from your data while it works. The agent asks a question, a tool turns it into a query, and the result comes back. This is also called agentic retrieval over structured data.
It differs from RAG. RAG retrieves passages of text from a copy of your documents, usually stored in a vector database. A database connection retrieves exact values (a status, a count, a date) from the live system where the data already lives, so there is no copy to keep in sync.
The layer between the agent and the database can be thin, such as a connection string, or complete, such as a service that handles permissions, query checking, limits and logging. The thinner it is, the more of those jobs fall to you.
Can an AI agent query a database safely?
Yes, if the safety does not depend on the model behaving well. An agent can query a database safely when the permissions live in the database, the queries are checked by code before they run, the results are limited and typed, and every request is logged. It can't be made safe by writing "never read the salary column" in a prompt.
Why is giving an LLM a database connection risky?
A raw connection works in a demo and fails in production for five reasons.
The model can be manipulated. Instructions hidden in a user message, a document, or even a text field in your database can change what an agent asks for. This is prompt injection. Supabase's own documentation names it as the main risk of connecting an agent to your data.
Wrong answers don't raise errors. A query that spells a status value differently, for example canceled instead of cancelled, runs fine, matches no rows and returns an empty result. Nothing fails, and someone acts on it.
The output changes shape. One run returns a boolean, the next returns a sentence such as "Yes, the customer accepted." Both look reasonable to a person. An automation expecting a boolean breaks.
Context grows. If the agent sees a schema with hundreds of tables, you pay in tokens and latency, and the model confuses similar tables.
There is no record. When an answer looks wrong, you can't see which table the agent used or what query it ran.
What is text-to-SQL, and is it safe for production?
Text-to-SQL is the technique of letting a language model write a SQL query from a question in plain language. It is safe for production only when it is surrounded by controls: a read-only role with narrow privileges, a parser that checks every query before it runs, limits on time, rows and cost, and logs.
A good validator uses a real SQL parser, not regular expressions. It accepts one statement, only a SELECT, only approved tables, and only functions from an allowlist, and it rejects SELECT *. Even with all of that, a model can write a query that is allowed, valid and still answers the wrong question, for example with a bad join. That is why test questions with known answers matter.
What is a database MCP server, and should you use one in production?
MCP, the Model Context Protocol, is a standard way for AI clients to use tools. A database MCP server exposes a database as one of those tools, so an assistant or an IDE can query it with little setup.
Supabase's MCP server has a read-only mode that runs queries as a read-only Postgres user, and an option to scope it to a single project. Its documentation also says the server is designed for development and testing. That is the right way to think about database MCP servers: they are very good for exploring data while you build, and they are not the access layer for a production agent that serves other people.
How do you make a read-only Postgres role for an AI agent?
Create a dedicated login role, grant it only CONNECT, USAGE on the schema and SELECT on the specific columns the agent needs, and set timeouts. Never use a superuser or your application's main database user.
CREATE ROLE claix_agent WITH LOGIN PASSWORD 'use-a-secret-manager'
NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT NOREPLICATION NOBYPASSRLS
CONNECTION LIMIT 10;

GRANT CONNECT ON DATABASE mydb TO claix_agent;
GRANT USAGE ON SCHEMA public TO claix_agent;
GRANT SELECT (id, name) ON public.customers TO claix_agent;
GRANT SELECT (id, customer_id, status, total) ON public.orders TO claix_agent;

ALTER ROLE claix_agent SET default_transaction_read_only = on;
ALTER ROLE claix_agent SET statement_timeout = '5s';
Column-level grants matter. With them, a query for a column you didn't grant fails, and so does SELECT *. Avoid GRANT SELECT ON ALL TABLES and the built-in pg_read_all_data role, which gives read access to every table in the database.
This works the same way on Supabase, because Supabase is Postgres.
What can a read-only Postgres role not protect you from?
We tested a standard read-only setup on PostgreSQL 16 and found gaps that most guides skip.
• The read-only setting is a default, not a lock. A session can run SET default_transaction_read_only = off, and a role that has write privileges can then write. What really stops writes is the absence of the privilege.
• Timeouts can be switched off. A session can run SET statement_timeout = 0 and remove the limit. The limit only protects you if the agent can't send a SET statement, which means it must never have a raw SQL session.
• A SECURITY DEFINER function can write for the role. Such functions run with their owner's privileges, and by default everyone can execute them. List them and remove public execute access from the ones that write.
• Table names stay visible. The role can't read a table it wasn't granted, but pg_tables still lists its name. information_schema shows only what the role can access.
• Row-level security with no policy returns zero rows. That fails safe, and it looks like an empty table.
• Anything you granted can be read by a manipulated agent. A role protects what it can't reach, not what you gave it.
The lesson is that the role is the foundation, and it needs layers around it: validation, limits, logging, and a controlled way for the agent to ask.
What are the options for giving an AI agent database access?
There are six approaches, from the least to the most complete.
Predefined functions. You write a fixed set of functions, such as get order status, and the agent calls them. This is the safest and most predictable approach, and it covers only the questions you wrote code for. It is a good choice for a handful of fixed questions.
A database MCP server. Quick to connect and good for development, as covered above. Not designed for production agents.
A framework such as LangChain. You build the agent yourself from parts. LangChain's documentation is candid about the trade-off: running model-generated SQL has inherent risks, permissions should be scoped as narrowly as possible, and its SQL tutorial tools are minimal wrappers for demonstration that need your own validation. You own the safeguards.
An open-source text-to-SQL framework such as Vanna. Vanna's main GitHub repository was archived by its owner on March 29, 2026, so it is read-only and no longer receives new code. It still works as it did, and maintenance is now yours.
A semantic layer such as Cube or Colrows. A semantic layer defines business metrics and access rules once, and agents query those definitions. Cube has an open-source core and a managed cloud priced per developer seat plus compute (as of October 2026, $40 or $80 per developer per month on its Starter and Premium plans, with a custom Enterprise plan). Colrows is an enterprise semantic layer sold on a committed annual figure priced on natural-language requests, with figures given on request. Semantic layers shine for governed metrics shared across teams, and they take modeling work and aim mostly at analytics.
A managed controlled layer such as Claix. A service your agent calls, with permissions, query limits and logging built in, and nothing to host. The rest of this guide explains how it works.
What is Claix?
Claix is a managed, controlled database retrieval layer for AI agents. It sits between an agent and a relational database (Postgres and Supabase today), so the agent never holds a database connection and never writes SQL directly against your tables.
Claix is not an agent framework. It is a service your agent calls. You don't build it into your code and you don't host it. You configure what each agent can reach, and the agent asks questions through an endpoint.
How do you give an AI agent controlled access to Postgres or Supabase with Claix?
There are five steps.

1. Connect your database with a read-only role, like the one above. Claix learns the structure of your tables through that connection.
2. Review your Data Map. Claix drafts a description of your tables and the relationships between them. You choose which tables are used and correct anything the AI suggested, including the relationships.
3. Create routes. A route is a set of tables and columns that can be used for one purpose, with a short guide of rules written in plain language. You tick the columns one by one, so anything you don't tick is not part of the route.
4. Create an agent. It has a name, which becomes its URL (/agent/ followed by the name), a business prompt that explains its job and when to use each route, the routes it can use, and a response mode.
5. Call it. Send one or several questions, each with the type of answer you expect, and get the answers back in the same order. When a question arrives, Claix chooses a route among the routes attached to that agent, writes one read-only query that uses only the tables and columns of that route, and returns the answer. If no route fits, it doesn't guess. A response looks like this: [ { "user_ask": [ { "question": "What is the phone number of the employee named Carlos?", "format": "string" }, { "question": "Has the customer Javier Perez accepted marketing consent?", "format": "boolean" }, { "question": "What is the job title of Marta?", "format": "string" } ], "ia_response": [null, true, "Waiter"], "log_id": "9ff38974-1392-4c1a-83e5-3b2f09bb43dc" } ] The answers come back in the same order as the questions, typed as requested. The first answer is null because the phone number is not in the data that agent can use, so Claix doesn't invent a value. The log_id lets you look up the request in Traces. What is the difference between Claix and a framework or a raw MCP server? A framework is something you build with. Claix is something you call. With a framework you write, host and maintain the query tools, the permission checks and the logging for every agent. With a raw MCP server, the safety depends on the role you connected with, and the model writes the queries unsupervised. With Claix, the boundary is in the configuration. An agent can only use the routes attached to it, and a route can only use the tables and columns you ticked. The agent reasons about its task, and Claix deals with the schema, the queries and the permissions. That separation is the point: an agent should not reason about your SQL and your permissions at the same time. How do typed answers help your workflows? A query returns rows. A workflow usually needs one value with a meaning: has this customer accepted marketing consent, what is the status of this order, when is this guest's next reservation. Claix returns that value in the type you ask for, such as text, a number, true or false, a date, a list or JSON, so the next step of your automation can use it without interpreting a paragraph. Each agent has a response mode. In Data mode, you get the result of the query as it comes out of your database, which suits code that processes the result itself. In Answer mode, you get a reasoned answer in the requested type. In Answer mode the rows returned by the query are sent to a model to produce the answer, so consider that when your data is sensitive. Because the answer is typed, an automation can branch on it directly: • If the value is true, continue the flow. • If the value is null, route the case to a person. • If the value is a number above a threshold, request approval. How do you use Claix with n8n, Make, MCP and other agents? Every Claix agent is reachable over REST, so n8n, Make, Zapier or any backend can call it with an HTTP request and your API key. Claix also exposes a hosted MCP server for MCP-compatible clients, and it is a native A2A agent, so other agents can discover it and delegate data questions to it. Keep your API key on the server, never in browser or mobile code. You can test an agent with real questions in the Sandbox before you connect it to a workflow, and review every request in Traces. What does Claix cost? Claix is priced per question, with no seats and no annual commitment. At the time of writing, a question costs 0.10 euros with Claix Managed AI, or 0.02 euros with your own LLM key plus your provider's token costs. Free questions are included to start. Check the pricing page at claix.dev for current rates. When is Claix not the right choice? Claix is not the best option in every case: • You need each end user to see only their own rows inside the tool. Claix scopes access per agent, not per end user, so per-person rules stay in your database or your application. • You need governed business metrics shared across teams, dashboards or charts. A semantic layer or a BI tool fits that better. • You must self-host everything. Claix is a managed service. • You use a database other than Postgres or Supabase. Those are what Claix supports today. • You only have a few fixed questions. A handful of well-written functions may be all you need. A checklist for connecting an AI agent to a database
6. Create a dedicated read-only role. Never use a superuser or your application's main user.
7. Grant SELECT only on the columns the agent needs, or expose views.
8. Review functions that run with their owner's privileges and revoke public execute access from the ones that write.
9. Set timeouts, and don't give the agent a raw SQL session.
10. Describe your tables and relationships in plain language, so the agent doesn't guess.
11. Limit what each agent can use, instead of exposing the whole schema.
12. Return typed answers, not paragraphs.
13. Treat results as untrusted data, because text in your database can contain instructions.
14. Log every request, and keep the identifier next to important decisions.
15. Test with real questions and with hostile ones before going live. Frequently asked questions Can ChatGPT or Claude query my database? Not on their own. A language model doesn't connect to a database. It calls tools, such as an MCP server, an API or code you wrote. What that tool can do is what matters, so give it narrow, read-only access. What is the best way to let an LLM query a SQL database? The safest way is through a layer that limits permissions in the database, validates queries before they run, caps time and rows, and logs every request. That can be code you write, a framework with your own safeguards, or a managed layer such as Claix. Is it safe to connect Supabase to an AI agent? It can be. Use a dedicated read-only Postgres role limited to specific columns. Supabase's MCP server has a read-only mode and project scoping, and Supabase says it is designed for development and testing, so use a controlled layer for production agents. How do I stop prompt injection in a database agent? You can't fully stop a model from being influenced by text it reads, so limit the damage. Put permissions in the database, grant as little as possible, validate every query, treat results as untrusted data, and log requests. Never rely on a prompt for security. Do I need a vector database to query structured data? Usually not. For exact values, counts and dates, querying the database directly is more accurate than searching embeddings. Vector search suits semantic discovery over large amounts of unstructured text. What is the difference between RAG and text-to-SQL? RAG retrieves passages of text, usually from a vector store, and gives them to the model. Text-to-SQL lets the model write a query against a database. RAG suits documents and meaning, and text-to-SQL suits records and exact values. Is text-to-SQL accurate enough for production? It depends on your data and your descriptions. Good table descriptions, explicit relationships and a test set of questions with known answers raise accuracy, and a validator keeps mistakes from becoming incidents. Measure it on your own questions before you rely on it. How do I connect an n8n AI agent to Postgres? Use an HTTP Request node to call a controlled endpoint, such as a Claix agent, and branch on the typed answer. Avoid giving the workflow a raw database credential with broad privileges. What are alternatives to Vanna? Vanna's main repository was archived on March 29, 2026. Alternatives depend on what you need: a fork you maintain yourself, an open-source semantic layer such as Wren AI, a framework such as LangChain, a semantic layer such as Cube, or a managed layer such as Claix. How much does it cost to give an AI agent database access? It ranges from nothing, if you build it yourself and pay with engineering time, to seat-based and committed annual pricing for semantic layers. Claix charges per question, with no seats or annual commitment. What is agentic retrieval? Agentic retrieval is when an agent decides when it needs information, calls a tool to get it, checks the result and acts. Over structured data, the tool queries a database instead of searching a copy of the data. Sources and further reading • Supabase documentation, MCP server: https://supabase.com/docs/guides/getting-started/mcp • LangChain documentation, SQL agents and security: https://docs.langchain.com/docs/use_cases/sql/ • Vanna repository on GitHub: https://github.com/vanna-ai/vanna • PostgreSQL documentation, GRANT: https://www.postgresql.org/docs/current/sql-grant.html • PostgreSQL documentation, CREATE FUNCTION and SECURITY DEFINER: https://www.postgresql.org/docs/current/sql-createfunction.html • Cube pricing: https://cube.dev/pricing • Colrows pricing: https://colrows.com/pricing.html • Claix: https://claix.dev Claix is a managed, controlled database retrieval layer for AI agents. Connect Postgres or Supabase, choose what each agent can access, and get typed answers over REST, MCP and A2A.