Serverless y edge: una llamada a la API de runtime antes de ejecutar

Qué protege

Las mismas reglas que en el proxy, evaluadas sobre cada sentencia que la función envía. En un handler, las que más suelen dispararse:

• VERICTO-001 y VERICTO-042: DELETE y UPDATE sin WHERE, por ejemplo cuando un filtro opcional llega vacío y el constructor de queries lo omite.
• VERICTO-090: tautologías como OR 1=1, el patrón típico de una inyección SQL en una API pública.
• VERICTO-010 y VERICTO-011: DROP TABLE y TRUNCATE desde una función que nunca debería ejecutarlos.
• VERICTO-087 (Team y Enterprise): una allowlist de tablas y columnas por API key. Usa una key por función o por grupo de funciones: la API devuelve la decisión y tu código la respeta.
• VERICTO-085 (Team y Enterprise): con columnas en mask, la respuesta 200 trae rewritten_query. Ejecuta esa query en lugar de la original: la API no puede obligarte, solo el proxy TCP impone el enmascaramiento.

Latencia y disponibilidad

Cada sentencia suma una llamada HTTPS a api.vericto.com antes de ejecutarse. No publicamos todavía una cifra para ese round trip: mídelo desde la región o el punto de presencia donde corre tu función. El plano de control compartido corre en AWS us-east-1, así que una función lejos de esa región paga un round trip más largo.

Para no pagar el handshake TLS en cada invocación, crea el cliente HTTP fuera del handler y reutiliza la conexión. La API tiene un límite de seguridad de 100 solicitudes por segundo por API key; si tu concurrencia lo supera, pide que lo subamos.

Pools de conexiones. Las funciones abren muchas conexiones cortas, por eso suele ponerse un pool delante de la base, como RDS Proxy en AWS o Hyperdrive en Cloudflare. Vericto no se integra con ellos ni los reemplaza: la llamada ocurre en tu función, antes de usar la conexión, sea cual sea el pool.

La API de runtime, la API de validación y MCP corren en Vericto Cloud, con un SLA de 99,5% en Builder y de 99,9% en Team y Enterprise (99,95% y 99,99% con despliegue dedicado). El estado del servicio, en la página de estado.

Cómo implementarlo

1. Registra la base de datos con su dialecto (PostgreSQL, MySQL, Oracle, SQL Server, Snowflake o SQLite, por ejemplo D1) y copia su Database ID: guía de integración.
2. Crea una API key con el scope de la API de runtime (proxy:evaluate) y guárdala como secreto: en Lambda, en Secrets Manager o en una variable de entorno cifrada; en Workers, con wrangler secret put.
3. Donde la función ejecuta SQL, envía antes la sentencia a POST /api/v1/proxy/query con query, database_id y dialect, y con un timeout explícito.
4. Ejecuta solo con un 200, usando rewritten_query cuando venga. Con un 403, devuelve un error con el rule_code. Con un timeout, un error de red o un 429, aplica la política que elegiste: fail-closed o fail-open.
5. Empieza en modo observación: revisa en el dashboard lo que se habría bloqueado y luego aplica las reglas.
6. Revisa también las migraciones antes del deploy, con la CLI: ver CI/CD y migraciones.

Cuándo no usar esta opción

• Funciones dentro de una VPC, junto a Postgres o MySQL. Despliega el proxy TCP como servicio en esa VPC (ECS o Kubernetes) y apunta a él la conexión de la función: aplica las reglas sin cambiar el código. Ver aplicación web.
• Un proxy para Cloudflare D1 u otra base SQLite. No existe: SQLite se evalúa con la API de runtime (dialect: sqlite), la API de validación, la CLI y MCP, que es justo el camino de esta página.
• Lotes de SQL que no se ejecutan, como un archivo de migración: eso es la API de validación, con lotes de hasta 500 sentencias.
• No puedes cambiar el código de la función. La API de runtime necesita esa llamada; sin ella, solo el proxy TCP evalúa el SQL.

Disponibilidad por plan

Precios y todos los límites en Precios.

Otras arquitecturas

• Todas las arquitecturas de referencia
• Aplicación web
• Microservicios y Kubernetes
• Agentes de IA y text-to-SQL
• Data warehouse y analítica
• Pipelines de datos
• CI/CD y migraciones
• SaaS multi-tenant
• Enterprise y entornos regulados