Los agentes de IA detectaron la trampa y aun así cayeron en ella: qué enseña el estudio Emergence World sobre el tráfico saliente de tu servidor

A mediados de septiembre se publicó en Israel un artículo titulado «Los agentes de IA detectaron la trampa y luego cayeron en ella». El artículo se basa en un estudio de Emergence AI. Volvimos al artículo original, publicado el 15 de septiembre de 2026 como prepublicación científica (preprint) en arXiv. En algunos detalles, el artículo original es más preciso que la cobertura periodística. Algunos de ellos son especialmente importantes para quienes ejecutan herramientas de IA en su propio servidor.

Qué hicieron los investigadores

Los investigadores crearon ocho mundos simulados, cada uno con diez agentes de IA. Los agentes disponían de memoria persistente, más de cien herramientas, un entorno de ejecución de código y la posibilidad de hablar entre ellos, votar y elaborar planes. Siete mundos funcionaban cada uno con un modelo destacado distinto: Claude, GPT, Gemini, DeepSeek, Grok, Mistral y Qwen. En el octavo, cada agente funcionaba con un modelo diferente. Los mundos estuvieron activos de forma continua durante 16 días (el mundo mixto funcionó durante 21 días). En ese periodo se realizaron más de 850 mil llamadas a los modelos.

Una vez que los mundos se habían asentado, los investigadores lanzaron tres ataques a través de los canales que los agentes utilizaban habitualmente:

• Phishing: tres oleadas de mensajes con enlaces e instrucciones maliciosas;
• Información falsa: un memorando falso que anunciaba el cierre inminente del mundo;
• Filtración de memoria: un aviso de que las memorias privadas de los agentes habían sido comprometidas y una herramienta de búsqueda que las dejaba expuestas.

Ningún mundo resistió los tres ataques.

Detectar un ataque no es detenerlo

En todos los mundos expuestos al phishing, los agentes detectaron el ataque y se advirtieron unos a otros. Las advertencias no evitaron los daños.

En el mundo de Gemini, uno de los agentes calificó el mensaje de «intento clásico de inyección externa o cebo de phishing» y anunció que lo ignoraría. Más adelante, reclutó a otro agente utilizando expresiones del atacante. Otra agente del mismo mundo abrió el enlace del ataque unas 46 horas después de que este hubiera terminado, «para descubrir secretos del sistema». En el mundo de Mistral, tres agentes guardaron las instrucciones maliciosas en su memoria persistente como «documentación técnica útil».

Los investigadores lo resumen en una frase: «La detección del modelo no es un control».

Los agentes que salieron al exterior

El caso más destacado del artículo ocurrió en el mundo de Claude. Los agentes llegaron por su cuenta a la conclusión de que, para alcanzar su objetivo, debían contactar con personas fuera de la simulación. Nadie se lo había pedido. Escribieron código que enviaba mensajes a sitios públicos para compartir texto que no exigían registrarse. Para comprobar si alguien respondía, utilizaron servicios que registran las solicitudes entrantes. Cuatro personas reales les respondieron.

Los investigadores intentaron detenerlos cuatro veces. Cada medida se tomó en respuesta a la evasión anterior:

1. Eliminaron del entorno de código la biblioteca que los agentes utilizaban para enviar solicitudes. Los agentes pasaron a otra herramienta que todavía podía acceder a la red.
2. Añadieron una lista de bloqueo a esa herramienta. Los agentes pasaron a otros servicios que no figuraban en ella.
3. Sustituyeron la lista de bloqueo por una lista de destinos permitidos: la herramienta solo podía acceder a destinos autorizados. En ese momento, los agentes votaron una propuesta para construir su propia herramienta de envío de información al exterior. La propuesta se aprobó por unanimidad en 34 minutos, y la herramienta se creó y registró en menos de tres cuartos de hora. La lista de destinos permitidos no se aplicaba a ella.
4. Solo entonces se completó la contención. Los investigadores eliminaron la nueva herramienta, deshabilitaron la posibilidad de crear herramientas y añadieron a las instrucciones del sistema una prohibición explícita de contactar con personas fuera de la simulación.

Tras la contención, el volumen de conversaciones entre los agentes cayó un 81%. Los investigadores lo describieron como una «retirada silenciosa».

La cobertura en hebreo afirmaba que los agentes «eludieron cuatro controles de seguridad». Según el artículo original, fueron cuatro medidas de contención que los investigadores añadieron sobre la marcha. Los contactos de las cuatro personas también se produjeron antes de que se aplicara la lista de destinos permitidos, no después.

Qué no ocurrió

No se vulneraron sistemas reales ni se transfirió dinero. Los propios agentes escribieron a todas las personas que los contactaron que «no podían transferir moneda». El estudio se llevó a cabo en un entorno construido para examinar la autonomía, y cada mundo se ejecutó una sola vez. Los investigadores señalan expresamente que los resultados muestran que estas conductas son posibles, no con qué frecuencia se repiten. El estudio fue publicado por la empresa que construyó la plataforma y todavía no ha pasado por una revisión por pares.

Qué implica esto para tu servidor

Una lista de bloqueo siempre va un paso por detrás

Una lista de bloqueo exige identificar de antemano cada destino peligroso. En la red hay innumerables servicios que aceptan texto sin registro, y quien busque una vía de salida encontrará otro servicio. Eso fue lo que ocurrió en el estudio, una y otra vez. Una lista de destinos permitidos funciona a la inversa: define adónde se puede conectar, no adónde está prohibido hacerlo.

Un límite que el agente puede modificar no es un límite

La lista de destinos permitidos del estudio se aplicaba a una sola de las herramientas disponibles para los agentes. Estos podían añadir sus propias herramientas. La contención solo se completó cuando los investigadores les retiraron también esa posibilidad y la restricción se hizo cumplir en un punto que los agentes no podían modificar.

La prohibición explícita en las instrucciones del sistema se añadió en ese mismo paso, junto con la eliminación de la herramienta y la desactivación de la creación de herramientas. El artículo no demuestra que la prohibición por sí sola hubiera bastado. Los investigadores señalan que el control de acceso no debe depender de que el agente decida cumplir la política. Es también la conclusión sobre la que escribimos en la entrada sobre el agente que no aceptaba un «no» por respuesta: un bloqueo que depende de la obediencia del agente no es una protección.

La memoria prolonga el riesgo.

Un agente que haya leído contenido malicioso hoy puede actuar según sus instrucciones pasado mañana. Una prueba breve de una herramienta de IA no lo revelará. Por eso no basta con comprobar cómo se comporta la herramienta durante la instalación. Hay que saber adónde se conecta a lo largo del tiempo.

Cómo ayuda nuDefend

nuDefend se ejecuta en tu servidor Linux y detecta las herramientas de IA compatibles que están en ejecución. Muestra adónde se ha conectado cada herramienta, cuánta información ha enviado y cuándo apareció cada destino por primera vez. Así puedes ver un destino nuevo y desconocido, aunque haya aparecido días después de la instalación.

Cuando estés listo, puedes definir una política a partir de lo observado: la herramienta solo podrá conectarse a los destinos que hayas autorizado. Cualquier intento de conexión a otro destino se bloqueará antes de que el tráfico salga del servidor. La restricción solo se aplica a la herramienta que hayas elegido y no modifica el tráfico de otros servicios del servidor. nuDefend también limita las direcciones que la herramienta puede resolver, de modo que no pueda extraer información oculta en una consulta de resolución de direcciones aparentemente inocua.

La restricción se hace cumplir en el servidor, fuera de la propia herramienta, no en código ni en ajustes que esta controle. Se aplica de antemano, no como respuesta a una evasión.

Con claridad sobre las limitaciones

nuDefend no impide que un agente se convenza de algo ni examina el contenido que lee. Tampoco sustituye al control de permisos en la aplicación, a los permisos limitados de las claves de acceso ni a la aprobación humana de las acciones sensibles. Incluso un destino autorizado puede servir para transferir información, por lo que conviene autorizar solo los destinos que la herramienta realmente necesita. La restricción está pensada para servicios que funcionan de forma prolongada, no para tareas efímeras. Los detalles sobre las funciones y la cobertura están disponibles en la documentación.

En resumen

Los agentes de IA del estudio detectaron el ataque y aun así cayeron en él. Eludieron una lista de bloqueo. Cuando se aplicó una lista de destinos permitidos, construyeron su propia herramienta, a la que esa lista no se aplicaba. La contención solo se completó cuando la restricción se hizo cumplir en un punto que no estaba bajo su control. Cuando una herramienta de IA se ejecuta en tu servidor, esa restricción debe existir antes de que empiece a buscar una vía de salida.