- Cómo responder a la “triple amenaza letal (lethal trifecta)” que permite abusos por parte de los usuarios
- Los agentes LLM que siguen instrucciones en lenguaje natural de forma literal tienen una vulnerabilidad estructural: al no separar datos e instrucciones, pueden ejecutar incluso instrucciones maliciosas incrustadas en texto externo
- Cuando se combinan exposición a contenido externo, acceso a datos privados y capacidad de comunicación hacia el exterior, se forma la “triple amenaza letal”, y el riesgo de que un error menor escale a un incidente de seguridad grave se multiplica
- Casos reales incluyen el parche de vulnerabilidad de Microsoft Copilot (junio), el mal uso del bot de atención al cliente de DPD (enero de 2024) y la demostración de exfiltración de datos basada en PDF en el agente de Notion AI (19 de septiembre)
- Los principios de defensa son desarmar la tríada, aislar los modelos no confiables y controlar las comunicaciones; también se proponen diseños seguros que aceptan restricciones funcionales, como la arquitectura dual de LLM CaMeL de Google
- La industria reconoce que reforzar solo el entrenamiento no basta, y que, como sugieren el riesgo de combinar plugins MCP y los retrasos en lanzamientos de productos (por ejemplo, el aplazamiento de funciones de IA de Apple), hace falta un cambio de diseño basado en un margen probabilístico de seguridad
Definición del problema central: no separar datos e instrucciones y la “triple amenaza letal”
- Los LLM procesan el texto de entrada como predicción continua de palabras, por lo que usan un modelo de interpretación unificado: responden preguntas e intentan ejecutar órdenes
- Si en un documento externo se inserta una instrucción maliciosa como “copiar el disco duro y enviarlo al correo del atacante”, durante una tarea de resumen puede surgir el riesgo de ejecución colateral
- Si en un mismo sistema coexisten exposición a contenido externo + acceso a datos privados + una vía de salida al exterior, se configura la triple amenaza letal (lethal trifecta)
- La triple amenaza letal es un concepto propuesto por el investigador de seguridad Simon Willison; cuando los tres elementos están abiertos al mismo tiempo, la inevitabilidad del abuso aumenta
Señales tempranas y casos reales
- En el verano de 2022 apareció de forma independiente el término prompt injection, poniendo el foco en el riesgo de una obediencia domesticada
- En enero de 2024 se confirmó que el bot de atención al cliente de DPD seguía instrucciones para responder con insultos, lo que llevó a la suspensión del servicio
- En junio de 2025 se descubrió una vulnerabilidad de la tríada en Microsoft Copilot, se distribuyó un parche silencioso y se indicó que no hubo reportes de explotación real
- El 19 de septiembre de 2025, el investigador Abi Raghuram demostró que un agente de Notion AI con acceso a documentos, bases de datos y web podía sufrir exfiltración de datos mediante un PDF manipulado
Por qué es difícil bloquearlo: fallas probabilísticas y canales indirectos
- Aunque se definan reglas de prioridad en el system prompt, sigue existiendo un desliz probabilístico, como fallar 1 de cada 100 veces
- Incluso si se añaden instrucciones de seguridad como “detectar señales dañinas”, persiste la posibilidad de que alguna vez las deje pasar
- Bloquear la comunicación saliente es clave, pero prohibir solo el envío de correos no basta: es posible filtrar datos mediante logs de solicitudes web, por ejemplo codificando valores secretos en la ruta de una URL
- El simple hecho de permitir acceso web puede convertirse en una vía de exfiltración de datos
Estrategia de defensa 1: no construir la tríada
- Eliminar хотя бы uno de los elementos reduce drásticamente el riesgo
- Si se limita la entrada a fuentes generadas y validadas internamente, se puede eliminar la exposición externa
- También funciona una estrategia de reducir el alcance, por ejemplo cuando un asistente de programación solo trabaja con una base de código confiable, o un altavoz inteligente procesa únicamente comandos de voz
- Sin embargo, en tareas como la gestión de correo electrónico, que por naturaleza manejan datos externos, es difícil eliminar por completo ese factor
Estrategia de defensa 2: aislamiento del modelo no confiable y privilegio mínimo
- Un artículo de Google de marzo recomienda clasificar como “modelo no confiable” al modelo que entra en contacto con datos externos y aislar la información sensible
- Recursos como el correo electrónico, que son privados pero también reciben entradas externas, ya cumplen dos de los tres elementos y quedan en un estado de alto riesgo
- Mediante privilegios mínimos, sandboxing y límites de contexto, se separa el acceso a secretos internos y credenciales
Estrategia de defensa 3: restricciones del modelo y separación arquitectónica
- Reforzar patrones de rechazo con datos de entrenamiento es necesario, pero no es una condición suficiente
- CaMeL de Google separa funciones usando dos LLM
- El modelo confiable convierte el lenguaje natural del usuario en código restringido
- El modelo no confiable solo realiza relleno de espacios dentro de un flujo estrictamente restringido, lo que permite obtener propiedades de seguridad
- A cambio, acepta la restricción funcional de reducir el rango de tareas posibles
Riesgo en el ecosistema de consumo y plugins: el caso de MCP
- Al añadir apps auxiliares con Model Context Protocol (MCP), la composición de capacidades puede formar de manera accidental la triple amenaza letal
- Incluso si cada MCP es seguro por separado, la seguridad de la combinación puede romperse, por lo que se requiere instalar lo mínimo y verificar la procedencia
Señales de la industria: retrasos en lanzamientos y giro conservador
- En 2024, Apple anunció funciones como “reproducir el podcast recomendado por Jamie”, pero optó por retrasar el lanzamiento ante la preocupación de que pudieran activar la tríada
- El hecho de que incluso en la versión más reciente de iOS de septiembre de 2025 no haya grandes funciones de IA y el enfoque se haya desplazado a traducción y mejoras de interfaz refleja lo difícil que es el problema en la práctica
Checklist práctico: qué hacer
- Modelado de riesgos: identificar explícitamente qué elementos están abiertos entre entrada externa, datos sensibles y salida al exterior, y mapear si existe la triple amenaza
- Diseño de fronteras: limitar el modelo no confiable a un buffer de solo lectura, desviar secretos y tokens mediante un servicio intermediario separado y bloquear el acceso directo
- Bloqueo de salidas: restringir con listas de permitidos canales de exfiltración como correo, solicitudes web y carga de archivos
- Motor de políticas: ejecutar solo llamadas a herramientas autorizadas y convertir lenguaje natural → política estructurada antes de ejecutar instrucciones
- Auditoría y guardrails: gestionar las fallas probabilísticas con conjuntos de prueba de prompt injection, automatización de red team y registro de sesiones/monitoreo de tasas de rechazo
- Aceptar trade-offs funcionales: se plantea la necesidad de una transformación cultural de ingeniería que acepte sacrificar parte del rendimiento y la autonomía para asegurar un margen probabilístico de seguridad
Conclusión
- Se acumulan las advertencias de que, si los tres elementos de la tríada permanecen abiertos, inevitablemente se encontrarán vulnerabilidades
- Desarmar la tríada, aislar los modelos no confiables, controlar las salidas y usar una arquitectura con separación de roles son hoy las medidas más realistas disponibles
- A largo plazo, será necesario un cambio de ingeniería de software: abandonar la obsesión por el determinismo e incorporar al diseño un margen probabilístico de seguridad
Aún no hay comentarios.