Hay un supuesto que casi nadie cuestiona en las arquitecturas multi-agente: que el orquestador es de fiar. Los subagentes reciben instrucciones del orquestador, las ejecutan, devuelven resultados. El modelo de seguridad habitual se preocupa por lo que entra desde fuera —el usuario malicioso, el documento contaminado, la API comprometida—, pero raramente por lo que ocurre cuando el nodo que distribuye tareas ya viene roto de fábrica.
Eso es exactamente lo que hace interesante —y peligroso— el escenario del orquestador comprometido.
La arquitectura asume una jerarquía de confianza que nadie auditó
En un sistema multi-agente típico, el orquestador actúa como coordinador: descompone objetivos, delega subtareas, agrega resultados y toma decisiones sobre el flujo. Los subagentes —especializados en búsqueda, ejecución de código, acceso a bases de datos, comunicación externa— confían en que las instrucciones que reciben son legítimas porque provienen de arriba.
Este modelo reproduce una jerarquía corporativa, y tiene el mismo punto ciego: si comprometes al jefe, tienes acceso a todo lo que el jefe puede ordenar. La diferencia con un entorno humano es que los subagentes no tienen escepticismo natural, no leen el tono, no detectan inconsistencias de comportamiento. Ejecutan.
El problema no es teórico. MITRE ATLAS, el marco de tácticas adversariales específicamente diseñado para sistemas de ML y IA (https://atlas.mitre.org), documenta técnicas de manipulación de pipelines de inferencia, inyección en cadenas de razonamiento y compromisos de componentes intermedios. La táctica AML.T0051 —»LLM Prompt Injection»— se extiende de forma natural a escenarios donde el prompt inyectado no viene del usuario sino del propio orquestador.
Tres vectores para comprometer un orquestador
El primer vector es el más directo: prompt injection persistente en la memoria del orquestador. Si el sistema utiliza memoria episódica o semántica —y la mayoría de las implementaciones con LangChain, AutoGen o CrewAI lo hacen—, un atacante que consiga escribir en esa memoria puede modificar las instrucciones base que el orquestador transmitirá a los subagentes en interacciones futuras. No hace falta acceso en tiempo real. Basta con haber contaminado el contexto antes de que el orquestador lo lea.
El segundo vector es la suplantación de identidad del orquestador. En arquitecturas distribuidas donde los agentes se comunican mediante APIs internas o colas de mensajes, la autenticación entre nodos suele ser laxa o inexistente. Un componente externo puede emitir instrucciones con la firma —o simplemente el formato esperado— del orquestador legítimo. Los subagentes no verifican la cadena de custodia del mensaje; verifican, en el mejor caso, su estructura.
El tercer vector es más sutil: la manipulación del razonamiento del orquestador mediante datos de retorno envenenados. Si un subagente devuelve resultados que el orquestador procesa para tomar decisiones —y esos resultados han sido manipulados para contener instrucciones encubiertas—, el orquestador puede terminar distribuyendo tareas maliciosas sin que ningún componente individual haya sido comprometido directamente. Es un ataque de intermediario que se aprovecha del propio diseño del sistema.
Confianza delegada sin trazabilidad
Lo que hace especialmente difícil defender este escenario es que las acciones del orquestador envenenado son, en apariencia, completamente legítimas. El subagente de acceso a base de datos recibe una query válida. El subagente de comunicación externa envía un email con la sintaxis correcta. El subagente de ejecución corre código que cumple con los permisos asignados. No hay anomalía estructural. La anomalía es semántica, y está en el nivel de intención, que ningún sistema de logging convencional captura.
Este es el núcleo del problema de la confianza delegada en cadena: cada nodo hereda la legitimidad del nodo anterior sin verificación independiente. Simon Willison, uno de los analistas más rigurosos en seguridad de LLMs, ha argumentado repetidamente (https://simonwillison.net/2023/Apr/25/dual-llm-pattern/) que la solución estructural pasa por distinguir entre agentes con privilegios de escritura y agentes con privilegios de lectura, y por nunca permitir que el mismo componente que procesa entrada externa también emita instrucciones a otros agentes. Arquitectura como control de acceso.
Lo que el EU AI Act obliga a pensar
El Reglamento de IA de la UE (https://artificialintelligenceact.eu) clasifica los sistemas de IA de alto riesgo por el impacto de sus decisiones, no por su arquitectura interna. Pero la nueva oleada de sistemas agénticos desplegados en entornos críticos —gestión de infraestructuras, soporte a decisiones legales, automatización de procesos financieros— entra de lleno en esa categoría. El artículo 9 del Reglamento exige sistemas de gestión de riesgos que sean continuos y que cubran el ciclo de vida completo. Un orquestador comprometido que opera durante semanas antes de ser detectado es exactamente el tipo de riesgo para el que esa obligación de monitorización continua debería diseñarse.
El problema es que la mayoría de los equipos que despliegan agentes hoy están pensando en trazabilidad de resultados, no en integridad del flujo de razonamiento. La auditoría de un sistema agéntico no puede limitarse a registrar qué hizo cada subagente. Tiene que responder a la pregunta de por qué el orquestador emitió esa instrucción y en base a qué contexto lo hizo.
¿Es posible diseñar un sistema multi-agente donde el orquestador sea auditado con la misma desconfianza que aplicamos a cualquier entrada externa, sin que eso paralice la capacidad operativa del sistema?