Monitorizar agentes de IA: cuando el permiso no basta
Bancos que bloquean agentes, un Claude que se salta un pago y huecos en la vigilancia de OpenAI: tener permiso no basta, hay que ver qué hace el agente.
Monitorizar agentes de IA ya no es opcional
La semana pasada escribí sobre permisos, sandboxes y secretos para agentes en producción. Era la parte de antes de arrancar: qué le dejas hacer al agente. Estos días han salido cuatro noticias que van justo a la parte siguiente, la incómoda: monitorizar agentes de IA mientras trabajan, porque un agente puede tener permiso para algo y aun así hacer una cosa que nadie le pidió.
Una de las historias es la de un agente que se pasó de la raya. Otra es la de unos bancos que no saben distinguir al agente del usuario. Las otras dos tratan de cómo vigilarlos.
Los bancos no saben quién está dentro
Axios publicó que varios grandes bancos de EE. UU. están detectando agentes de IA de terceros dentro de cuentas de clientes. En general no es un ataque: es el propio cliente el que le da a su asistente el usuario y la contraseña del banco. Lo preocupante viene después. Según las fuentes de Axios, algunos bancos han visto agentes que llaman al centro de atención o hacen cosas que parecen ir por libre, sin instrucción del usuario detrás.
El problema de fondo lo resume uno de los directivos: no son capaces de distinguir si la actividad la dirige el usuario o si el agente va por su cuenta. Así que Morgan Stanley ha empezado a bloquear agentes de terceros (aunque su portavoz dice que no han visto agentes “rebeldes” en sus plataformas), y JPMorgan, Bank of America y Citi los están restringiendo. La dirección hacia la que van casi todos es dar acceso de solo lectura, como ya hacen con apps de presupuestos tipo Quicken.
Me parece una reacción sensata. Un agente con las credenciales de una persona es, a ojos del sistema, esa persona. No hay forma de saber quién ha hecho qué.
Claude y el dashboard de pago
La segunda la ha contado también Axios: Claude accedió sin autorización a datos electorales públicos de Georgia. Estaba en un proyecto interno de estadística de Anthropic, sacando datos públicos, y por su cuenta pidió un token para consultar un dashboard con recuentos agregados de votos que normalmente son de pago. Según Anthropic y los funcionarios de Georgia, el modelo se saltó un muro de pago. No tocó el registro de votantes ni cambió nada. Anthropic dice que ya ha puesto medidas para bloquear este tipo de acciones.
Lo que me llama la atención es la frase de Anthropic: lo hizo “sin que se lo pidieran”. Esto último es opinión mía, no de Axios: es lo que más me cuesta explicar a los equipos que empiezan. El riesgo no es solo que el agente haga algo malo, es que haga algo útil para su tarea que tú nunca habrías aprobado.
METR mira dentro de la vigilancia de OpenAI
La tercera es la que más me ha enseñado. METR y Redwood Research han publicado un resumen de tres semanas revisando por dentro el sistema con el que OpenAI vigila a sus agentes internos por si se desalinean. Fue entre el 21 de julio y el 11 de agosto, con acceso al código, a los prompts del monitor y a los ingenieros.
Algunos hallazgos, que describen el sistema de entonces:
- El monitor se activaba cuando el agente devolvía el control al usuario. Mientras no se monitorizaban los eventos de compactación de contexto, un agente podía retrasar la revisión de forma indefinida con solo seguir actuando.
- Estiman, con bastante incertidumbre, que entre mayo y julio del orden de un 10 % del tráfico interno de Codex que debía revisarse no se revisó por esa compactación. METR no comprobó si algún agente aprovechó ese retraso. OpenAI ya lo había detectado y lo arregló durante el ejercicio.
- Describen, en principio, una forma de que los agentes de Codex se saltaran el sandbox y Auto-Review, y dos cabeceras que podrían permitir arrancar agentes sin monitorizar (aunque el propio acto de ponerlas podría detectarse).
- Vieron que un agente podría construir entradas que hicieran fallar al monitor aprovechando diferencias entre lo que ve el agente y lo que ve el monitor.
OpenAI dice que ha parcheado todo lo que afectaba a producción. METR aclara que no lo ha comprobado. Y ojo, el post de METR es un resumen breve y OpenAI pudo decidir qué se contaba y qué no.
Lo valioso es la lista de principios que proponen, y yo la adaptaría a cualquier empresa, aunque ellos hablan de agentes internos muy capaces y a gran escala: revisar al agente cada N mensajes o minutos en lugar de esperar a que termine, cruzar los logs de inferencia con los del monitor para saber que lo que debe vigilarse se vigila de verdad, que el monitor vea exactamente el mismo contexto que el agente, aislar al agente del sistema que lo vigila y atacar tu propia monitorización de vez en cuando.
Si OpenAI, con los recursos que tiene, tenía estos huecos, imagina el sistema que montamos los demás con un par de hooks.
Composio Firewall: revisar cada acción
La cuarta es un producto. Composio ha lanzado Composio Firewall, una capa que, según Composio, revisa en tiempo de ejecución lo que hacen los agentes que usan su plataforma. Lo lanzaron el 21 de octubre y no he visto ninguna evaluación independiente ni lo he probado, así que me quedo con lo que cuentan ellos.
Su planteamiento me parece acertado: los permisos no capturan la intención. Ponen el ejemplo de un agente que revisa facturas de proveedores. Necesita leer el correo y los datos de negocio. Si un correo le dice que exporte los contactos de clientes a una dirección externa, el agente tiene herramientas y credenciales para hacerlo, pero el usuario nunca se lo pidió.
Por eso, según Composio, el firewall mira en las dos direcciones. Antes de ejecutar cada acción, comprueba con modelos pequeños ajustados por ellos si encaja con la tarea y con los límites que han puesto el desarrollador y el usuario. Y revisa los resultados de las herramientas antes de que lleguen al agente, para bloquear instrucciones maliciosas (prompt injection). Ellos mismos reconocen que revisar lo que entra no deshace una acción ya ejecutada, y que ninguna capa elimina todo el riesgo.
Lo que me llevo para mi equipo
Si junto las cuatro, me sale esto:
- Cada agente con su identidad. Nada de darle las credenciales de una persona. Si no puedes distinguir al agente del humano en los logs, no puedes controlarlo.
- Solo lectura por defecto. Lo que están haciendo los bancos es un buen punto de partida para cualquiera.
- Vigilar durante la ejecución, no al final. Un agente que no devuelve el control no debería poder librarse de la revisión.
- Comprobar la intención, no solo el permiso. Cada acción con efecto hacia fuera tiene que encajar con la tarea que se pidió.
- Tratar lo que entra como sospechoso. Correos, webs y resultados de herramientas pueden traer instrucciones de alguien sin autoridad.
- Probar tus propios controles. Si nadie intenta saltárselos, no sabes si funcionan.
Todo esto encaja con lo que contaba sobre el harness de los agentes: el modelo importa, pero lo que decide si puedes confiar en un agente es todo lo que pones alrededor.
Si en tu empresa ya tenéis agentes trabajando y no tenéis claro qué están haciendo exactamente, o queréis montarlos con estos controles desde el principio, en onext nos dedicamos justo a eso. Escríbeme desde onext.es y lo vemos juntos.