Parse before it burns.

Vetro nació de una pregunta simple: ¿por qué usamos IA para protegernos de la IA, cuando el problema tiene una solución matemática? AST parsing determinístico — el mismo mecanismo que usa PostgreSQL internamente — aplicado como capa de seguridad entre tu LLM y tu base de datos.

Misión

Vetro existe para que los equipos de ingeniería puedan desplegar agentes de IA sobre bases de datos en producción con la misma confianza con la que despliegan código revisado por humanos.

El problema no es la IA. El problema es que entre el LLM y la base de datos no existe ninguna capa de seguridad determinística. Los permisos de base de datos son frágiles. Los allowlists de operaciones son superficiales. Y los modelos de ML para detectar queries peligrosas introducen exactamente el tipo de varianza estocástica que no quieres en el path crítico de tu sistema de producción.

Vetro resuelve esto con matemáticas, no con más IA.

Visión

En 2026, la mayoría de las aplicaciones SaaS tendrán al menos un agente de IA con acceso directo o indirecto a una base de datos en producción. Text-to-SQL, MCP servers, LangChain agents, Vercel AI SDK — el ecosistema está construyendo sobre bases de datos reales a una velocidad que los equipos de seguridad no pueden seguir con herramientas tradicionales.

Nuestra visión es que Vetro sea la capa de seguridad estándar para cualquier pipeline LLM-to-database, de la misma forma que HTTPS es la capa estándar para cualquier comunicación web. No opcional. No un add-on. La capa de defensa que está ahí por defecto.

El mercado de database security alcanzará $12.8B en 2025 (MarketsandMarkets). El segmento de AI-native database access control — donde Vetro opera — crece 3x YoY en 2025-2026.

Por qué AST parsing determinístico, no ML

Esta es la pregunta que más nos hacen. La respuesta corta: porque el problema tiene una solución exacta.

Una query SQL es un programa. Tiene una gramática formal, un árbol sintáctico definido, y semántica precisa. DELETE FROM users sin cláusula WHERE es destructiva en el 100% de los casos — no hay ambigüedad, no hay contexto que cambie esa afirmación, no hay distribución de probabilidad que calcular.

Un modelo de ML para detectar queries peligrosas tiene tres problemas fundamentales:

  • Falsos negativos: un modelo entrenado en queries históricas no conoce las queries que tu LLM específico va a generar mañana.
  • Falsos positivos: bloquear queries legítimas en producción es tan catastrófico como dejar pasar queries destructivas.
  • No certificable: no puedes incluir en un reporte de auditoría SOC2 que "un modelo de ML con 99.2% de accuracy" protege tus datos. Sí puedes incluir que "el AST parser bloquea determinísticamente cualquier UPDATE sin WHERE clause".

El AST parsing es reproducible, auditable, y produce el mismo resultado en el 100% de las ejecuciones con el mismo input. Es matemática, no estadística.

Valores

Precisión sobre cobertura

Preferimos hacer una cosa perfectamente — bloquear queries destructivas con certeza matemática — que hacer muchas cosas con incertidumbre. El scope de Vetro es deliberadamente estrecho.

Transparencia radical

Cada decisión de bloqueo incluye el nodo AST exacto, la regla activada, y la query segura sugerida. No somos una caja negra. Puedes auditar cada decisión que tomamos.

Velocidad sin compromiso

Sub-2ms en el path crítico no es un objetivo de marketing — es un requisito de diseño. La seguridad que añade latencia perceptible no se adopta. La que no se nota, sí.

Ingenieros primero

Vetro está construido por ingenieros para ingenieros. El onboarding en <8 minutos, la documentación técnica precisa, y el CLI para CI/CD son decisiones de producto, no de marketing.

Contacto

Para consultas de enterprise, partnerships o prensa, escríbenos a hello@vetro.dev.

Para soporte técnico, usa el chat en el dashboard o escribe a support@vetro.dev.

Para reportar vulnerabilidades de seguridad, consulta nuestra política de seguridad.