Seguridad y BYOK
Cómo Verica protege tus claves y aísla tus datos — cifrado de credenciales y aislamiento por workspace.
Verica orquesta evaluaciones sobre tu proveedor de LLM con tu clave. Esta página describe cómo se protege esa clave, cómo se separan los datos entre clientes, y qué sale de Verica y qué no.
BYOK: tu clave, cifrada
Cada credencial se protege con cifrado por sobre (envelope encryption):
- Se genera una clave de datos aleatoria de 256 bits, distinta para cada credencial.
- Tu API key se cifra con esa clave usando AES-256-GCM.
- La clave de datos se envuelve con RSA-OAEP de 3072 bits (SHA-256), usando una clave pública.
La clave en texto plano nunca se guarda ni se registra en ningún log. En la interfaz solo se ve su huella — los primeros tres caracteres y los últimos cuatro, del estilo sk-…AB12 — que sirve para reconocerla y no revela nada.
La garantía principal
Lo importante no es el algoritmo, sino dónde vive cada mitad del par de claves:
- La aplicación web, que es la que está expuesta a internet, tiene solo la clave pública. Puede guardar credenciales nuevas, pero no tiene forma de abrirlas.
- El worker, que no recibe tráfico entrante, tiene la clave privada. Descifra una credencial únicamente en el momento en que hace la llamada al proveedor.
La aplicación expuesta a internet no puede, físicamente, leer las claves de tus proveedores de modelos. Esa propiedad la impone la arquitectura, no una política.
Como defensa adicional, el servicio web se niega a arrancar si encuentra la clave privada en su entorno. Y los mensajes de error de los proveedores se limpian de cualquier cadena con forma de clave antes de guardarse.
Las credenciales se pueden revocar y borrar. Al agregar una, Verica la valida con una llamada mínima al proveedor, no con un trabajo completo.
Aislamiento entre clientes
El límite de aislamiento es el workspace. Los proyectos organizan, no aíslan.
Hay tres capas, y las tres tendrían que fallar a la vez para que se filtrara una fila:
Row-Level Security en PostgreSQL
Cada tabla con datos de clientes tiene RLS activado y forzado — forzado significa que la política se aplica también al dueño de la tabla, que es como se conecta la aplicación.
La política compara el workspace_id de la fila contra la variable de sesión que se fija por transacción. Falla cerrada: sin esa variable, las consultas ven cero filas y los inserts se rechazan. No hay un modo "ver todo" al que caerse.
Acotado en la aplicación
Además, cada camino de acceso a datos se acota al workspace de quien llama, en el código. Así el aislamiento se sostiene aunque una consulta esté mal escrita. Los trabajos en segundo plano llevan su workspace en la carga del trabajo y quedan sujetos a lo mismo.
Roles de base de datos
La aplicación se conecta con un rol de mínimo privilegio que no puede saltarse RLS. Las migraciones usan un rol dueño distinto, que la aplicación nunca usa en tiempo de ejecución.
Autenticación: código de un solo uso por email, sin contraseñas — no hay contraseña que robar, reutilizar o filtrar. Los roles (admin, editor, viewer) se otorgan por membresía explícita y se resuelven en cada petición. El rol de solo lectura está disponible en Pro y Enterprise.
Los tokens de API se guardan como hash SHA-256 con un prefijo visible, se pueden revocar, admiten expiración y quedan atados a un proyecto. Ver Integración con CI.
Qué sale de Verica y qué no
Todo el uso de LLM en el producto corre sobre tu clave. Eso incluye la IA asistiva: la generación de casos y el análisis de fallos.
Las funciones asistivas usan la clave de tu proveedor configurada. Verica no usa una clave de modelo compartida para tus prompts, salidas o artefactos de evaluación.
Va a tu proveedor, con tu clave: el prompt (sistema, mensajes y definiciones de herramientas), los valores de las filas interpolados en él, la salida que se está juzgando, y las consignas de los jueces.
Se queda en Verica: los datasets y golden sets, la configuración y calibración de los criterios, tus anotaciones humanas, el historial de ejecuciones, veredictos, puntajes y métricas de concordancia, las versiones de prompts, la configuración del gate y sus veredictos congelados, las credenciales cifradas y el contenido cifrado de las trazas.
Como se admite cualquier endpoint compatible con la API de OpenAI mediante una base_url propia, puedes apuntar Verica a tu propio endpoint autoalojado — y entonces tus datos no salen de tu infraestructura en absoluto.
Verica no hace de proxy de tu tráfico a través de una clave compartida, y tus prompts y salidas no se usan para entrenar ningún modelo. Donde el proveedor lo permite, se pide explícitamente no persistir la petición del lado del proveedor.
Trazas de producción
Las trazas reciben el trato más estricto, porque traen contenido real de usuarios:
- El receptor OTLP se autentica con un token de permiso ingest.
- El payload se sella con la clave pública antes de encolarse — el contenido de la traza nunca pasa por Redis en claro.
- El worker redacta datos personales — emails, teléfonos, tarjetas — antes de persistir nada.
- La entrada, la salida y el árbol de spans, ya redactados, se cifran con el mismo esquema que las credenciales.
- Para mostrar una traza, la interfaz se la pide al worker: la clave privada nunca llega al servicio expuesto a internet.
En claro queda a propósito la metadata operativa — modelo, proveedor, tokens, costo, latencia, sesión, tags, nombres y cantidad de spans — más previews ya redactados de unos 160 caracteres, que permiten listar, filtrar y buscar sin descifrar nada.
Secretos y arquitectura
Todos los secretos son variables de entorno del lado del servidor. Lo único que llega al navegador es la URL pública de la aplicación. Cada servicio valida su entorno contra un esquema al arrancar y falla rápido, incluida la comprobación de que los secretos del worker no aparezcan en el servicio web.
La arquitectura son tres piezas: la aplicación web (expuesta), un worker en segundo plano (sin tráfico entrante) y las bases de datos. El worker es el único componente que tiene la clave privada de las credenciales.
El tráfico de usuario va por TLS, y las llamadas a proveedores por sus endpoints HTTPS.
Alcance honesto
Esta sección enumera lo que Verica no afirma hoy. Un exceso de promesa cuesta más caro que un "todavía no" claro.
- Los prompts y el contenido de los datasets no están cifrados a nivel de columna. El contenido de las trazas de producción es la excepción. Los datasets y prompts están protegidos por el aislamiento entre clientes y por lo que provea la plataforma gestionada, no por un cifrado de aplicación. Las claves gestionadas por el cliente están en el roadmap.
- El cifrado en reposo del disco lo provee la plataforma de hosting, no lo implementa Verica.
- No hay certificación SOC 2 ni ISO 27001. Tampoco un programa formal de bug bounty, ni una prueba de penetración de terceros, ni un pipeline formal de SAST/DAST.
- No hay garantías de residencia multi-región por el momento.
- El historial de ejecuciones y calificaciones queda registrado, pero un registro de auditoría dedicado y a prueba de manipulación de las acciones administrativas está en el roadmap.
- SSO (SAML/OIDC), MFA y SCIM están en el roadmap, no disponibles.
- Los sub-procesadores son la plataforma de hosting, las bases de datos gestionadas, el proveedor de email para los códigos de acceso, y los proveedores de modelos que elijas vos.
Con gusto recorremos la arquitectura con quien haga la revisión de seguridad.
Divulgación responsable
Si encuentras una vulnerabilidad, escribe a [email protected]. Pedimos no abrirla como issue público y darnos una ventana razonable antes de divulgarla. Confirmamos la recepción y mantenemos informado el avance.
Siguientes pasos
- Planes y límites — retención y qué se purga.
- Proyectos — por qué un proyecto no es un límite de seguridad.