Varios agentes, 193 amenazas: el fallo puede nacer entre ellos
En un sistema multiagente, proteger cada modelo por separado no basta: el fallo puede nacer cuando un componente acepta la salida de otro, hereda una delegación, consulta memoria compartida o activa una herramienta con más autoridad. Por eso la revisión debe seguir la tarea completa y tratar cada relación entre agentes como un límite de confianza.
Antes del despliegue hay que comprobar quién originó cada instrucción, qué transformaciones sufrió, con qué identidad y permisos avanzó y qué efecto puede producir. Las 193 amenazas documentadas no requieren 193 controles aislados, sino un mapa que relacione nueve familias de riesgo con activos, fronteras y consecuencias.
Qué significa realmente la cifra de 193 amenazas
La prepublicación de Nguyen, Ndebugre y Arremsetty organiza 193 amenazas principales en nueve categorías y contrasta 16 marcos de seguridad mediante una escala de tres niveles. Su método construye una base técnica, emplea IA generativa para el modelado de amenazas, somete los resultados a validación especializada y evalúa la cobertura amenaza por amenaza.
El número describe el catálogo elaborado por ese estudio; no es una estimación universal de todo sistema multiagente. La exposición concreta depende de la arquitectura, los canales de comunicación, la memoria, las herramientas, las credenciales y la autonomía concedida. La cifra resulta útil si evita que una revisión centrada en un único modelo ignore las rutas creadas por la composición.
La presentación publicada en CSRC de NIST caracteriza esas superficies mediante ingeniería del conocimiento y modelado de amenazas, y propone identidad criptográfica, autorización sensible a la secuencia, telemetría entre agentes y pruebas continuas basadas en eventos. Son controles dirigidos a las relaciones del sistema, no solo a cada llamada individual.
Nueve familias para localizar dónde puede propagarse el fallo
Los nombres siguientes traducen las nueve categorías del estudio. Para convertirlas en una revisión arquitectónica, cada una debe asociarse con el activo afectado y el límite que cruza:
- Acoplamiento entre agente y herramienta. Una decisión manipulada puede producir una llamada técnicamente válida pero contraria a la intención autorizada. Hay que delimitar credenciales, argumentos, destinatarios y efectos.
- Fuga de datos. Mensajes, contexto, trazas o almacenes compartidos pueden trasladar información entre usuarios y dominios que debían permanecer separados.
- Inyección. El contenido recibido en documentos, resultados o mensajes puede interpretarse como una orden y viajar después a otros componentes.
- Identidad y procedencia. Sin atribución verificable se pierde quién originó, transformó o aprobó una acción, incluida la identidad del usuario representado.
- Envenenamiento de memoria. Un dato adversarial escrito hoy puede reaparecer en otra sesión y condicionar a un agente distinto con mayores capacidades.
- No determinismo. La variación se acumula entre decisiones, herramientas y pasos de orquestación, dificultando reproducir una ruta insegura.
- Explotación de la confianza. Un agente puede aceptar la salida de otro como análisis fiable sin validar su procedencia, su ámbito o sus supuestos.
- Temporización y monitorización. Los registros locales pueden mostrar llamadas aisladas sin conservar la causalidad de extremo a extremo.
- Arquitectura del flujo. Orquestadores, índices, complementos y servicios comunes concentran el impacto sobre todos sus consumidores.
Activos y límites de confianza antes que controles
El punto de partida es un diagrama con agentes, personas, modelos, herramientas, memorias, orquestadores y servicios externos. Cada conexión debe indicar qué datos transporta, qué identidad presenta, qué capacidad delega, dónde termina y si la respuesta puede modificar estado persistente o iniciar otra acción.
Después se señalan los activos cuyo compromiso altera el comportamiento colectivo: objetivos, políticas, credenciales, colas, historiales, índices de recuperación y trazas. Un agente con pocos privilegios directos sigue siendo crítico si puede escribir en una memoria que consultará otro autorizado para operar sobre pagos, infraestructura o datos sensibles.
La guía multiagente de OWASP aplica la metodología arquitectónica por capas MAESTRO y examina cómo la coordinación, la autonomía y la memoria amplían las rutas de ataque. Esa vista por capas ayuda a encontrar dependencias que desaparecerían en una lista separada por agente.
Una plantilla para la revisión arquitectónica
Estas preguntas convierten la taxonomía en decisiones comprobables. Cada respuesta debería identificar el control, su responsable y la evidencia técnica esperada:
- ¿Qué agentes pueden originar, transformar, aprobar y ejecutar la tarea, y cómo se conserva esa procedencia?
- ¿Cada agente tiene identidad verificable o comparte cuentas, tokens o roles con otros componentes?
- ¿La autorización se evalúa de nuevo cuando cambian el agente, el recurso, el usuario representado o el efecto?
- ¿Qué memoria puede leer y escribir cada agente, con qué propósito, para qué usuario y durante cuánto tiempo?
- ¿Los mensajes y resultados se tratan como entradas no confiables antes de convertirse en instrucciones?
- ¿La aprobación humana muestra la secuencia de efectos o resume varias operaciones bajo una acción ambigua?
- ¿Las trazas enlazan tarea, agente, usuario, modelo, herramienta y versión de política?
- ¿Qué límites de tiempo, coste, iteraciones y llamadas contienen bucles o reintentos?
- ¿Puede revocarse una credencial, aislarse un agente e invalidarse memoria contaminada sin borrar todo el sistema?
Una autorización válida para cada llamada no garantiza que la secuencia completa esté permitida: consultar un dato y enviarlo pueden ser acciones aceptables por separado, pero formar juntas una ruta prohibida. Este problema convierte los permisos en producción en propiedades del flujo, no en una suma de privilegios independientes.
Condiciones mínimas para autorizar el despliegue
El despliegue debería bloquearse si hay agentes sin identidad atribuible, memorias compartidas sin separación, herramientas que usan credenciales comunes o acciones críticas autorizadas solo al comienzo de la cadena. La misma decisión se justifica si una investigación no puede reconstruir qué mensaje cambió el curso de la tarea y qué componente produjo el efecto.
Las pruebas previas deben cubrir mensajes falsificados, memoria contaminada, respuestas malformadas de herramientas, delegaciones encadenadas, fallos parciales del orquestador y bucles de coordinación. El criterio de aceptación no es únicamente completar la tarea: también debe demostrarse contención, revocación, separación de datos y trazabilidad cuando una relación entre agentes deja de ser confiable.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.