Data masking for Postgres and MySQL, in the proxy

The risk that blocking a DELETE does not cover

Blocking a destructive DELETE protects the data from the agent. It does nothing against the opposite risk: an agent that reads what it should not. SELECT email, card_number FROM customers is harmless to the database and still puts personal and payment data into an LLM's context.

Three policies per column

• block: the query that reads the column is blocked.
• flag: the query passes and is recorded, with an alert.
• mask: the projection is rewritten to return the masked value.

If a query reads several tagged columns, the strictest wins: block, then mask, then flag. All are reported with rule VERICTO-085, and the audit trail says which column triggered each decision.

Four mask styles

In MySQL the styles return exactly the same as in Postgres. A masked column comes back as text, and any expression computed over it is masked with full.

What counts as a read

• Vericto tracks which columns every projected expression derives from, at any subquery or CTE level: an alias, a function, an aggregate or a CASE is still a read.
• SELECT *, whole-row references and COPY … TO on a table with tagged columns are blocked under mask and block: the message asks to list the columns.
• A column that only appears in WHERE, JOIN, GROUP BY or ORDER BY is not a read.
• Copying the value elsewhere (INSERT … SELECT, CREATE TABLE … AS) counts as a read and is blocked under mask.

Where it is a control and where it is a recommendation

Only the TCP proxy sits between the query and the database: there the proxy sends the rewritten SQL and the database returns the value already masked. The runtime API returns the rewritten query for the application to run; MCP returns it as the only approved query; the CLI and the validation API show it as a suggestion. For masking to be a control, the agent must reach the data only through the proxy.

Limits

• It is defence in depth: your database's column privileges, views and row-level security remain the first line.
• Vericto decides by column name, not content: it does not look for sensitive data in the values.
• Masking works on Postgres and MySQL (MariaDB and Aurora MySQL too). On Oracle and SQL Server, a mask tag blocks the query.
• ORMs that run SELECT * are blocked under mask until they list the columns, and a renamed column loses its tag.

Available on the Team and Enterprise plans. The dashboard shows whether your deployment's proxy and evaluator versions do not apply the tags yet.

Keep reading

• Docs: sensitive columns
• Agent access: an allowlist per agent
• Blog: what an AI agent with database access can do
• Audit trail