A prompt cannot enforce database permissions. Claix Guard checks the changes your agent proposes against approved rules and returns allow or deny before your code runs them.
Claix · Updated November 2026. Product: Claix Guard. Docs: Check SQL API.
Quick answer
To add SQL guardrails with Claix Guard, describe rules in plain English, review and approve the proposed conditions, and try statements in the Sandbox. Then call POST /check-sql before every change. Send the SQL and its parameters, read allowed, and execute only when it is true.
Claix Guard checks; your code executes. With a connection ready and an executor you can edit, you can configure and test a first rule in about five minutes.
Reading a database and changing it are different jobs. An agent can understand a request and still propose a discount that is too high, an update on the wrong column, or a delete nobody authorized. Writing “do not make dangerous changes” in the prompt does not make that instruction a mandatory check. You set the policy; Guard returns a decision; your application controls execution.
How Claix Guard works
Main operations: INSERT, UPDATE, and DELETE.
Setup: Plain-English rules turned into exact proposals.
Activation: You review and approve the rules.
Decision: Deterministic check; no model decides on each call.
Result: Allow or deny, with the reason.
SQL execution: Your application.
Oversight: Decisions stored in Guard Traces.
Documented databases: PostgreSQL, MySQL, and MariaDB.
What Claix Guard checks
Guard does not judge whether a conversation “looks safe”. It checks a SQL statement and its parameters against the active rules of a connection. “Discounts cannot exceed 20%” can become a testable condition. A proposed 35% can be denied with the broken rule.
Guard does not replace database permissions, schema constraints, or your app's access control.
Examples of what you control:
An operation on a table: Agents can never delete orders.
A limit on a value: A discount cannot exceed 20%.
Which columns can change: The agent may change status, never price.
What the WHERE must contain: An update must name the order by id.
A denial your workflow routes for review: Refunds above a threshold go to a person.
A fixed set of values: Only certain statuses are allowed.
Separate the proposal from the execution
The agent should not be able to write to the database itself. It proposes the operation. An executor you control holds the credentials, asks Guard, and decides whether to run it. If the agent has another write path, it can skip the check. You also need active rules. The docs state that if no guards are active, the write is allowed.
Steps
Write one rule you can test, such as “an order discount cannot exceed 20%”. A model helps turn the sentence into exact proposals. Later checks do not ask a model again.
Review the table, column, and unit. 20% might be stored as 20 or as 0.20. A person should approve rules. An agent should not be able to loosen the limits that apply to it.
Try allowed and denied cases in the Guard Sandbox before you wire the executor.
Call POST https://claix.dev/check-sql with sql and params. Use $1, $2 for Postgres and ? for MySQL and MariaDB. Send connection_id when you have more than one active connection.
Read allowed, not only the HTTP status. A denial is still HTTP 200. Execute the same statement and parameters you checked.
Bash
curl -X POST "https://claix.dev/check-sql" \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"sql":"UPDATE shop.orders SET discount_percent = $1 WHERE id = $2","params":[35,4821]}'
How your app should handle the response:
HTTP 200 and allowed: true: Guard allows the checked operation. Execute it.
HTTP 200 and allowed: false: Guard denies the operation. Block it.
HTTP 401: Fix your API Key authentication.
HTTP 400: Fix the invalid request payload.
Network error, timeout, or invalid body: Treat as unauthorized / blocked.
What deterministic means
A model may help when the rule is created. It does not decide, on each check, whether a write is allowed. The check uses the approved rules. Deterministic does not promise a fixed latency. It means the allow or deny answer does not depend on talking another model into calling the change reasonable.
Where to place the check
Your backend: In the function that executes changes.
An agent tool: Inside the controlled implementation of that tool.
n8n or Make: Before the write step, branching on allowed.
MCP client: In a flow the agent cannot bypass.
Several agents: At the shared executor, or at every authorized executor.
Each check returns a decision_id you can open in Guard Traces, along with the operation, table, checked SQL, rules, violations, and latency. A stored decision does not prove the write ran. Log the real execution in your app.
What Guard does not do
It does not execute statements.
It does not replace SQL privileges or schema constraints.
It does not see triggers inside the database.
It does not protect a database the agent can reach directly.
It does not handle reads. Use Claix Retrieve for those.
Frequently asked questions
Does Claix Guard run my INSERT, UPDATE, or DELETE?
No. Guard returns a decision. Your code executes the statement with its own credentials.
Does it need my database write credentials?
It does not need write credentials to execute changes, because it does not execute them. The API does need an active connection whose rules it checks.
Can I write rules in plain English?
Yes. Claix proposes exact conditions from your description. You review, edit, or approve them before they apply.
Does a model decide whether my SQL is allowed?
Not at check time. The decision uses approved rules. A model is used when the rule is first proposed.
What if I have not activated any rules yet?
The docs say that with no active guards on the connection, the write is allowed. Confirm that active rules cover the tables and operations you want to limit.
Does Guard include human approval?
Guard returns allow or deny. If a person should see a case, deny it with a rule and route that denial in your own workflow.
How is Guard different from Retrieve?
Retrieve controls reads and returns data. Guard checks proposed INSERT, UPDATE, and DELETE statements before your application runs them.
Can I protect an agent that still has direct write credentials?
Not by adding Guard as an optional tool. If the agent can reach the database without the executor that requires the check, it can skip it.
Start with one rule you can verify
Pick one change the agent needs and one limit the business cannot break. Configure the rule, test an allowed case and a denied case, and connect the check to the component that writes.
Start at claix.dev/guard and use the API docs at claix.dev/documentation/check-sql.
Top comments (0)