ALL PLANS · CUSTOM RULES FROM BUILDER

Database policies for AI agents, tested before they enforce

Write your own rules on the AST, keep them in observe while the agent works, simulate them against your real traffic and move them to enforce once the log is clean. If an agent goes wrong, you block it on every path with one click.

Start free Read the docs
A custom rule in YAML, as the documentation describes it. It starts in monitor.

The standard rules cover what is destructive. Your business has more rules

The 42 standard rules block DELETE and UPDATE without WHERE, DROP, TRUNCATE and risky DDL. They do not know that in your stack the payments table is never touched without a WHERE, or that your support agent has no business there. That is a policy, and in Vericto it is written, tested and enforced by the same deterministic engine that decides everything else: same statement, same rules, same verdict.

Your own rules, as code

A custom rule is a YAML condition on the statement's syntax tree: the node type, the table and the predicate. There is no model and no variance: the statement matches the condition or it does not.

  • Create it in the dashboard or through the API (POST /rules/custom). The condition is checked as you type, and before saving you see a diff against the saved version.
  • Every match is in the audit trail with the rule's code (CUSTOM-001) and the name you gave it.
  • Up to 5 custom rules on Builder, 20 on Team and unlimited on Enterprise.

Observe first, enforce later

Every layer starts without blocking anything, so you see what it would do before it does it:

  • The workspace: in observe mode, a 7-day window when you connect your first database, every BLOCK becomes a FLAG. The dashboard shows what would have been blocked and by which rule.
  • Each custom rule: starts in monitor; it is evaluated and recorded, and never blocks. "Promote to enforce" tells you what the rule will do in your workspace and links its latest simulation, or warns you if you did not simulate it.
  • Each agent: its allowlist of tables and columns starts in observe: anything outside it is flagged with VERICTO-087, and blocked only in enforce.

Simulate against your real traffic

The rule simulator replays a change against your workspace's query history (up to 30 days on Builder, 90 on Team and, by contract, up to 180 on Enterprise) and tells you which legitimate flows it would have blocked. An agent's allowlist is simulated against its queries of the last 7 days. Nothing runs against your database.

Unbounded reads and sensitive data

  • A SELECT without LIMIT, FETCH or TOP is flagged with VERICTO-050, in all six dialects.
  • The per-agent allowlist decides which tables and columns each identity reads or writes (Team and Enterprise).
  • Sensitive columns are blocked, flagged or returned masked (Team and Enterprise).

A per-agent kill switch

When an agent does something it should not, you stop it first. In Incident response → Block an agent, the owner or an admin picks the target (an API key, a database user, a registry principal or every agent in the workspace), writes the reason and confirms. On every plan. The block does not touch the allowlist or the rules: unblock, and everything is as it was.

  • Runtime API, SDKs, MCP check_sql and CLI: at once. The next call gets BLOCKED with VERICTO-105 and a message telling the agent not to retry and to ask a person.
  • TCP proxy: at its next rule sync (300 seconds by default, configurable down to 30), as an allowlist that allows no table. Any vericto-proxy with agent access (4.8.0 or later) enforces it with no upgrade: the statement is refused with VERICTO-087.
  • While the workspace is in monitor mode or in an observe mode window, a proxy older than 4.18.0 only flags the blocked agent's statements, without refusing them. The dashboard warns you when you block.
  • Every block and unblock is in the audit log with the actor, the reason and the time, and is announced on the workspace's channels.

Limits

  • It is defence in depth: your database's roles, grants and row-level security remain the first line.
  • Vericto sees the SQL, not the prompt: it does not try to detect an injection, it limits what the statement can do.
  • A simulation is evidence, not proof: a flow that did not run in the window is not covered.

Keep reading

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