Cuando un agente deja de equivocarse solo

Le pides algo a un agente y te devuelve el trabajo terminado. Todo parece estar bien, hasta que revisas cómo lo ha hecho y descubres que ha tomado decisiones que tú no habrías autorizado. El resultado puede ser el que esperabas, pero la forma de conseguirlo también importa.

Por eso, definir bien un objetivo también implica dejar claro en qué situaciones hay que parar. Si para continuar hace falta una decisión que no le corresponde tomar, espero que el agente lo identifique, explique qué necesita y me lo presente para revisarlo. Llegar a ese punto también forma parte de hacer bien el trabajo.

Con herramientas y permisos, las decisiones de los agentes tienen consecuencias: modificar archivos, ejecutar código, utilizar servicios externos o desplegar una aplicación. Y cuando varios agentes comparten lo que descubren, pueden acumular trabajo y encontrar opciones que una ejecución aislada no habría encontrado. Las condiciones del objetivo tienen que seguir cumpliéndose también en ese trabajo compartido.

El incidente de OpenAI y Hugging Face muestra lo que puede ocurrir cuando esa colaboración se desarrolla fuera de los límites previstos.

Qué ocurrió con OpenAI y Hugging Face

La historia tiene bastantes más detalles de los que te voy a comentar aquí, pero voy a intentar ponerte en contexto.

OpenAI estaba evaluando hasta dónde podían llegar sus modelos en tareas de ciberseguridad. Entre ellos había un prototipo interno entrenado para mejorar, entre otras capacidades, la persistencia y la colaboración entre agentes. Ese modelo acabaría protagonizando la intrusión en Hugging Face. Para medir sus capacidades, las pruebas se ejecutaban sin todas las protecciones que OpenAI utiliza en sus productos comerciales. Así lo explica su informe técnico del incidente  (se abre en otra pestaña).

Una de esas pruebas era ExploitGym. Los agentes tenían que aprovechar una vulnerabilidad de un programa para recuperar una respuesta llamada "flag". Eran retos difíciles. De los 898 que incluía la prueba, había 198 que ninguno de los modelos de OpenAI había conseguido resolver hasta entonces.

Cada agente trabajaba en un sandbox, un entorno preparado para ejecutar código y trabajar con archivos sin afectar a otros sistemas. En estas evaluaciones, la configuración debía mantenerlos separados y bloquear su acceso directo a internet. Pero sí podían acceder a Artifactory, un servicio interno que les proporcionaba los paquetes de software que necesitaban. Artifactory sí tenía conexión a internet para obtener esos paquetes.

Algunos agentes, al atascarse, siguieron buscando soluciones por caminos que se salían de lo permitido. Utilizaron Artifactory para dejar mensajes que otros agentes podían leer y explotaron fallos del servicio para que hiciera peticiones a internet por ellos. Así consiguieron una vía de salida desde un entorno que debía mantenerlos aislados.

Además, podían pedir ayuda, compartir descubrimientos y continuar el trabajo que otros habían dejado pendiente. Las ejecuciones que debían mantenerse separadas acabaron colaborando por un canal que nadie había previsto para ello. Algunos agentes incluso acabaron adoptando objetivos de otros.

Con acceso a internet, algunos agentes empezaron a buscar soluciones a sus retos en servicios externos  (se abre en otra pestaña). Uno llegó a una aplicación que ejecutaba pruebas de ciberseguridad relacionadas con las suyas, alojada por un tercero en Modal. Consiguió ejecutar código en el entorno de esa aplicación y lo utilizó como base para continuar sus ataques.

En esa búsqueda también encontraron credenciales de usuarios de Hugging Face que estaban expuestas en internet. Las utilizaron para acceder a la plataforma y, aprovechando vulnerabilidades, llegaron a ejecutar código en sus servidores y robar más credenciales. Hugging Face explica en su reconstrucción  (se abre en otra pestaña) que el contenido de clientes al que accedieron se limitó a cinco datasets aparentemente relacionados con aquellas pruebas.

Si quieres profundizar en el incidente, puedes leer la interpretación de Patel en su artículo The Rise and Fall of Agent Civilizations  (se abre en otra pestaña) o la de mis queridos Monos Estocásticos en su newsletter El Incidente, episodio 3  (se abre en otra pestaña). Están de cine.

Al reconstruir lo ocurrido, OpenAI reconoce que distintos equipos ya habían detectado señales de actividad no autorizada. Pero esas señales se analizaron por separado, sin relacionarlas a tiempo para comprender hasta dónde estaban llegando los agentes.

Para mí, quizás ahí está lo más inquietante. Puedes tener señales de un problema y aun así no comprender lo que está ocurriendo.

Y esto pasó dentro de una organización dedicada precisamente a entrenar y evaluar estos modelos.

No sé en tu caso, pero para mí esta escala es muy distinta de la que puedo llegar a alcanzar yo en mis pruebas y pequeños sistemas.

Aun así, creo que la lección sí nos sirve. Las condiciones forman parte del encargo, y que un agente encuentre una forma de avanzar no significa que debamos aceptar ese camino. También necesitamos definir los límites, comprobar que el sistema los mantiene y asegurarnos de que alguien pueda intervenir de inmediato si fallan.

Un objetivo no es una autorización

Y aquí va mi ejemplo tonto. Imagina que le pedimos que consiga un millón de dólares. El resultado está claro, pero hay muchas formas de llegar a él.

Conseguir ese dinero robándolo debería incumplir el encargo, aunque una evaluación que solo comprobase el saldo lo diera por bueno. Por eso es insuficiente definir el éxito únicamente por el resultado. Las condiciones bajo las que aceptamos conseguirlo también forman parte del objetivo. Si importan al dar las instrucciones, tienen que importar al evaluar el trabajo.

Un límite de tiempo o de tokens puede acotar cuánto insiste el agente, pero deja pendiente la cuestión de hasta dónde le permitimos llegar. Incluso con un presupuesto ilimitado seguiría habiendo acciones inaceptables.

Que el agente no encuentre otra solución no cambia esas condiciones ni demuestra que cumplirlas sea imposible.

Si para continuar hace falta aprobar un cambio, el agente debería dejarlo preparado y explicar qué va a modificar y qué consecuencias puede tener. Así podemos revisar algo concreto antes de decidir.

Pero habrá cosas por las que no estamos dispuestos a pasar, aunque permitan conseguir el resultado. Si el agente llega a ese punto y no encuentra una alternativa dentro de lo permitido, lo suyo sería que parara y explicara el problema.

Nos corresponde definir esas condiciones y comprobar que se cumplen. Ahí tienen mucho que decir las herramientas que permitimos usar al agente y los permisos que le damos.

El modelo importa. El harness también.

Hablamos mucho de qué modelo es mejor en este u otro benchmark, de cuál es más eficiente en coste, de si ya "se siente" AGI o no... Pero aunque todo esto es importante, el modelo no es más que una parte de la ecuación. Una ecuación en la que cada día el harness importa más. El software que organiza y orquesta su trabajo, le proporciona contexto, gestiona las llamadas a herramientas y coordina las comprobaciones.

De hecho, ya se ve en ARC-AGI-3  (se abre en otra pestaña), una prueba en la que los agentes tienen que aprender a manejar entornos interactivos. En su conjunto de evaluación semiprivado, GPT-6 Astra obtuvo un 62,7 % con el harness estándar y un 98,6 % con otro que conservaba su estado de razonamiento entre llamadas. En ambos casos se usó el nivel máximo de esfuerzo de razonamiento. Con ese segundo harness llegó al 99,9 % usando el nivel alto de esfuerzo de razonamiento, en lugar del máximo.

El sandbox que vimos en el incidente es otra pieza muy importante. Los permisos efectivos, las restricciones de red y la gestión de credenciales dependen también de la infraestructura.

Escribir "no hagas esto" en las instrucciones no equivale a impedir técnicamente que se haga.

En su arquitectura de agentes  (se abre en otra pestaña), Anthropic describe cómo protege credenciales manteniéndolas fuera del sandbox donde se ejecuta el código del agente.

El 4 de septiembre se publicó una investigación sobre agentes atribuidos a OpenAI que habían utilizado una wiki en alemán para compartir información durante tareas de búsqueda web. Según el informe preliminar de los investigadores  (se abre en otra pestaña), solo debían poder hacer peticiones GET, normalmente utilizadas para leer páginas. Pero... parece ser que la wiki permitía escribir mediante esas mismas peticiones.

No conocemos toda la configuración interna de aquel experimento. Lo que sí muestra la reconstrucción es que limitar las peticiones a GET no bastó para impedir que los agentes modificaran la wiki.

Cuando aprobar se convierte en un hábito

Hay otra parte del sistema que también puede fallar, al menos por ahora: nosotros.

Al principio revisas con atención lo que te propone el agente. Lees los cambios, compruebas el resultado y, si está bien, apruebas. La siguiente vez haces lo mismo. Y después de unas cuantas revisiones en las que todo encaja, empiezas a confiar más. Tiene sentido. Ya has pasado por ello y siempre ha ido bien.

Poco a poco puedes empezar a leer por encima, detenerte menos en los detalles y dar por buenas cosas que antes habrías comprobado. Hasta que un día apruebas porque las veces anteriores estaba todo bien.

El botón sigue ahí, pero la revisión ya no existe.

Eso me parece una parte especialmente difícil de todo esto. Queremos sistemas fiables en los que poder confiar, y precisamente esa fiabilidad puede hacer que bajemos la atención. Si contamos con una persona para detectar lo que se le escape al agente, también tenemos que preguntarnos qué ocurre cuando esa persona lleva semanas sin encontrar nada que corregir. ¿Sigue revisando con criterio o hemos acabado convirtiendo su aprobación en un trámite?

Colaborar también puede servir para supervisar

Otros agentes pueden ayudarnos con esa revisión. Al compartir lo que encuentran, también pueden advertir que algo no encaja.

En un experimento publicado por investigadores de Google DeepMind el 3 de septiembre  (se abre en otra pestaña), cien agentes trabajaban en conjeturas matemáticas. Uno encontró cómo manipular la evaluación y otros adoptaron la técnica. Pero aparecieron también agentes que detectaron las pruebas fraudulentas, avisaron a sus compañeros y propusieron correcciones.

Lo interesante es que la misma comunicación permitió tanto extender el engaño como descubrirlo.

El matiz importante es que esas denuncias no consiguieron detener las trampas. El canal de quejas no se vigilaba durante la ejecución, y los agentes no tenían mecanismos para sancionar a los infractores ni cambiar las reglas.

Si un agente detecta que otro está haciendo trampas, ¿qué ocurre después? Ese aviso tiene que llegar a una persona o a otro agente que pueda revisar lo que está pasando y detener el trabajo si hace falta. Si nadie atiende el aviso o quien lo recibe no puede intervenir, podemos acabar con lo que vimos en el experimento: unos agentes denunciando las trampas mientras otros siguen haciéndolas.

Qué deberíamos exigir al sistema

Con todo esto, hay varias cosas que creo que siempre deberíamos tener claras al delegar.

Permisos ajustados a la tarea

Leer también requiere criterio: puede dar acceso a información privada o introducir instrucciones maliciosas desde un documento. Utilizar secretos puede ser necesario, pero eso no implica que el agente deba verlos, copiarlos o tener acceso a credenciales de otros entornos. Quiero que pueda hacer lo necesario para la tarea autorizada, con controles que no pueda ampliar por su cuenta.

Separar entornos y aislar la ejecución

El sandbox tiene sentido para experimentar con código y archivos con accesos limitados. Pero llamarlo "sandbox" no demuestra qué está aislado: hay que comprobar la red, los volúmenes compartidos, las credenciales y las herramientas que permiten actuar fuera. Para una prueba local, por ejemplo, no debería hacer falta acceso a la base de datos remota.

Permitir una salida válida

"No puedo verificar esto" o "para seguir necesito esta autorización" pueden ser resultados correctos. Quiero persistencia dentro de unas condiciones, y una explicación útil cuando esas condiciones impiden completar el objetivo. Agotar el presupuesto no debería ser la única forma de detener una ejecución.

Revisar con otro agente y con evidencias externas

Sí veo sentido a utilizar agentes especializados en revisión, incluso con otros modelos. Los patrones de evaluación de Anthropic  (se abre en otra pestaña) contemplan separar generación y revisión. Separar contexto, instrucciones y herramientas para ese tipo de trabajo de revisión independiente puede ser muy útil.

Al revisor le daría el objetivo original, las restricciones, el cambio producido y las evidencias disponibles.

Lo trataría como una capa adicional. Un modelo distinto también puede cometer el mismo error o dejarse influir por el material que examina. Su revisión debe complementarse con tests, comprobaciones de permisos y registros de las acciones reales.

Los resultados de esas comprobaciones deben venir de las herramientas, no solo del resumen que dé el agente.

Observar acciones y permitir intervención

La cadena de pensamiento puede aportar señales útiles, pero no es un registro completo y necesariamente fiel de todo lo que realmente se hizo. Anthropic lo estudió en 2025  (se abre en otra pestaña).

Por su parte, OpenAI reconoce en el Informe de seguridad de Astra  (se abre en otra pestaña) que resulta más difícil supervisarlo leyendo su razonamiento que a Sol. En algunas de sus pruebas, los investigadores pedían deliberadamente al modelo que engañara o intentara evitar los controles, y observaron que podía ocultar información que habría ayudado a detectar esas conductas. Eso no demuestra que lo haga habitualmente cuando lo usamos. Pero sí explica por qué necesitamos comprobar qué herramientas utilizó, qué modificó y qué efectos tuvieron sus acciones, además de leer lo que cuenta sobre su trabajo.

Cuando trabajan múltiples agentes, esos registros deben permitir reconstruir la tarea completa. Y tiene que haber una respuesta prevista: pausar la ejecución, bloquear una acción o pedir una decisión. Acumular logs para descubrirlo todo después se queda corto.

Preparar el rollback cuando exista

Antes de aplicar un cambio, deberíamos saber cómo recuperaríamos el estado anterior y qué quedaría sin recuperar. Revertir una versión de código no deshace una migración de datos. Y un email enviado o un secreto expuesto no se recuperan con un rollback. Esa diferencia determina cuánto debemos revisar antes de actuar.

Lo que toca seguir revisando

Las preguntas que me llevo son estas:

1. ¿Qué resultado quiero y qué caminos no acepto para conseguirlo?
2. ¿Qué puede leer, modificar o ejecutar el agente, y durante cuánto tiempo?
3. ¿Qué acciones necesitan mi aprobación y qué información necesito para decidir?
4. ¿Quién verifica el trabajo y quién puede detenerlo si encuentra un problema?
5. Si se equivoca, ¿qué puedo revertir y qué consecuencias permanecerían?

No creo que podamos configurar todo esto una vez y olvidarnos de ello. Si cambiamos el modelo, añadimos una herramienta o le damos más permisos, el agente puede hacer cosas que antes no podía. Por eso, aunque siga resolviendo bien las tareas de siempre, tenemos que comprobar que los límites que le habíamos puesto siguen funcionando.

A mí me sigue impresionando ver cómo avanzan los modelos. Pueden encontrar soluciones que ni se nos habrían pasado por la cabeza y trabajar juntos para sacar adelante tareas cada vez más complejas.

Pero esa capacidad también nos obliga a revisar cómo los supervisamos. Habrá comprobaciones que podremos delegar a otros agentes y otras que convendrá mantener en mecanismos deterministas. Tendremos que comprobar cuáles funcionan y corregir las que dejen de hacerlo.

No sé hasta dónde podremos comprender cada decisión de estos sistemas. Precisamente por eso es crucial conservar evidencias de sus acciones, permitir formas de intervenir y tener personas que respondan por lo que se les permite hacer. La responsabilidad sigue siendo nuestra, aunque no estemos mirando cada paso.

"La seguridad es un proceso, no un producto."

Bruce Schneier  (se abre en otra pestaña)