COMPARISON

Vericto vs. database roles

Roles and GRANTs are the first line of defense, and they stay that way. They decide which operations a user may perform on which objects. They do not look at the statement: whoever may DELETE from a table can delete one row or all of them.

What each one decides

SituationWith roles and GRANTsWith Vericto in front
A DELETE or UPDATE without WHEREIt runs if the role has the DELETE or UPDATE privilege on the table.Blocked by default, before it reaches the database.
DROP or TRUNCATEIt runs if the role owns the table or holds the corresponding privilege.Blocked by default.
Reading a column with personal dataColumn privileges or views, to be maintained for each role.The column is tagged as sensitive: the query is blocked, flagged or gets the masked value back (Postgres and MySQL).
Limiting an agent to certain tablesOne role per agent, with its GRANTs.An allowlist per agent, of tables and columns, evaluated on the AST.
Knowing what the agent tried to runThe database logs, if they are enabled.Every decision in the audit trail, with the rule and the AST node; signed exports.
Testing a policy changeIt is tested in another environment.The simulator evaluates it against real traffic, and observe mode flags without blocking.

Why a read-only role is not always enough

Many agents need to write: create a record, update a status, run a migration. Read-only access leaves them unable to do their job; write access also gives them the destructive statement. The database checks permissions, not the shape of the statement: UPDATE orders SET status = 'paid' WHERE id = 42 and the same UPDATE without WHERE need exactly the same privilege.

And even read-only, a SELECT email, card_number FROM customers puts personal and payment data into an LLM context.

What Vericto does not replace

  • Least-privilege roles, column privileges, views and row-level security remain the first line. Vericto is defense in depth.
  • Only the TCP proxy sits between the query and the database. The API, the CLI and MCP report the verdict; for it to be a control, the agent must reach the data through the proxy.
  • By default, a query that cannot be parsed goes through and is logged (fail-open); the workspace can switch to fail-closed.

How to use them together

  • One role per application or agent, with the minimum privileges it needs.
  • Vericto in front, through the proxy, for the rules on the statement: missing WHERE, DROP, TRUNCATE, sensitive columns and the agent's allowlist.
  • Observe mode first, to see what would be blocked before blocking it.

Try it on your own SQL

The Free plan includes 500K queries a month and 1,000 CLI and MCP checks, with no credit card.

Start free