Claix · Updated October 2026
SQL Guardrails for AI Agents: Check Every INSERT, UPDATE and DELETE Before It Runs
Claix Guard is a rules checker for the changes your AI agents propose to your database.
Before your agent runs an INSERT, UPDATE or DELETE, Claix checks it against rules you approved. The answer is allow or deny, with the reason. Claix never runs the statement.
Quick answer
What does Claix Guard answer?
Claix Guard is a SQL checker for AI agents. Before your agent runs an INSERT, UPDATE or DELETE, it sends the statement to Claix, and Claix checks it against rules you wrote in plain English and approved. The answer is allow or deny, with the reason. The check is deterministic: no AI model decides at check time. Claix never runs the statement. Your own code does.
Key points
What Claix Guard does, and what it never does
- What it checks: every INSERT, UPDATE and DELETE an AI agent proposes, with its parameters.
- How you set the rules: in plain English, by you or by your agent through the API or MCP. Claix proposes exact rules and limits, and you accept, reject or edit them.
- How it decides: with exact rules, not with a model, so the same statement always gets the same answer.
- What it returns: allow or deny, and why.
- What it never does: run your statements or touch your data.
- What it costs: €0.01 per check. The current rate is on the pricing page.
What is Claix Guard?
Claix Guard is a hosted service that checks the database changes an AI agent proposes before they happen. It sits between the agent and the code that executes its statements. The agent proposes a change, Guard decides whether the rules allow it, and your executor runs it only if the answer is allow.
It is the second half of the Claix control layer. Claix Retrieve controls what your agents can read. Claix Guard controls what they can change.
- INSERT, to create rows.
- UPDATE, to modify rows.
- DELETE, to remove rows.
Why do AI agents need a checker for INSERT, UPDATE and DELETE?
A database that an agent can change is a database that can be changed wrongly, and a prompt is the only thing between the agent and the mistake. A prompt is not a permission: an instruction written in it can be ignored, overridden or manipulated. Six things go wrong in practice.
Database permissions help, and they can't express rules like "discounts up to 20 percent" or "refunds above 200 euros are denied". Guard is where those business rules live.
- A DELETE or UPDATE without a WHERE. One missing condition affects every row in the table.
- A value outside any sensible limit. A discount of 90 percent, a negative quantity, a price of zero.
- A change nobody should make. Deleting an order, editing a closed invoice, touching a column that must never change.
- A statement that is valid and still wrong. It runs without an error and does something the business never intended.
- Too many changes too fast. A loop that fires fifty refunds in a minute.
- No record. When something looks wrong afterwards, nobody can say what the agent tried or why it was allowed.
How does Claix Guard work?
It works in four steps. If the answer is allow, your own code executes the statement. The reason is written so the agent can correct itself and try again with a valid value.
- 01
Write your rules in plain English
For example: Discounts can't exceed 20 percent. Agents can never delete orders.
- 02
Claix proposes exact rules
It turns your words into precise rules and limits. You, or your agent through the API or MCP, accept, reject or edit each proposal.
- 03
The agent asks before it changes anything
It sends the INSERT, UPDATE or DELETE, with its parameters, to Claix.
- 04
Claix answers
Allow or deny, with the reason. Your code runs the statement only when the answer is allow.
What does a check look like?
An illustrative request and response. The live call is POST /check-sql. A denial is still HTTP 200: read allowed. The full fields are in the check-sql documentation.
POST /check-sql
{
"sql": "UPDATE orders SET discount_percent = $1 WHERE id = $2",
"params": [35, 4821]
}
{
"allowed": false,
"code": "rule_denied",
"reason": "discount_percent must be 20 or less. Received 35.",
"sql": "UPDATE orders SET discount_percent = $1 WHERE id = $2",
"decision_id": "9ff38974-1392-4c1a-83e5-3b2f09bb43dc"
}How do plain-English rules become exact rules?
You describe a limit the way you would to a colleague, and Claix proposes an exact version of it. A model helps once, when the rule is created. It never decides on a change. We recommend that a person approves the rules, and that an agent proposes them. An agent that could loosen its own limits would defeat the point of having them.
- 01
Send the rule in plain English
You, or your agent through the API or MCP, describe the limit.
- 02
Claix returns proposed rules and limits
The proposal is exact: the condition, the tables, and the message.
- 03
You accept, reject or modify each one
Nothing is enforced until it is approved.
- 04
The approved rules are what Guard enforces
From then on, the same statement with the same parameters gets the same answer.
What kinds of rules can you set?
These are examples of limits you can describe in plain English. What Guard can't understand, it doesn't approve: the statement is denied.
- Which operations are allowed. Agents can create and update orders, and can never delete them.
- Which columns can change. Agents can update the status of an order, and never its price.
- What a WHERE must contain. An UPDATE or DELETE must name a single order by its id.
- Limits on values. Discounts up to 20 percent. Quantities above zero. Status only one of a fixed list.
- Allowed transitions. An order can go from pending to shipped to delivered, and not backwards.
- How often. No more than five refunds per hour.
- Cases a person should see. A rule can deny refunds above 200 euros, and your workflow sends that denial to a person.
Why is the check deterministic and not agentic?
A deterministic check follows exact rules, so the same statement with the same parameters always gets the same answer. No AI model decides at check time. Guardrails that ask another model whether a statement looks safe inherit the weaknesses of a model: they can be talked around, and they can give a different answer next time. A rule that says "discount_percent must be 20 or less" can't be talked into 35.
- Predictable. There is no mood, no prompt and no randomness in the decision.
- Explainable. Every denial points to the rule that caused it.
- Testable. You can try your rules on example statements before you rely on them.
- Fast. There is no model call in the path, so a check doesn't wait for a model.
Does Claix run my INSERT, UPDATE or DELETE?
No. Claix Guard only checks. Your own code executes the statement, with your own credentials, and Claix never touches your data. That also means Claix doesn't need write access to your database. If the agent can reach the database by another route, it can skip the check. Guard decides, and your executor enforces.
- 01
Your agent has no write credentials
It can propose a statement. It cannot run one.
- 02
One function in your code has the credentials
It is the only way a change reaches the database.
- 03
That function calls Guard first
It runs the statement only if the answer is allow.
What should you keep in the database as well?
Guard is one layer. It adds what the database can't: business rules in plain English, an explanation the agent understands, and one policy for every agent. Keep the other layers.
- A dedicated role with narrow privileges. The agent's executor should be able to change only the tables and columns it needs.
- CHECK constraints and NOT NULL. Rules that the data must always satisfy belong in the schema too.
- Row-level security, when different people or tenants share a table.
- Logging, so there is a record on your side as well.
How is Claix Guard different from other approaches?
The best setup combines several of these.
Database permissions and constraints
They are essential and they enforce what the database itself understands. They can't read your business rules, and their errors aren't written for an agent. Use them together with Guard.
SQL guardrail libraries
Some are Python libraries that check a statement against a policy file inside your own application. Guard is a hosted service that checks statements for every agent and every database with one policy, and you write the rules in plain English.
Proxies and gateways in the execution path
Some tools sit between the agent and the database and run the statement once it is approved. That gives them enforcement, and it also means they hold your database credentials. Guard decides and doesn't hold them.
Another model as the judge
A model that reviews the statement is flexible and can be wrong in a different way each time. Guard's decision is exact.
Human approval for everything
Safe and slow. Guard handles the clear cases instantly. When you want a person to see a case, deny it with a rule and route that denial in your own workflow.
What can you build with Claix Guard?
These are examples of how teams could use it.
A support agent that gives refunds and discounts
Limit discounts to 20 percent, deny refunds above a threshold so a person can review them, and cap how many an agent can issue per hour.
A sales assistant that updates the CRM
Allow it to change the status and notes of a deal, and never the owner or the amount of a closed deal.
An operations agent that manages inventory
Allow stock adjustments within a range, and never deletions.
An internal assistant for HR records
Allow changes to contact details, and deny anything about salary or contracts so a person reviews it.
A workflow in n8n or Make
Call Guard with an HTTP request before the node that writes, and branch on the answer.
A multi-agent system
Give every agent the same policy, so rules don't drift between agents.
How do you add Claix Guard to your agent?
Claix Guard works with any agent framework, with MCP clients, and with automation tools that can send an HTTP request.
- 01
Create a policy
Write your first rules in plain English and review the proposals.
- 02
Test it in the Sandbox
Try example statements, including ones that should be denied.
- 03
Call Guard before every change
Use REST or MCP, from your executor function or from the agent's tool.
- 04
Execute only on allow
Return the reason to the agent on deny. Send the cases you want a person to see through your own workflow.
- 05
Keep the trace
Every decision is recorded so you can review what was proposed and why it was allowed or not.
What does Claix Guard cost?
You pay €0.01 for each check, with no seats and no plans. Claix Guard is priced separately from Claix Retrieve. The current rate is on the pricing page.
What doesn't Claix Guard do?
- It doesn't run your statements. Your code does.
- It doesn't replace database permissions. It adds business rules on top of them.
- It can't see what happens inside your database, such as triggers, so keep critical rules in constraints too.
- It doesn't protect a database the agent can reach directly. The agent must not hold write credentials.
- It doesn't approve statements it can't understand.
- It checks changes, not reads. For reads, use Claix Retrieve.
Frequently asked questions
- What is a SQL checker for AI agents?
- A SQL checker for AI agents is a service that reviews the INSERT, UPDATE and DELETE statements an agent proposes, and says whether they follow your rules before they run. Claix Guard is one.
- How do I stop an AI agent from deleting data?
- Don't rely on a prompt. Give the agent no write credentials, send every change through one executor function, and make that function ask a rules checker first. With Claix Guard, you can set a rule that agents can never delete, and a DELETE is denied with the reason.
- How do I validate SQL before it runs?
- Parse the statement, check it against rules about operations, tables, columns, values and conditions, and execute it only if it passes. Claix Guard does this check for INSERT, UPDATE and DELETE and answers allow or deny.
- Can I write the rules in natural language?
- Yes. You describe the limit in plain English, Claix proposes exact rules, and you accept, reject or edit them. The approved rules are what Guard enforces.
- Does an AI model decide whether a statement is allowed?
- No. A model can help propose rules when you create them. The check itself is deterministic, so the same statement always gets the same answer.
- How fast is the check?
- There is no model call in the path, so a check doesn't wait for a model. Latency depends on where your code runs and on your network, so measure it in your own setup.
- Does Claix execute my statements?
- No. Claix only checks them. Your code executes, with your credentials, and Claix never touches your data.
- Which databases does Claix Guard support?
- Postgres, MySQL and MariaDB.
- What happens when Guard can't understand a statement?
- It isn't approved. Guard answers deny and tells the agent why.
- Can an AI agent approve its own changes?
- It shouldn't. We recommend that agents propose rules and that a person approves them. Guard does not give an agent a way to approve its own write.
- How do I send a change to a person?
- Write a rule that denies the case, such as refunds above a threshold, and route that denial to a person in your workflow, for example through Slack, email or n8n. Guard itself answers allow or deny.
- What is the difference between Guard and a read-only role?
- A read-only role limits what an agent can read. Guard checks what an agent wants to change. Retrieve and Guard cover the two halves.
- Is a database role enough to protect against agent mistakes?
- It is the foundation. It can't express business rules such as limits and thresholds, and its errors aren't written for an agent. Use it together with Guard.
- Does Claix Guard work with MCP, n8n and LangChain?
- Yes. Call it over REST or MCP from any agent framework, or use an HTTP request in n8n or Make.
- How much does it cost?
- €0.01 per check. See the pricing page for the current rate.
Sources and further reading
PostgreSQL documentation, constraints: https://www.postgresql.org/docs/current/ddl-constraints.html
PostgreSQL documentation, row security policies: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
PostgreSQL documentation, GRANT: https://www.postgresql.org/docs/current/sql-grant.html
Claix: https://www.claix.dev
Check the change before your code runs it
Claix Guard checks every INSERT, UPDATE and DELETE your AI agent proposes against rules you set in plain English, and tells the agent why when the answer is no.