DEV Community

Claix
Claix

Posted on

5 Essential Tools for AI Agent Database Security in 2026: Controlled Reads and Checked Changes

#ai #agentskills #agents #postgres

Quick answer

The five essential tools for securing how AI agents access a database are Claix, PostgreSQL's built-in controls, Interdict, SQLGuard MCP, and sql-guardrail. Claix is the all-in-one option: a managed service that controls what an agent can read, checks every INSERT, UPDATE, and DELETE it proposes against rules written in plain English, and records every request. PostgreSQL's own roles, row-level security, and constraints are the foundation under everything. Interdict, SQLGuard MCP, and sql-guardrail are open-source tools that cover one piece each, and you run them yourself.

The five tools at a glance

  • Claix. A managed control layer: controlled reads through Claix Retrieve, and a rules check for changes through Claix Guard.
  • PostgreSQL's built-in controls. Roles, column privileges, row-level security, and constraints. The foundation.
  • Interdict. An open-source safety layer for Postgres that measures a write before it happens and can hold or undo it.
  • SQLGuard MCP. An open-source MCP server that classifies an agent's queries and asks for confirmation before changes.
  • sql-guardrail. An open-source Python library that checks a SQL statement against a policy file before it runs.

What does securing an agent's database access involve?

It involves three jobs, and most incidents come from skipping one of them.

  1. Limit what the agent can read. Which tables and columns, for which agent, and with what result format.
  2. Check what the agent wants to change. Every INSERT, UPDATE, and DELETE, against rules the model cannot override.
  3. Keep evidence. A record of what was asked, what was proposed, and why it was allowed or denied.

Underneath all three sits least-privilege access in the database itself. A prompt cannot do any of this. An instruction written in a prompt is documentation of intent, not a control.

How did we choose these tools?

We looked for tools that act outside the model and that a team could use in production. The criteria were:

  • It does not depend on a prompt. The control works even if the model is manipulated or wrong.
  • It covers reads, changes, or both.
  • The decision is deterministic, so the same input gets the same answer.
  • It explains a denial in a way an agent can use.
  • It leaves a record.
  • It is practical to run: who hosts it, who maintains it, and whether it holds your database credentials.

1. Claix: the all-in-one managed control layer

Claix is a managed control layer between AI agents and your database. It has two parts that share the same account, connection, and Data Map.

Claix Retrieve controls what an agent can read. You connect your database with a read-only role, choose which tables and columns each route can use, and give each agent its own endpoint. The agent asks questions in plain language and gets typed answers back, as booleans, numbers, text, dates, lists, or JSON. It never holds a database connection and never writes SQL directly against your tables. Every request is traced.

Claix Guard checks what an agent wants to change. Before an INSERT, UPDATE, or DELETE runs, your application sends the statement and its parameters to Claix. Claix checks it against rules you wrote in plain English and approved, and answers allow or deny, with the reason. A denial is still HTTP 200. There is no third verdict. If a change should be reviewed by a person, Guard denies it and your own workflow routes that denial to Slack, email, or n8n. No model decides at check time, and Claix never runs the statement. Your own code does, so Claix does not need write access to your database.

Why it is number 1

  • One service for both halves. The other tools on this list cover reads or changes, and each one is a piece you assemble. Claix covers controlled reads, checked changes, and the audit trail from one place.
  • Nothing to host. There is no Python process, MCP server, or proxy to run and maintain.
  • The agent does not write SQL for reads. It asks a question and gets a typed answer, so there is no query to manipulate.
  • Rules in plain English. Claix proposes exact rules, and you accept, reject, or edit them. The check itself is deterministic.
  • It does not hold write credentials. Guard only checks.
  • One policy for every agent, and a trace of every decision.
  • Pay per use. Retrieve is priced per question and Guard per check, with no seats.

Best for teams that run agents in production, want one managed layer for reading and changing data, and do not want to build and operate the safeguards themselves.

Limits: Access is scoped per agent, not per end user. If each person must see only their own rows, enforce that in your database or application. Guard decides and your executor enforces. The agent must not hold write credentials, or it can skip the check. Claix is a managed service, so every check is a network call and nothing is self-hosted. Supported databases are Postgres, MySQL, and MariaDB. It is not a BI tool.

2. PostgreSQL's built-in controls: the foundation

Roles, column-level privileges, row-level security, views, and constraints are built into PostgreSQL. MySQL and MariaDB have their own equivalents of the privilege model.

They are essential because they are the only controls that live in the database itself, so they hold even when everything above them fails. A dedicated role with SELECT on specific columns is the first line of defence, and a CHECK constraint rejects a bad value whatever the agent does.

We ran a standard read-only setup on PostgreSQL 16 and found gaps that most guides skip. The SQL is in our read-only role guide:

  • The read-only setting is a default, and a session can switch it off. The real barrier is the absence of the privilege.
  • A session can remove its own statement timeout.
  • A SECURITY DEFINER function can write on behalf of a read-only role, unless you revoke public execute access.
  • Table names stay visible even when the contents are not.
  • Row-level security with no policy returns zero rows.

Best for everyone. Use them under every other tool on this list.

Limits: They cannot express business rules such as a discount cap, a refund threshold, or an allowed status change. Their errors are not written for an agent. A role cannot protect what you granted it. Cost: free, and already in your database.

3. Interdict: open-source safety layer for Postgres

Interdict is an open-source safety layer that sits between whatever writes SQL and Postgres. According to its documentation, it parses each statement, applies a deterministic policy, measures what a write would change without executing it, holds high-impact changes for a person to review, and records writes so a person can undo them. It offers an MCP adapter for agents.

Measuring the real impact of a write and being able to undo it are strong ideas, and not many tools offer them.

Best for teams that run Postgres, want to self-host, and want live row-count measurement and an undo path.

Limits: Its documentation describes it as an alpha developer preview, and it supports Postgres only. It governs only the SQL sent through its adapter, so the agent must not have a direct connection. It holds and uses your database credentials, because it executes the statements. Its documentation also says it cannot intercept infrastructure API calls such as deleting a cloud volume.

4. SQLGuard MCP: open-source MCP safety layer

SQLGuard MCP is an open-source MCP server that sits between an AI agent and a database. According to its documentation, it classifies queries as read, write, or destructive, estimates their impact with EXPLAIN, and asks for confirmation before changes. It has modes that range from read-only to permissive.

It is quick to add for teams that already use MCP clients, and its classification of queries is simple to understand.

Best for developers who want a lightweight guard in front of an agent's SQL, on Postgres or SQLite.

Limits: It executes the queries, so it holds your connection string in its configuration. The agent still writes the SQL, and the tool filters it. Confirmation is passed back as part of the tool call. Custom rules, an audit log, and multiple connections are features of its paid version, according to its page.

5. sql-guardrail: open-source policy checker for SQL

sql-guardrail is an open-source Python library. Its function verify(sql, policy, context) checks a SQL statement against a YAML policy and returns a result. According to its documentation, it never touches your database and never rewrites your SQL.

It checks statement shape, always-true filters, allowlists of tables and columns, tenant isolation through a required predicate, an optional function allowlist, and caps against heavy queries.

Best for Python teams that want an in-process check with no network hop and full control over the policy file.

Limits: It is a library, so you write the policy in YAML, host it, and keep it up to date. Its documentation describes it as a beta project and lists what it does not catch, for example tenant isolation on a bare INSERT ... VALUES, for which it recommends database CHECK constraints or row-level security.

How do the five tools compare?

Tool Type Controls reads Checks changes Where it runs Holds write credentials
Claix Managed service Yes, with Retrieve Yes, with Guard Hosted by Claix No. Retrieve uses a read-only role, and Guard only checks
PostgreSQL controls Built into database Yes, with privileges Yes, with privileges & constraints Your database Not applicable
Interdict Open-source tool Through its adapter Yes Self-hosted (Postgres only) Yes, it executes statements
SQLGuard MCP Open-source MCP Through its tool Yes Self-hosted Yes, it executes queries
sql-guardrail Open-source library Checks SQL shape Checks DML against policy In your application No, it never touches the database

How do you combine them?

The tools work as layers.

  • Start with the database controls. A dedicated role with narrow privileges, column grants, and constraints.
  • Add Claix as the control layer. Retrieve for what agents read, and Guard for every INSERT, UPDATE, and DELETE.
  • Add an open-source tool for a specific need. For example, Interdict for live impact measurement and undo on Postgres, or sql-guardrail for an in-process check in a Python service.
  • Keep the agent away from write credentials. One executor function holds them and runs only what Guard allows.
  • Send irreversible changes to a person after a denial, and log every decision.

How do you choose?

  • You want one managed service for reads and changes: Claix.
  • You want the strongest possible foundation first: PostgreSQL's controls, always.
  • You run Postgres and want a self-hosted safety layer with undo: Interdict.
  • You use MCP clients and want a quick filter in front of SQL: SQLGuard MCP.
  • You have a Python service and want an in-process policy check: sql-guardrail.

A checklist for securing an agent's database access

  • Create a dedicated role with narrow privileges. Never use a superuser.
  • Grant SELECT on specific columns, or expose views.
  • Revoke public execute access from functions that write.
  • Do not give the agent a raw SQL session or write credentials.
  • Limit what each agent can read.
  • Return typed answers, not text.
  • Check every INSERT, UPDATE, and DELETE against rules before it runs.
  • Send irreversible changes to a person after Guard denies them.
  • Keep backups where the agent cannot reach them.
  • Log every request and every decision, and test with hostile scenarios.

Sources

Claix is a managed control layer between AI agents and your database. Claix Retrieve controls what they can read, and Claix Guard checks every INSERT, UPDATE, and DELETE they propose.

Frequently asked questions

What are the best tools for AI agent database security?

The essential ones are PostgreSQL's built-in controls as the foundation, plus a layer that controls reads and checks changes. Claix covers both as a managed service. Open-source tools such as Interdict, SQLGuard MCP, and sql-guardrail cover parts of the problem.

How do I secure an AI agent's access to a database?

Use a dedicated least-privilege role, limit what each agent can read, return typed answers instead of letting the agent write SQL, check every INSERT, UPDATE, and DELETE with rules outside the model, and log everything.

Is Claix better than open-source guardrails?

It depends on what you need. Claix is the better fit if you want one managed service for reads and changes and nothing to host. The open-source tools are better if you want to self-host, need undo or live impact measurement, or want an in-process check with no network call.

Do I still need PostgreSQL permissions if I use Claix?

Yes. Claix connects with a read-only role, and what that role can read is the ceiling. Database permissions and constraints are the foundation, and Claix adds business rules and an audit trail on top.

Does Claix run my INSERT, UPDATE, or DELETE statements?

No. Claix Guard only checks them and answers allow or deny. Your own code executes, with your credentials, and only after Guard returns allowed: true. Claix never touches your data.

What is the difference between Claix Retrieve and Claix Guard?

Retrieve controls what an agent can read. Guard checks what an agent wants to change. They share the same account and connection.

Does an AI model decide whether a change is allowed?

Not in Claix Guard. A model can help propose rules when you create them, and you approve those rules. The check itself is deterministic, so the same statement always gets the same allow or deny answer.

Are the open-source tools production-ready?

Some describe themselves as alpha or beta projects, so check each one's maturity, maintenance, and limits before relying on it in production.

Can I use more than one of these tools together?

Yes, and it is usually the best setup. Use the database controls as the foundation, a managed layer such as Claix for reads and changes, and an open-source tool for a specific need.

Do guardrails protect against prompt injection?

They limit the damage. Controls outside the model, such as privileges, deterministic checks, and typed answers, hold even if the model is manipulated. No control stops a model from being influenced by text it reads.

Top comments (0)