Centro de confianza
Triggerfish aplica la seguridad en código determinista por debajo de la capa del LLM -- no en prompts que el modelo pueda ignorar. Cada decisión de política la toma código que no puede ser influenciado por inyección de prompts, ingeniería social ni mal comportamiento del modelo. Consulte la página completa de Diseño con seguridad como prioridad para la explicación técnica detallada.
Controles de seguridad
Estos controles están activos en la versión actual. Cada uno se aplica en código, se prueba en CI y es auditable en el repositorio de código abierto.
| Control | Estado | Descripción |
|---|---|---|
| Aplicación de políticas sub-LLM | ACTIVE | Ocho hooks deterministas interceptan cada acción antes y después del procesamiento del LLM. El modelo no puede eludir, modificar ni influir en las decisiones de seguridad. |
| Sistema de clasificación de datos | ACTIVE | Jerarquía de cuatro niveles (PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED) con aplicación obligatoria de escritura descendente. |
| Seguimiento de taint de sesión | ACTIVE | Cada sesión rastrea la clasificación más alta de datos accedidos. El taint solo escala, nunca disminuye. |
| Registro de auditoría inmutable | ACTIVE | Todas las decisiones de política se registran con contexto completo. El registro de auditoría no puede ser desactivado por ningún componente del sistema. |
| Aislamiento de secretos | ACTIVE | Las credenciales se almacenan en el llavero del SO o vault. Nunca en archivos de configuración, almacenamiento, registros ni contexto del LLM. |
| Sandboxing de plugins | ACTIVE | Los plugins de terceros se ejecutan en un sandbox doble Deno + WASM (Pyodide). Sin acceso a red no declarado, sin exfiltración de datos. |
| Escaneo de dependencias | ACTIVE | Escaneo automatizado de vulnerabilidades vía GitHub Dependabot. Se abren PRs automáticamente para CVEs upstream. |
| Base de código abierto | ACTIVE | La arquitectura de seguridad completa tiene licencia Apache 2.0 y es públicamente auditable. |
| Despliegue en infraestructura propia | ACTIVE | Se ejecuta íntegramente en su infraestructura. Sin dependencia de la nube, sin telemetría, sin procesamiento externo de datos. |
| Cifrado | ACTIVE | TLS para todos los datos en tránsito. Cifrado a nivel de SO en reposo. Integración con vault empresarial disponible. |
| Programa de divulgación responsable | ACTIVE | Proceso documentado de notificación de vulnerabilidades con plazos de respuesta definidos. Consulte la política de divulgación. |
| Imagen de contenedor endurecida | PLANNED | Imágenes Docker sobre base Google Distroless con CVEs cercanas a cero. Escaneo automatizado con Trivy en CI. |
Defensa en profundidad -- 13 capas independientes
Ninguna capa es suficiente por sí sola. Si una capa se ve comprometida, las capas restantes continúan protegiendo el sistema.
| Capa | Nombre | Aplicación |
|---|---|---|
| 01 | Autenticación de canal | Identidad verificada por código en el establecimiento de sesión |
| 02 | Acceso a datos con permisos | Permisos del sistema de origen, no credenciales del sistema |
| 03 | Seguimiento de taint de sesión | Automático, obligatorio, solo escalada |
| 04 | Linaje de datos | Cadena de procedencia completa para cada elemento de datos |
| 05 | Hooks de aplicación de políticas | Deterministas, no eludibles, registrados |
| 06 | MCP Gateway | Permisos por herramienta, clasificación de servidor |
| 07 | Sandbox de plugins | Sandbox doble Deno + WASM (Pyodide) |
| 08 | Aislamiento de secretos | Llavero del SO o vault, por debajo de la capa del LLM |
| 09 | Sandbox de herramienta del sistema de archivos | Jaula de ruta, clasificación de ruta, E/S limitadas por taint |
| 10 | Identidad y delegación de agentes | Cadenas de delegación criptográficas |
| 11 | Registro de auditoría | No se puede desactivar |
| 12 | Prevención de SSRF | Lista de denegación de IP + verificaciones de resolución DNS |
| 13 | Control de clasificación de memoria | Escribir a nivel propio, leer solo hacia abajo |
Lea la documentación completa de la arquitectura de Defensa en profundidad.
Por qué importa la aplicación sub-LLM
La mayoría de las plataformas de agentes de IA aplican la seguridad mediante prompts del sistema -- instrucciones al LLM que dicen "no compartas datos sensibles". Los ataques de inyección de prompt pueden anular estas instrucciones.
Triggerfish adopta un enfoque diferente: el LLM tiene cero autoridad sobre las decisiones de seguridad. Toda la aplicación ocurre en código determinista por debajo de la capa del LLM. No hay camino desde la salida del LLM hasta la configuración de seguridad. :::
Hoja de ruta de cumplimiento
Triggerfish está en fase pre-certificación. Nuestra postura de seguridad es arquitectónica y verificable en el código fuente hoy. Las certificaciones formales están en la hoja de ruta.
| Certificación | Estado | Notas |
|---|---|---|
| SOC 2 Tipo I | PLANNED | Criterios de servicios de confianza de Seguridad + Confidencialidad |
| SOC 2 Tipo II | PLANNED | Eficacia sostenida de controles durante período de observación |
| HIPAA BAA | PLANNED | Acuerdo de asociado comercial para clientes del sector sanitario |
| ISO 27001 | PLANNED | Sistema de gestión de seguridad de la información |
| Test de penetración de terceros | PLANNED | Evaluación de seguridad independiente |
| Cumplimiento RGPD | PLANNED | Arquitectura autoalojada con retención y eliminación configurables |
Una nota sobre la confianza
El núcleo de seguridad es de código abierto bajo Apache 2.0. Puede leer cada línea de código de aplicación de políticas, ejecutar la suite de pruebas y verificar las afirmaciones usted mismo. Las certificaciones están en la hoja de ruta. :::
Auditar el código fuente
La base de código completa de Triggerfish está disponible en github.com/greghavens/triggerfish -- licencia Apache 2.0.
Notificación de vulnerabilidades
Si descubre una vulnerabilidad de seguridad, por favor infórmela a través de nuestra Política de divulgación responsable. No abra issues públicos en GitHub para vulnerabilidades de seguridad.