Acceso de agentes.

Resumen

Un agente con acceso a la base de datos puede recibir instrucciones inyectadas en cualquier texto que lea: un ticket, un email, una fila. Vericto no ve el prompt, solo el SQL, así que no intenta detectar la inyección. Limita lo que una inyección exitosa puede hacer: el agente solo usa las tablas y columnas que le diste.

La decisión se toma sobre el AST de cada query, como cualquier otra regla: la misma query recibe siempre la misma decisión. Lo que queda fuera de la allowlist se reporta con la regla VERICTO-087.

El modelo

Una política pertenece a una identidad en una base de datos y deniega por defecto. Cada entrada es una tabla (con esquema opcional), sus columnas (todas, *, o una lista) y el acceso: read o read_write. Una identidad con política y sin entradas no puede usar ninguna tabla. Una identidad sin política se comporta como antes: las allowlists son opcionales por identidad.

• Observar (observe): lo que queda fuera de la allowlist se marca (FLAGGED) y nunca se bloquea. Una política nueva empieza así.
• Aplicar (enforce): se bloquea (BLOCKED, VERICTO-087).
• El DDL (CREATE, ALTER, DROP, TRUNCATE, GRANT…) siempre se deniega a una identidad con política, y también las sentencias que cambian la identidad o la resolución de nombres (SET ROLE, SET search_path, USE).
• PREPARE/EXECUTE no se permiten con una política. Las sentencias SQL PREPARE, EXECUTE y DEALLOCATE se deniegan (needed: ddl), porque la allowlist no ve la sentencia que ejecutan. Los prepared statements del protocolo, los que usan los drivers y los ORMs, no cambian: el proxy evalúa su texto al prepararlos.

Qué cuenta como acceso

• Toda columna que la sentencia menciona: la proyección, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, subqueries, CTEs, RETURNING y las columnas que escriben INSERT y UPDATE. Un filtro cuenta porque permite sondear valores. Es más estricto que las columnas sensibles, que solo cuentan la proyección.
• Toda tabla mencionada necesita su entrada, aunque no se lea ninguna columna (SELECT count(*) FROM t).
• SELECT *, t.* y las referencias a la fila completa necesitan que la entrada de la tabla sea *.
• Escribir (INSERT, UPDATE, DELETE, MERGE, COPY … FROM) necesita read_write en cada tabla destino.
• Los catálogos del sistema (information_schema, pg_catalog, mysql, performance_schema, sys) se deniegan salvo que una entrada nombre ese esquema.
• Sin esquema = el esquema por defecto. Una entrada sin esquema es la tabla del esquema por defecto (public en Postgres, o el que configures), calificada o no en la query; no la de cualquier esquema. Una tabla de otro esquema necesita una entrada con ese esquema. Ante la duda, se deniega: una columna sin calificar en una query con varias tablas tiene que estar permitida en todas. Califica la columna si el mensaje lo pide.
• Los nombres se comparan como en tu base de datos. En Postgres, User (creada con comillas) y user son dos tablas, y también dos columnas; el árbol las muestra como las ve el tráfico. En MySQL, los nombres de tabla y de base de datos se comparan exactamente y los de columna sin distinguir mayúsculas.
• Con una política en enforce, una query que no se puede analizar se bloquea: no se puede demostrar que se quede dentro de la allowlist.

Precedencia con las columnas sensibles

Una columna bloqueada o enmascarada sigue bloqueada o enmascarada aunque esté permitida. En orden:

1. Una etiqueta sensible block siempre gana (VERICTO-085).
2. Fuera de la allowlist: se deniega (VERICTO-087). En observe se marca y la evaluación sigue.
3. Permitida pero etiquetada mask: se devuelve enmascarada, y el evento se atribuye a VERICTO-085.
4. Si no, permitida.

La identidad en cada modo

• Runtime API, CLI, Validation API y MCP: la API key que hace la llamada. Usa una key por agente. En la CLI, la Validation API y MCP, pasa el database_id: sin él se aplica la única política de la key en el workspace, y si tiene políticas en varias bases la petición se rechaza.
• Proxy TCP: el usuario de base de datos de la sesión (el user del inicio de sesión de Postgres, el usuario del handshake de MySQL), comparado exactamente. Una política para el usuario X solo se aplica a las sesiones como X. Para un proxy dedicado al agente, crea la política para el usuario con el que se conecta.

La garantía en cada modo

En todos los modos Vericto devuelve la decisión y la aplicación ejecuta la query. Solo el proxy TCP está entre la query y la base de datos.

Cómo configurarla

En Bases de datos → una base → Acceso a datos → Acceso de agentes: elige la identidad (una API key del workspace o un usuario de base de datos), el acceso por defecto (solo lectura o lectura y escritura) y marca tablas y columnas en el esquema observado. Las columnas sensibles aparecen marcadas en el mismo árbol (◐ enmascarar, ⛔ bloquear). Crear y editar políticas es del owner y los admins; el resto del equipo las ve.

El esquema sale del tráfico. Vericto nunca se conecta a tu base de datos: el árbol muestra las tablas y columnas que mencionaron tus queries recientes. Una tabla que no aparece se agrega a mano. Dos plantillas ayudan a empezar: «solo lectura: estas tablas» y «todo excepto estas tablas».

Los cambios llegan a cada proxy en su siguiente sincronización de reglas, sin reiniciar, y la API los usa en la siguiente evaluación.

Esquema por defecto

En Acceso de agentes, Esquema/base de datos por defecto dice qué significa una entrada sin esquema en esta base. MySQL: la base de datos a la que se conecta tu aplicación. Postgres: normalmente public, que es lo que se usa si lo dejas vacío. En MySQL, vacío significa que una entrada sin esquema solo cubre los nombres sin calificar. Lo configuran el owner y los admins, y cada cambio queda en el registro de auditoría.

En las sesiones del proxy TCP sobre MySQL manda la base de datos de la conexión. El proxy usa, para cada sesión, la base de datos con la que se conectó el cliente, porque es la que esa sesión usa; el valor del dashboard se aplica cuando el cliente se conecta sin base de datos, y en la Runtime API, la CLI, la Validation API y MCP. Un USE posterior se deniega.

Prisma. En MySQL, Prisma califica cada tabla con el nombre de la base de datos (`shop`.`User`): configura shop como base de datos por defecto y las entradas sin esquema la cubren. En Postgres, Prisma pone comillas en cada nombre ("public"."User"): la tabla es User con mayúscula, distinta de user, y así aparece en el árbol. Cuando el tráfico muestra una tabla con y sin el esquema por defecto (public.orders y orders), las plantillas agregan una sola entrada sin esquema.

Simular antes de aplicar

Simular reproduce las queries de esa identidad en esa base de los últimos 7 días (hasta 2.000) con el borrador, sin guardarlo, y dice cuántas habría bloqueado, con enlaces a cada evento. Es solo una evaluación: no se envía nada a tu base de datos y no se registra nada. Con la telemetría en modo sanitized se reproduce el texto sanitizado: los literales cambian, pero las tablas, columnas y tipos de sentencia se conservan, que es lo que decide una allowlist.

El orden recomendado: crear la política en observe, dejar que el agente trabaje, simular, ajustar y pasar a enforce.

Audit trail

Cada query lleva su identidad en el audit trail: la API key o el usuario de base de datos que la emitió, el modo de su política y lo que se denegó (tablas y columnas, nunca valores). Cada cambio de una política (creada, editada, cambio de modo, borrada) queda en el registro de auditoría del workspace, con quién lo hizo y el antes y el después.

Límites

• Es defensa en profundidad: los roles, permisos y el row-level security de tu base de datos siguen siendo la primera línea.
• Vericto no conoce tu esquema: una vista, función o trigger sobre una tabla no se resuelve a esa tabla. Una vista se permite por sí misma.
• Las llamadas a funciones no se restringen aquí.
• Si renombras una tabla o columna, la allowlist no se actualiza sola.

Ver también

• Columnas sensibles
• Agentes de IA (MCP)
• API Keys
• Audit trail