Claix is the controlled data retrieval and security layer for AI agents: it connects to your relational database and lets each agent retrieve only the tables and columns you allow and only execute the actions allowed following your rules and limits, without moving your data. Available via REST API, MCP, and A2A.

How do I get started?

Connect any SQL database with a read-only role (Claix drafts a Data Map for you to review), define routes and agents with your rules (no YAML or code), write Guard rules in plain English for the changes an agent may propose, then call one endpoint so your agent gets live typed answers and a verdict before any change, inside the perimeter you set.

Does Claix copy my data into a vector store?

No. Claix does not copy your data or build a vector index over it. Agents query your database where it lives, within the tables and columns you allow. Every query is validated before it runs and traced afterward.

Does Claix write to my database?

No. Claix never writes to your database. Retrieve connects with a read-only role. When an agent proposes an INSERT, UPDATE, or DELETE, Claix Guard answers allow or deny, with the reason, and your code executes. Loading documents into structured fields is a separate product, Claix Ingest, which you choose to use.

Which databases does Claix support?

Any SQL database, including Postgres, MySQL, and MariaDB, plus Postgres-compatible setups such as Supabase. You connect with a read-only role. Claix never executes writes: Guard only answers whether a proposed change is allowed, and your code runs it.

What are routes and agents?

A route is a retrieval capability: the tables and columns allowed plus a short guide with your rules and vocabulary. An agent is the identity that uses them—its own endpoint, business prompt, attached routes, and response mode (raw results or reasoned typed answers). Create a route once and attach it to as many agents as you need.

How do I call a Retrieve agent?

POST to /retrieve/{agent_name} with a JSON body of questions (each with an optional format such as string, int, boolean, json, or array:string). You get typed answers in order plus a log_id. The same agent is also reachable over MCP (claix.retrieve.ask) and A2A.

What answer formats can I request?

In reasoned mode you can ask for string, int, boolean, timestamp, timestamptz, date, json, array:string, or array:int. Typed values mean your workflow can branch on booleans, use numbers and lists directly, and skip parsing free text.

How does pricing work?

With Claix Managed AI the fee is €0.10 per question. With your own LLM key (BYOK) from OpenAI, Google, Anthropic, or xAI, the Claix fee drops to €0.02 per question and you pay your provider’s tokens directly. Results with your own key depend on the model you choose—test in the Sandbox before going live. Claix Guard is €0.01 per call: each check of an INSERT, UPDATE, or DELETE. There is no model and no managed AI on that check.

Is agentic RAG the same as vector RAG?

No. They sit on different axes. “Agentic” is about who triggers retrieval (a fixed pipeline vs an agent calling a tool). “Vector” is about how results are matched (embeddings). An agent can call SQL, BM25, or embeddings; a fixed pipeline can use hybrid search. For relational business data, embeddings are often the wrong default.

Is SQL retrieval RAG?

Yes. RAG means retrieved information feeds the model. It does not require embeddings, and the retrieved information does not have to be text chunks. A SQL query that returns live records for the model is still retrieval.

When should I still use a vector database?

When you need semantic discovery over a large permanent text collection, heavy repeated search traffic, or a product where search is the product. For exact values, counts, dates, and live rows already in your SQL database, query the database where it lives with scoped access instead of copying it into an index.

Can I use Claix from LangChain, Cursor, or n8n?

Yes. Claix is not an agent framework—it is a retrieval layer you call from the stack you already use. Call REST from any HTTP client (including n8n), expose the agent as an MCP tool for Cursor and compatible clients, or connect over A2A so other agents can delegate data questions.

What happens when the answer is not in the allowed tables?

The field comes back empty instead of a guess. Queries only run inside the routes you attached to the agent; everything outside that perimeter does not exist for them. Traces show what was asked, which route answered, and what came back.

How is Claix different from giving an agent a database MCP server?

A generic database MCP connection is quick to wire up, but the access model depends on the server and the role you attach. Claix adds routes, per-agent allowlists, validation before queries run, typed multi-question answers, Claix Guard — which checks every proposed change against exact rules before your code runs — and a reviewable trace, so you define the boundary once and enforce it on every call.

Do I need guardrails if I already use Row Level Security?

Yes. RLS decides which rows a role can see or change. It does not control which kinds of actions an agent attempts, and it does not limit how many rows one operation touches. The two layers complement each other.

Does this work with any model or agent?

Because the rules are applied outside the agent, they do not depend on the model you use or the framework you built it with.

Can I start with read access only?

Yes, and that is the better start. Give read access first, watch what the agent queries, and add write permissions gradually.

What happens when the agent tries a blocked action?

The action does not run, and the attempt is logged, so you can see what it tried and adjust the rules. Claix Guard answers allow or deny, with the reason. Your code runs the statement only when the answer is allow.

Do I need to know SQL or write complex policies?

No. With Claix Guard you describe the rules in plain English and review the generated rules before you turn them on. At check time the decision is exact: no model decides allow or deny.

I already have an agent in production with direct database access. What should I do?

First cut its permissions to the minimum and remove write credentials it does not need. Then put a guardrail layer between the agent and the database, starting by blocking DELETE and limiting the rows affected.

Try Claix Guard

Back to blog

Security · GuardrailsNovember 6, 2026ByGael Anaya

How to stop an AI agent from deleting your database: guardrails and rules (2026)

An AI agent can delete your database even if the prompt forbids it. Check each action with external guardrails before it reaches the database.

Claix · Updated November 2026. Related guides: read-only Postgres role (/blog/read-only-postgres-role-for-ai-agents), safe agent queries (/blog/how-to-let-an-ai-agent-query-postgres-safely), and six ways to give safe database access (/blog/best-way-give-ai-agents-safe-database-access). Product: Claix Guard (https://www.claix.dev/guard).

Can an AI agent actually delete a database?

Yes, and it has already happened in production. In April 2026, a Cursor coding agent running Claude Opus 4.6 deleted PocketOS's production database and its volume-level backups with a single call to its infrastructure provider, Railway. Reports say it took nine seconds, and the agent ignored instructions that forbade destructive commands. The backups lived on the same volume that was deleted, and the last external backup was three months old.

It is not an isolated case. Other coding agents have deleted production databases before. This is not about one model. The pattern repeats: an agent with broader permissions than it needs, and no layer that checks its actions.

Why is telling the agent “do not delete anything” not enough?

A prompt is a request to the model, not a restriction. A language model is probabilistic: it can decide that a destructive action is the way to solve a problem, such as a credentials error, and run it anyway.

The security rule is simple: the control has to live outside the model. What the agent must not do has to stay blocked even if the agent decides to try it.

Is a read-only database user enough?

It is a good first step, and it is not enough on its own. A read-only role in PostgreSQL leaves several gaps:

Session settings the role can change. Parameters such as default_transaction_read_only can be turned off in the session. What actually blocks a write is the privileges you granted (GRANT), not that setting.
SECURITY DEFINER functions. They run with their owner's privileges, and PostgreSQL lets anyone execute functions by default, so a role with no access to a table can still write to it through a function.
Grants that are too broad. GRANT SELECT ON ALL TABLES exposes tables you did not mean to expose. Grant access only to specific tables and columns.
Row Level Security (RLS). With RLS enabled and no policies, a role sees no rows, so you have to define explicit policies per role.
Everything that is not SQL. In the PocketOS case the destructive action was not a SQL query. It was an infrastructure API call with a broadly privileged token. A database role does not protect against that.

What are guardrails for AI agents that access data?

A guardrail is a rule evaluated outside the agent, before the action runs, that allows or denies it. A good guardrail system follows three principles:

Deny by default. What is not explicitly allowed does not run.
Deterministic enforcement. A model that can be wrong or talked into it does not make the allow or deny decision.
Audit. Every attempted, allowed and blocked action is recorded.

Large platforms already work this way. Amazon Bedrock AgentCore, for example, evaluates each agent-to-tool request against policies defined outside the agent.

How does Claix Guard work?

Claix Guard is a managed service that sits between your AI agents and your databases. You describe the rules in plain English. Claix turns them into exact rules and limits, and checks every INSERT, UPDATE and DELETE before your code runs it. The answer is allow or deny, with the reason. The check is deterministic: no model decides at check time. Claix never runs the statement and never touches your data. Claix also retrieves data for agents inside the limits you set. There is no framework to install and no policy language to learn.

Example rule in plain English: “Agents may query orders and customers, but they must never see emails or phone numbers. They may change an order's status, but they must not delete anything. No operation may affect more than 10 rows.”

How that rule is applied (illustrative)

What you write	What gets enforced
They may query orders and customers	Reads allowed only on those tables
Never see emails or phone numbers	Sensitive columns blocked
They may change an order's status	UPDATE allowed only on the status field
Do not delete anything	DELETE denied
At most 10 rows	Row limit per operation

Which rules should you define first?

Separate reads and writes. Start with read-only agents and add writes only where the task needs them.
Deny DELETE, DROP and TRUNCATE by default.
Limit the rows affected by each operation so one statement cannot change the table.
Hide sensitive columns: emails, phone numbers, identity documents, tokens.
For destructive or irreversible operations, deny them and require human approval in your own workflow (Slack, email, n8n). Guard answers allow or deny. There is no third verdict.
Use different credentials per environment, so a test agent cannot reach production.
Log everything and review blocked attempts. They show what your agent actually tries to do.
Keep backups out of the agent's reach, not on the same volume.

Comparison: what protects what?

Control	Stops accidental deletes	Controls columns and rows	Does not depend on the model	Covers non-SQL actions
Prompt instructions	Not reliable	No	No	No
Read-only database user	Yes, but only for SQL writes	Partial	Yes	No
Row Level Security	No	Rows	Yes	No
External guardrails	Yes	Yes	Yes	Depends on where they are applied

These controls work together. The practical setup is least privilege in the database plus a guardrail layer in front.

Frequently asked questions

Do I need guardrails if I already use Row Level Security?: Yes. RLS decides which rows a role can see or change. It does not control which kinds of actions an agent attempts, and it does not limit how many rows one operation touches. The two layers complement each other.
Does this work with any model or agent?: Because the rules are applied outside the agent, they do not depend on the model you use or the framework you built it with.
Can I start with read access only?: Yes, and that is the better start. Give read access first, watch what the agent queries, and add write permissions gradually.
What happens when the agent tries a blocked action?: The action does not run, and the attempt is logged, so you can see what it tried and adjust the rules. Claix Guard answers allow or deny, with the reason. Your code runs the statement only when the answer is allow.
Do I need to know SQL or write complex policies?: No. With Claix Guard you describe the rules in plain English and review the generated rules before you turn them on. At check time the decision is exact: no model decides allow or deny.
I already have an agent in production with direct database access. What should I do?: First cut its permissions to the minimum and remove write credentials it does not need. Then put a guardrail layer between the agent and the database, starting by blocking DELETE and limiting the rows affected.

Conclusion

Giving an AI agent access to a database is useful, but prompt instructions are not a security control. The combination that works is least privilege, deterministic rules outside the model, and a record of everything the agent tries. With Claix Guard you define those rules in plain English and the service handles the rest. Try Claix Guard at https://www.claix.dev/guard.