AI agents and text-to-SQL: limit what the agent can run

What it protects

• VERICTO-087, agent access (Team and Enterprise): an allowlist of tables and columns per identity, read or read-write. Start in observe, switch to enforce, and everything else is denied.
• VERICTO-085, sensitive columns (Team and Enterprise): at the proxy, a column tagged mask reaches the agent masked and a block one is not read. The Runtime API and MCP return the approved query (rewritten_query, approved_query), which your code must run instead of the original.
• VERICTO-001, 042, 010 and 011: the destructive SQL an LLM generates from an ambiguous request.
• VERICTO-090: tautologies such as OR 1=1, typical of an injected instruction.
• VERICTO-050 and 051: SELECT without LIMIT or SELECT * without WHERE, flagged so you see which agents read whole tables.

The identity depends on the mode: at the proxy it is the session's database user; in the Runtime API and MCP, the API key. Use one user or one key per agent. The allowlist is enforced at the proxy; in the other modes it is a decision your code honours.

Latency and availability

Proxy: one network hop and the evaluation in its own process.

For parsing and rule evaluation, the design target is p99 < 2 ms. It is a target, not a measurement: the proxy latency benchmark is not published yet.

Runtime API: one HTTP call per statement, before running it. We do not publish a figure for that round trip yet: measure it from your region. It has a safety limit of 100 requests per second per API key. MCP stays off the execution path, and each statement counts toward the validation quota.

The Runtime API, the Validation API and MCP run in Vericto Cloud, with a 99.5% SLA on Builder and 99.9% on Team and Enterprise (99.95% and 99.99% with a dedicated deployment). Service status is on the status page.

How to implement it

1. Create a database user for the agent and connect it through the TCP proxy (Postgres or MySQL): the agent does not change, only its connection string.
2. In the dashboard, create the agent's allowlist in observe, let it work and simulate the policy against its queries from the last 7 days.
3. Tag the sensitive columns (email, card, ID number) with mask or block.
4. Switch the allowlist to enforce: whatever is outside it is blocked with VERICTO-087.
5. Without a proxy (Oracle, SQL Server or an agent you cannot reconnect), call the Runtime API from the agent's SQL tool and run the query only if the answer is 200, using rewritten_query when it comes.
6. For coding agents (Claude Code, Copilot, Kiro), connect the MCP server so they check the SQL with check_sql while they write it.

Coming soon: the Vericto SDKs for Python and Node, with LangChain and LlamaIndex integrations that will ask the Runtime API before every execution. They are not published on PyPI or npm yet; until then, use the proxy or the Runtime API directly.

When not to use this option

• As the only defence. Vericto is defence in depth: your database's roles, permissions and row-level security are still the first line. If the agent only reads a fixed set of data, a view or a read-only replica with its own role may be enough.
• To detect prompt injection. Vericto does not see the prompt: it limits what a successful injection can do with SQL.
• MCP as a control. An agent can ignore the verdict. To enforce the rules at runtime, use the proxy.
• Views, functions and triggers. Vericto does not know your schema: a view or a function over a table does not resolve to that table in the allowlist.

Plan availability

Prices and every limit on Pricing.

Other architectures

• All reference architectures
• Web application
• Microservices and Kubernetes
• Data warehouse and analytics
• Data pipelines
• CI/CD and migrations
• Serverless and edge
• Multi-tenant SaaS
• Enterprise and regulated