El riesgo que bloquear un DELETE no cubre
Bloquear un DELETE destructivo protege los datos del agente. No hace nada contra el riesgo contrario: un agente que lee lo que no debería. SELECT email, card_number FROM customers es inofensivo para la base de datos y aun así pone datos personales y de pago en el contexto de un LLM.
Tres políticas por columna
- block: la query que lee la columna se bloquea.
- flag: la query pasa y queda registrada, con alerta.
- mask: la proyección se reescribe para devolver el valor enmascarado.
Si una query lee varias columnas marcadas, gana la más estricta: block, luego mask, luego flag. Todas se reportan con la regla VERICTO-085, y el audit trail dice qué columna disparó cada decisión.
Cuatro estilos de máscara
| Estilo | Resultado |
|---|---|
full | [redacted] |
last4 | **** y los últimos 4 caracteres |
email | La primera letra y el dominio: a***@example.com |
hash | SHA-256 en hexadecimal |
En MySQL los estilos devuelven exactamente lo mismo que en Postgres. Una columna enmascarada se devuelve como texto, y cualquier expresión calculada sobre ella se enmascara con full.
Qué cuenta como lectura
- Vericto sigue de qué columnas deriva cada expresión proyectada, en cualquier nivel de subquery o CTE: un alias, una función, una agregación o un CASE siguen siendo una lectura.
SELECT *, las referencias a la fila completa yCOPY … TOsobre una tabla con columnas marcadas se bloquean bajo mask y block: el mensaje pide listar las columnas.- Una columna que solo aparece en WHERE, JOIN, GROUP BY u ORDER BY no es una lectura.
- Copiar el valor a otro sitio (
INSERT … SELECT,CREATE TABLE … AS) cuenta como lectura y bajo mask se bloquea.
Dónde es un control y dónde una recomendación
Solo el proxy TCP está entre la query y la base de datos: ahí el proxy envía el SQL reescrito y la base de datos devuelve el valor ya enmascarado. La API de runtime devuelve la query reescrita para que la aplicación la ejecute; MCP la devuelve como la única query aprobada; la CLI y la API de validación la muestran como sugerencia. Para que el enmascaramiento sea un control, el agente debe llegar a los datos solo a través del proxy.
Límites
- Es defensa en profundidad: los privilegios de columna, las vistas y el row-level security de tu base de datos siguen siendo la primera línea.
- Vericto decide por el nombre de la columna, no por su contenido: no busca datos sensibles en los valores.
- Enmascarar funciona en Postgres, en MySQL (también MariaDB y Aurora MySQL), en Snowflake y en SQLite (en SQLite, el estilo hash bloquea la query). En Oracle y SQL Server, una etiqueta mask bloquea la query.
- Los ORMs que hacen
SELECT *se bloquean bajo mask hasta que listen las columnas, y una columna renombrada pierde su etiqueta.
Disponible en los planes Team y Enterprise. El dashboard indica si las versiones del proxy y del evaluador de tu despliegue todavía no aplican las etiquetas.