Cómo detener la "triple amenaza letal" de la IA

• Los LLM tienen un problema estructural: no pueden separar código y datos, por lo que son vulnerables a ataques de prompt injection
• En particular, cuando se les otorga al mismo tiempo acceso a datos externos, lectura de secretos internos y capacidad de comunicarse con el exterior, se produce la llamada triple amenaza letal (lethal trifecta), que puede derivar en daños graves
• Los ingenieros de IA deben pensar como ingenieros mecánicos y, en lugar de un enfoque determinista, aceptar la incertidumbre de los sistemas probabilísticos y trabajar con márgenes de seguridad
• Así como los ingenieros victorianos sobrediseñaban para dejar margen frente a la incertidumbre de los materiales, los sistemas de IA también deben incorporar límites de seguridad, tolerancia al riesgo y tasas de error
• Igual que los puentes del mundo físico tienen límites de carga, ya es momento de establecer en los sistemas de IA normas con límites explícitos y márgenes de seguridad

---

El problema de seguridad inherente de los LLM

• Los modelos de lenguaje grandes tienen un defecto estructural: no pueden separar código y datos
• Por eso son vulnerables a los ataques de prompt injection
  • Se les engaña para que sigan instrucciones que el sistema no debería obedecer
  • En algunos casos, esto solo produce resultados vergonzosos, como hacer que un agente de soporte al cliente hable como pirata
  • En otros, causa daños mucho más destructivos

Triple amenaza letal (Lethal Trifecta)

• El peor impacto ocurre cuando se forma una "tríada letal"
• Sus tres componentes son
  • acceso a datos no confiables
  • capacidad de leer información confidencial importante
  • capacidad de comunicarse con el mundo exterior
• Si una empresa intenta dar a sus empleados un asistente de IA poderoso y le concede estas tres capacidades a la vez, los problemas graves son inevitables
• No solo los ingenieros de IA: los usuarios comunes también deben aprender a usar la IA de forma segura
  • instalar la combinación equivocada de apps puede crear accidentalmente esta tríada

Hace falta un cambio de mentalidad en la ingeniería de IA

Pensar como un ingeniero mecánico

• Una mejor ingeniería de IA es la primera línea de defensa
• Los ingenieros de IA deben pensar como quienes diseñan estructuras como puentes
  • entendiendo que un trabajo deficiente puede costar vidas

La lección de la ingeniería victoriana

• Las grandes construcciones de la era victoriana en Reino Unido fueron levantadas por ingenieros que no podían estar seguros de las propiedades de los materiales
  • en esa época, el hierro a menudo era de baja calidad por incompetencia o fraude
  • como resultado, los ingenieros optaron por la prudencia e integraron redundancia mediante el sobrediseño
  • el resultado fueron obras maestras que han perdurado durante siglos

El problema actual de la industria de seguridad en IA

• Los proveedores de seguridad para IA no están pensando de esta manera
• La programación tradicional es determinista
  • una vulnerabilidad de seguridad se considera un error que debe corregirse
  • una vez corregido, desaparece
• Los ingenieros de IA se han acostumbrado a esta forma de pensar desde sus años de formación
  • por eso actúan como si más datos de entrenamiento y prompts de sistema más inteligentes bastaran para resolver el problema

Un enfoque adecuado para sistemas probabilísticos

Los límites de los datos de entrenamiento y los prompts

• Los datos de entrenamiento y los prompts inteligentes sí reducen el riesgo
  • los modelos más avanzados e inteligentes de hoy son mejores que los anteriores o más pequeños para detectar y rechazar solicitudes maliciosas
• Pero no pueden eliminar el riesgo por completo
  • a diferencia de la mayor parte del software, los LLM son probabilísticos
  • su salida se determina mediante una selección aleatoria entre respuestas plausibles
  • por eso, un enfoque de seguridad determinista es inadecuado

Imitar la ingeniería del mundo físico

• Un mejor camino es imitar a los ingenieros del mundo físico
• Aprender a trabajar con sistemas impredecibles
  • en vez de luchar contra sistemas caprichosos que no se puede garantizar que funcionen como se pretende, trabajar con ellos
• Incorporar márgenes de seguridad, tolerancia al riesgo y tasas de error para manejar con mayor comodidad la imprevisibilidad

Estrategia de sobrediseño para la era de la IA

• Usar modelos más potentes de lo estrictamente necesario
  • reduce el riesgo de que sean engañados para comportarse de manera inapropiada
• Imponer límites a la cantidad de consultas que un LLM puede recibir de fuentes externas
  • ajustados al riesgo de daño causado por consultas maliciosas
• Enfatizar el principio de fallar de forma segura
  • si un sistema de IA necesita acceder a secretos, hay que evitar darle las llaves del reino

La necesidad de fijar límites de seguridad

• En el mundo físico, los puentes tienen límites de carga
  • aunque no siempre estén claramente visibles para los conductores, existen
  • lo importante es que esos límites dejan suficiente margen dentro del rango real que, según los cálculos, el puente puede soportar
• Ahora es momento de que el mundo virtual de los sistemas de IA adopte algo similar
• Es esencial diseñar sistemas con límites de seguridad claros y con margen

[GN⁺]

Comentarios en Hacker News

• Enlace al artículo archivado
• Esta es la segunda vez esta semana que un artículo de The Economist menciona la lethal trifecta. El primero fue Los sistemas de IA nunca serán completamente seguros — la “triple amenaza letal” a la que hay que responder, y me pareció la explicación más clara en medios de qué es el prompt injection y por qué es peligroso. Puede que yo sea un poco parcial porque me citan, pero aun así es un artículo que sí recomendaría a ejecutivos. Este artículo nuevo no me gustó tanto. Menciona que, como los LLM no son deterministas, es difícil corregir vulnerabilidades de seguridad, y por eso usa la analogía de “sobrediseñarlos” como si fueran puentes y prepararse para tolerancias. Eso podría aplicar a los puentes, pero no me parece una solución de raíz para vulnerabilidades de seguridad. Si un sistema cae ante prompt injection 1 de cada 100 veces, un atacante va a seguir probando variantes hasta lograrlo. Si bloqueas aunque sea uno de los elementos de la lethal trifecta (acceso a datos privados, exposición a instrucciones no confiables, canal de exfiltración), el ataque no se concreta
  • Los constructores de puentes casi nunca diseñan pensando en ataques adversariales. Y si lo hacen, suelen enfocarse más en que sea fácil moverlos y reubicarlos rápido que en volverlos robustos. En vez de un puente ultraresistente que sobreviva bombardeos, suele ser más rápido y barato poner un puente temporal adicional. Ver este caso concreto
  • Los LLM, igual que los humanos, no son deterministas. Por eso también se puede abordar su seguridad como se hace con las personas. Hay que dar solo el mínimo privilegio necesario mediante control de acceso basado en roles, y hacer que tareas riesgosas o costosas pasen por un proceso de aprobación. En organizaciones críticas de tecnología, infraestructura, defensa o finanzas, es básico modelar amenazas asumiendo que puede haber agentes de gobiernos extranjeros como Rusia, China, Israel o Corea del Norte mezclados dentro del equipo
  • En realidad, ambos artículos son el mismo artículo. The Economist publica cada semana al inicio de la edición una serie llamada “Leaders”, que resume y generaliza los reportajes de fondo de ese mismo número. O sea, aplican una estructura de pirámide invertida a todo el periódico (explicación de pirámide invertida). En este caso también, el artículo enlazado funciona como una versión resumida del reportaje completo sobre el tema
  • Yo pienso el problema de seguridad de los LLM como “¿qué pasaría si mi código pudiera caer ante ataques de ingeniería social?”. Los LLM, igual que los humanos, por más entrenamiento que reciban, inevitablemente pueden ser engañados. Si le das permisos de root a una computadora y además permites que cualquiera en el mundo converse con el LLM, al final será vulnerable sí o sí. Así como no le delegas autoridad ilimitada a una persona, tampoco deberías permitirle a un LLM acceder a datos no relacionados con quien hace la solicitud ni modificar datos de usuarios
  • El problema con decir que basta con cortar uno de los lados de la lethal trifecta es que esos tres elementos en realidad están entrelazados. Por ejemplo, contenido externo como el correo también puede ser información personal, y si se manda un email, el contenido de mi bandeja de entrada también puede terminar en manos del atacante. Además, correo, GitHub y similares son más útiles cuando pueden tanto recibir como enviar; poner servidores separados para cada función sería ineficiente
• Desde una perspectiva de ingeniería mecánica, este artículo se siente insuficiente. Eso de “solo hay que añadir resistencia” se dice mucho, pero en la práctica solo aplica si se entienden a detalle muchos modos de falla distintos. La lethal trifecta es apenas un modo de falla, y la “resistencia” se agrega para evitarlo. No es “este puente vibra demasiado, veamos cómo cruzar de forma segura un puente que vibra”, sino modificar el puente para que ni siquiera vibre en exceso
  • Siento que el mundo está perdiendo la cabeza. Siguiendo esa analogía del puente, sería como si desde hace tiempo supiéramos construir puentes, pero a veces el piso desapareciera de repente y la gente cayera al río, y en vez de discutir cómo evitarlo, dijéramos “pongamos una red abajo y atrapemos a todos los que se caigan”. Estamos gastando miles de millones sobre una tecnología esencialmente impredecible, y la respuesta parece ser solo agregar más barandales. No tiene sentido
  • En cuanto aparece la frase “coders need to” en un artículo, de inmediato pierdo el interés. La analogía misma se siente equivocada, y suena rara incluso para gente con experiencia real en el área. El ejemplo del periodista —“si en una empresa el LLM puede al mismo tiempo manejar datos no confiables, información importante y comunicación externa”— ya parte de una condición problemática. Muchas veces las empresas crean ese riesgo por priorizar funcionalidad por encima de seguridad. Decir que “como el LLM es no probabilístico, un enfoque determinista es inapropiado” es un salto lógico. Aunque no sea determinista, la lógica de sandboxing sigue siendo válida; dicho de otro modo, si estiras demasiado la analogía, termina siendo poco útil para el área. Sería mejor usar la terminología y el conocimiento del dominio, pero claro, eso haría el artículo menos atractivo
• ¿En serio el artículo daba a entender que las únicas soluciones eran limitar la velocidad y usar mejores modelos? Los ingenieros de software ya estudiaron esto hace décadas. Esta industria conoce las respuestas de seguridad; el problema es que no encajan con la actitud actual de sacar productos de IA a toda prisa
  • La IA también pertenece ya al mismo campo de TI, así que la conclusión sería más bien: “en realidad no entendemos la seguridad”. Decir que en IA hay descuido no refleja bien la realidad. Que no exista una forma de separar perfectamente los datos de los tokens de instrucción es una limitación fundamental, no mera negligencia. Decir “esto ya se resolvió hace décadas” es arrogante
  • Ese tipo de comentario de “la seguridad ya se resolvió hace décadas” aparece cuando una industria nueva se apura a recrear malos estándares previos para lanzar “productos de IA”. Basta ver casos como el del estándar MCP, que ya venía roto desde el principio; enfoques tipo “escribe mejor el prompt” ya rozan lo ridículo. El mayor problema es que casi todo el mundo en la industria de IA diseñó servidores MCP con acceso directo a la base de datos sin cuestionarlo demasiado. Es un buen ejemplo de que no porque algo se pueda hacer significa que se deba hacer, y por esta seguridad tan floja muchísimos productos de IA están siendo realmente comprometidos
  • La afirmación de “ya entendemos la seguridad” tampoco es cierta en la práctica. Y cuando pasas al problema humano, menos todavía; incluso gastando miles de millones en capacitación repetida, el efecto va disminuyendo. Hace poco incluso hubo casos de expertos de seguridad muy buenos que cayeron en phishing simple en YouTube
• Publicación original de @simonw: The lethal trifecta for AI agents, y también vale la pena ver esta publicación relacionada. Dejo además el debate relacionado en HN
• La lethal trifecta es el problema que ocurre cuando un LLM tiene al mismo tiempo acceso a datos no confiables, capacidad de ver información sensible y comunicación externa. La solución es reducir el riesgo gestionando los límites (permisos), lo cual es seguridad 101 bastante básica
  • Sí, pero en la práctica ahí aparece una tensión fuerte entre seguridad y funcionalidad. Si quieres que haga cosas útiles con datos personales, abres la puerta a vulnerabilidades de prompt injection. Además, juntar el mayor contexto relacionado posible ayuda bastante a la eficiencia del agente, pero si por eso separas o aíslas por completo al agente que lee entradas no confiables, su utilidad baja. Ver este blog relacionado
  • Estrictamente hablando, esto sigue siendo solo control de acceso básico (Access Control). En cuanto se conecta a internet, el riesgo se dispara. Si hubiera un investigador de seguridad realmente bueno, con un solo prompt injection podría tomar el control de todo el sistema, así que al menos una de las condiciones se cumpliría de inmediato
• Los LLM no distinguen entre prompt y datos. No existe algo como el bit NX (no-execute), ni hay ejemplos de algo parecido implementado. Claro, igual que la introducción del bit NX no logró detener por completo la ejecución remota de código, esto por sí solo tampoco sería una defensa perfecta. Hoy, el enfoque más realista es gestionar el proceso del agente LLM con mecanismos de seguridad tradicionales. Por ejemplo, ejecutarlo bajo una cuenta de usuario separada para limitar acceso a archivos, y además restringir red, hardware y cgroups. Aun así, si en los datos no confiables vienen instrucciones mezcladas, sigue existiendo el riesgo de que el LLM termine filtrando datos secretos. Y si el usuario copia hacia afuera la salida del LLM sin darse cuenta, se vuelve a abrir la vía de exfiltración
  • Cuando dicen que nadie ha creado algo parecido, me pregunto si alguien siquiera lo ha intentado de verdad, o si existe al menos entrenamiento relacionado. Los animales sociales hacen compartmentalization de manera natural. Hasta un perro puede notar la mirada de una persona y ocultar la existencia de comida. Yo mismo, al criar a un hijo, manejo la información por separado según vida social, conocimiento confidencial, datos personales del niño, información que aún le costaría procesar, mis pensamientos internos o cosas aprendidas de fuentes no confiables. La inteligencia importa, pero la sabiduría (wisdom) todavía no parece ser una consideración de primer nivel en el mundo de los LLM. Incluso cachorros y niños pequeños parecen ir por delante en capacidad de compartimentación
• Vi una cita llamativa en el reportaje de fondo relacionado: el sistema CaMeL propuesto por Google evita parte del riesgo de la lethal trifecta usando dos LLM. Uno accede solo a datos no confiables, y otro procesa todo lo demás. Un modelo de alta confianza traduce las instrucciones del usuario en código de alcance restringido, y el modelo no confiable rellena los huecos de ese código. Esta estructura da ciertas garantías de seguridad, pero a cambio limita mucho el tipo de trabajo que el LLM puede hacer. No lo conocía y me da curiosidad si realmente funciona. Me pregunto si garantiza seguridad de verdad en términos “absolutos”, qué restricciones impone y si podría ser una alternativa práctica. Fuente del artículo
  • Llevo tiempo pensando en el paper de CaMeL. Me parece un enfoque bastante bueno, pero implementarlo de verdad es bastante difícil y el sistema termina pudiendo hacer solo cosas bastante limitadas. Lo resumí en mi análisis
• Aparece la analogía de que “los ingenieros de IA también deberían pensar como ingenieros de verdad en áreas como la construcción de puentes, donde puede haber pérdida de vidas”. La idea sería algo como: “a los ingenieros de IA se les forma desde la escuela para creer que con más datos de entrenamiento y prompts más inteligentes basta para resolver el problema”
  • Aquí, eso de que “los ingenieros de IA deben pensar como ingenieros de verdad” no se refiere solo a no ser simples ingenieros de software, sino a pensar como ingenieros reales; ahora que el software también está dentro de puentes y autos, al menos deberían adoptar la forma de pensar de la ingeniería del mundo físico
  • Casi sugiere la idea de exigir licencias de ingeniería de software y hasta certificación ética. Pero como el software poco ético pero legal puede generar ganancias enormes, siento que una idea así sería difícil de aplicar en la práctica
  • La conclusión de pensar “esto se arregla con mejores datos de entrenamiento” es que al final tragedias como estas mismas terminan convirtiéndose en datos de entrenamiento
  • No hay que olvidar el rol del “arquitecto”, además del “ingeniero” de software
• Me pregunto si habría oportunidad de negocio en ofrecer como suscripción un producto de software que monitoree automáticamente cuentas de LLM y filtre/procese las entradas mediante pipelines por una tarifa razonable