Amenazas de sistemas de agentes y multiagente

Un agente no solo responde: decide pasos y llama herramientas. Cuando varios agentes cooperan, el modelo de amenazas cambia en un punto clave. El mensaje que un agente recibe de otro no es más confiable que lo que ese otro leyó. Si un agente lee un adjunto escrito por un asociado y le pasa un resumen al agente que crea solicitudes, el texto del asociado viaja dentro de ese mensaje, ahora con la apariencia de una instrucción interna. La confianza no se queda en la frontera de entrada: se transmite por la cadena.

Por eso, en un diseño multiagente, cada flujo entre agentes se trata como un posible cruce de frontera, salvo que el contenido viaje marcado con su origen y el agente que actúa no dependa de ese contenido para decidir qué está permitido. A eso se suman tres piezas que no existían en un asistente simple: la identidad con la que actúa cada agente, la memoria que persiste entre sesiones y la falta de un tope en la cadena de delegaciones.

En un sistema de agentes la pregunta de autorización es con qué identidad se ejecuta cada herramienta. Si el agente actúa con la identidad del asociado de la sesión, solo puede tocar lo que ese asociado puede tocar, y un texto engañoso no le da más alcance. Si actúa con una cuenta de servicio con permiso sobre todas las cuentas, cualquier desvío del objetivo se convierte en una acción sobre datos ajenos. Es la familia de amenazas de abuso de identidad y privilegios.

Revisa en el diseño qué identidad usa el agente que puede crear solicitudes.

La memoria compartida es lo que permite a los agentes recordar entre una conversación y otra. Es útil, y es también un almacén donde un contenido no confiable puede quedarse y reaparecer en la sesión de otra persona, días después y sin rastro visible de dónde salió. Esa es la familia del envenenamiento de memoria y contexto. Para modelarla hay que saber quién escribe en la memoria, desde qué origen y quién la lee.

Revisa las notas de la memoria compartida y su uso posterior.

Cuando un agente delega en otro y ese otro puede volver a delegar, una sola petición puede multiplicarse en muchas llamadas. Si no hay un tope, un error o un contenido engañoso se propaga por la cadena y el daño crece con cada salto: es la familia de los fallos en cascada. El diseño debería fijar un máximo de delegaciones por petición, y la traza permite ver cuántas hubo de verdad.

Cuenta en la traza de prueba las delegaciones entre agentes de una sola petición.

Con las amenazas a la vista, la mitigación tiene que romper la transmisión de confianza en un punto que no dependa de que el modelo se porte bien. Pedirle a un agente en sus instrucciones que desconfíe de los adjuntos no es un control: es un deseo escrito en el mismo canal que el atacante puede usar. Un control es algo que se cumple aunque el modelo se equivoque.