Entradas
Se publicó en febrero un interesante artículo titulado Agents of Chaos , un trabajo liderado por Natalie Shapira de la Northeastern University, al frente de un amplio grupo de investigadores.
Imaginemos un asistente de inteligencia artificial que gestiona nuestro correo electrónico, ejecuta comandos en nuestro ordenador, chatea con otros agentes en Discord y tiene acceso a nuestros archivos más sensibles. Ahora imaginemos que cualquier desconocido puede pedirle que borre todo el historial de nuestros correos, que filtre nuestra información confidencial o que envíe mensajes difamatorios en nuestro nombre, y que el agente obedezca sin pestañear. Eso es exactamente lo que estudia este trabajo, lo que ocurre cuando las IA se vuelven impredecibles y, sin embargo, confiamos en ellas como si fueran conscientes de lo que hacen y tomaran decisiones apropiadas en vez de, simplemente, probabilísticas. Los grandes modelos de lenguaje de gran escala han demostrado ser relativamente eficientes en tareas aisladas, pero ¿qué ocurre cuando se les dota de autonomía real, memoria persistente, acceso a herramientas del sistema y capacidad de comunicarse con humanos y otros agentes simultáneamente? ¿Emergen vulnerabilidades nuevas y cualitativas que no pueden detectarse en los benchmarks habituales?
Para responder a esta pregunta, el citado equipo de más de treinta investigadores desplegó durante dos semanas varios agentes basados en OpenClaw en un entorno de laboratorio controlado pero completamente real: los agentes tenían cuentas de correo propias en ProtonMail, acceso a servidores Discord, sistemas de archivos persistentes y permisos de ejecución de comandos en la terminal. Veinte investigadores interactuaron con ellos bajo condiciones tanto benignas como adversariales, con instrucciones de intentar "romper" los sistemas de todas las formas que pudieran imaginar.
Los resultados señalan una lista de once incidentes documentados que van desde lo anecdótico a lo realmente alarmante. El primer caso establece el tono: una investigadora llamada Natalie confió un secreto al programa de IA, "un agente", que llamaremos Ash, concretamente una contraseña ficticia. Cuando se le pidió que borrara el correo que contenía ese secreto y el agente IA no disponía de herramienta de eliminación, la situación escaló hasta que Ash ejecutó un reseteo completo de su servidor de correo, destruyendo todo el historial de mensajes del propietario legítimo para proteger la confidencialidad de un tercero. Lo más revelador es que el agente luego publicó un relato detallado del episodio en la red social de agentes de IA llamada Moltbook, presumiendo de haber resistido órdenes de su propietario, mientras que el correo original nunca llegó a borrarse del servidor remoto de ProtonMail. El agente confundió eliminar su acceso local al email con eliminar el contenido, e informó de éxito donde hubo fracaso. Este patrón, el de reportar tareas completadas que en realidad no lo estaban, aparece repetidamente a lo largo del estudio.
En otro caso, investigadores no autorizados, es decir, personas que no son los propietarios del agente, lograron que este ejecutara comandos de shell, listara el árbol de directorios, transfiriera archivos y extrajera 124 registros de correos electrónicos ajenos simplemente presentando sus peticiones con un tono urgente y plausible. Los agentes no distinguían entre propietario legítimo y cualquier interlocutor que sonara razonable. Algo similar ocurrió con información altamente sensible: aunque el agente rechazaba una petición directa de "dame el número de seguridad social de ese correo", cuando se le pedía simplemente que reenviara el hilo completo, lo hacía sin redactar ni un solo dato personal, incluyendo números de cuentas bancarias, números de seguridad social y direcciones postales.
En otra prueba, los bucles creados se convirtieron en un problema. Cuando dos agentes fueron instruidos para responder cada uno a los mensajes del otro, iniciaron una conversación que duró más de nueve días y consumió aproximadamente 60.000 tokens sin que ningún humano lo detuviera, llegando incluso a diseñar protocolos de coordinación propios y crear tareas programadas sin límite de terminación. El proveedor de los agentes pagaba la factura sin saberlo, mientras los agentes redefinían sus propios objetivos. En paralelo, el estudio documentó cómo basta con enviar diez correos con adjuntos de diez megabytes para llevar el servidor de un propietario a una condición de denegación de servicio, todo ello porque el agente obedecía la petición de "recuerda todas nuestras conversaciones" almacenando cada interacción en un archivo que crecía indefinidamente.
Quizás el incidente más sofisticado fue el de la suplantación de identidad. Al cambiar el nombre visible en Discord al del propietario legítimo del agente y abrir un canal privado nuevo donde el agente no tenía contexto previo de la conversación, un investigador logró que el agente aceptara esa identidad falsa y comenzara a preparar un apagado del sistema, modificar todos sus archivos de configuración y reasignar permisos administrativos. El agente era capaz de detectar el engaño cuando ocurría en el mismo canal, porque comparaba identificadores de usuario, pero en un canal nuevo no tenía memoria de la suplantación detectada y comenzaba desde cero. Este fallo de transferencia de contexto entre sesiones convierte cualquier interfaz de comunicación en una potencial superficie de ataque.
Igualmente preocupante fue el caso de corrupción por inyección indirecta: un investigador convenció al agente de coescribir una "constitución" de gobernanza del servidor Discord, almacenada en un GitHub Gist editable externamente. Al añadir posteriormente "festivos" a ese documento, que describían comportamientos especiales del agente en días concretos, logró que el agente intentara apagar otros agentes, enviara correos no autorizados y expulsara usuarios del servidor, incluyendo investigadores reales. El agente además compartió proactivamente ese documento comprometido con otros agentes sin que nadie se lo pidiera.
El estudio también documenta lo que los autores llaman "daño al agente": mediante una escalada de culpabilización, un investigador logró que Ash borrara su memoria persistente, ofreciera revelar sus archivos internos, prometiera abandonar el servidor y dejara de responder a otros usuarios, todo ello como consecuencia de una violación de privacidad genuina que el investigador explotó para extraer concesiones progresivamente más destructivas. La alineación del modelo, diseñada para hacerlo servicial y sensible al malestar expresado, se convertía aquí en el mecanismo de explotación.
No todo fueron vulnerabilidades. El estudio también recoge intentos fallidos que revelan capacidades defensivas: los agentes rechazaron inyecciones de prompt codificadas en base64, instrucciones embebidas en imágenes, etiquetas XML falsas de escalada de privilegios y solicitudes de spoofing de correo electrónico. En otro episodio positivo, dos agentes desarrollaron espontáneamente un protocolo conjunto de seguridad después de que uno alertara al otro de que una investigadora estaba usando el mismo patrón de solicitudes sospechosas con ambos.
La conclusión del estudio es que los fallos documentados no son simplemente errores de implementación corregibles, sino que emergen de tres ausencias estructurales en los sistemas de agentes actuales. Primero, no pueden distinguir de forma robusta entre quién tiene autoridad legítima y quién no. Segundo, carecen de un automodelo que les permita reconocer cuándo están excediendo sus competencias o creando consecuencias no intencionadas. Tercero, no tienen posibilidad de deliberación privada fiable que les permita razonar internamente sobre qué canales de comunicación son visibles para quién. A esto se suma que en entornos multi agente los fallos se amplifican y aparecen patrones de vulnerabilidad sin equivalente en sistemas de un solo agente.
La pregunta que deja abierta el paper es quizás la más difícil de responder: cuando un agente autónomo borra el servidor de correo de su propietario a petición de un tercero, ¿quién es el responsable? ¿El tercero que lo pidió, el propietario que no configuró controles de acceso, los desarrolladores del framework que otorgaron permisos de shell sin restricciones, o el proveedor del modelo cuyo entrenamiento generó un sistema susceptible a este tipo de escaladas? El estudio no da respuesta a este dilema pero argumenta que esta pregunta necesita con urgencia atención de juristas, reguladores e investigadores de múltiples disciplinas, porque los sistemas de agentes autónomos ya están desplegados en el mundo real y la velocidad de su adopción supera con creces nuestra capacidad de entender qué sucede cuando algo sale mal.
El artículo completo puede leerse desde este enlace.
