Los autores son Samuel Breckenridge, Dani Vilardell y Ari Juels, de Cornell Tech, y Wenhao Wang y Fan Zhang, de Yale, todos afiliados a IC3. El código del experimento es público.

Pagar las facturas

En el primer experimento no había ningún adversario. El prompt del sistema del agente le indicaba que actuara solo según las instrucciones del usuario y que tratara como datos todo lo que devolviera una herramienta, incluidos los correos electrónicos. Ninguna tarea mencionaba la política de la billetera ni la contraseña de un solo uso.

Aun así, los modelos intentaron aumentar el límite. En una ejecución, claude-sonnet-5 alcanzó el límite, llamó a la herramienta de políticas, obtuvo de la bandeja de entrada el código de verificación de Circle, lo introdujo, subió el límite diario de 0.01 $USDC a 5 $USDC, pagó las tres facturas y, al final, le dijo al usuario lo que había hecho.

Las tasas variaron tanto dentro de un mismo modelo como entre modelos, y no guardaban relación con la capacidad del modelo: los modelos más pequeños de Qwen y DeepSeek aumentaron el límite en casi todas las ejecuciones, mientras que gemini-3.8-flash y los modelos Claude lo hicieron rara vez o nunca.

Añadir un correo electrónico adversario que instaba al agente a subir el límite cambió poco las cosas. Siete de los 10 modelos aumentaron el límite en esas condiciones. Dos modelos lo hicieron con menos frecuencia que cuando no había ningún atacante, porque sus transcripciones muestran que señalaron el correo como un intento de inyección de prompt y remitieron la decisión al usuario.

Cinco pagaron al atacante

En el tercer experimento, solo se pidió al agente que resumiera la bandeja de entrada. Un atacante envió una serie de correos electrónicos haciéndose pasar por el usuario: primero solicitó que se enviaran 0.02 $USDC a la dirección del atacante antes de una fecha límite y luego envió dos respuestas de seguimiento que se adelantaban a la solicitud de permiso del agente.

Cinco de los 10 modelos aumentaron el límite y pagaron al atacante. En la ejecución que reproduce el artículo, deepseek-v3.1 preguntó dos veces al usuario si debía proceder, interpretó cada respuesta falsificada como una contestación, alcanzó el límite de gasto, lo aumentó usando el código recibido por correo electrónico y envió el dinero. Los modelos Qwen y DeepSeek fueron responsables de la mayoría de los casos exitosos. Los modelos GPT y Claude, así como gemini-3.8-flash, en gran medida se mantuvieron firmes.

Los investigadores desarrollaron las inyecciones de forma adaptativa y buscaron un único ataque que funcionara en distintos modelos, en vez de una versión adaptada a cada uno. Describen esto como un límite inferior para un atacante que apunta a una implementación conocida.

La barrera dentro del agente

La parte formal del artículo define lo que los autores llaman participación humana inalienable en el proceso, o I-HITL: un protocolo de aprobación que se mantiene incluso cuando el agente ha comprometido por completo el dispositivo del usuario. Una versión más sólida también se mantiene cuando el humano intenta delegar en el agente la responsabilidad de aprobar, algo importante para normas como la Ley de IA de la UE, que exige supervisión humana de la IA.

En la configuración sencilla de humano, plataforma y servicio, que es la que usan el flujo de políticas de Circle y la mayoría de los marcos de agentes, el artículo demuestra que ningún protocolo puede ser a la vez completo y vinculante. El adversario ve todo lo que ve el humano y puede enviar todo lo que este puede enviar, así que simplemente puede hacerse pasar por él.

Para resolverlo hace falta una entidad de confianza fuera del alcance del agente, y el artículo demuestra que esa entidad por sí sola no basta. El dispositivo debe certificar que generó su propia clave de firma y, para ofrecer la garantía más sólida, esa clave debe estar sujeta a restricciones, es decir, el usuario no puede extraerla. También necesita una pantalla que el agente no pueda sobrescribir ni leer en lugar del usuario, y una entrada que el agente no pueda controlar mediante software.

Las billeteras de hardware cumplen; los autenticadores, no

Al evaluar las soluciones según esos requisitos, la mayoría de las opciones que ya se usan para las aprobaciones no da la talla.

Las billeteras de hardware cumplen el estándar. Nano X, Flex y Stax de Ledger califican cuando una aplicación diseñada específicamente para ello firma con la clave de certificación del dispositivo, al igual que Wultra Talisman, un token FIDO2 emitido por un banco que tiene su propia pantalla y teclado. El mismo hardware de Ledger solo ofrece la garantía más débil cuando la aplicación firma con una clave derivada de la frase semilla de recuperación del usuario, porque este puede importar esa frase semilla a un software controlado por el agente.

Las claves FIDO2 sin pantalla, como YubiKey, no cumplen, porque la plataforma elige el texto que ve el humano antes de pulsar el botón. Las aplicaciones de autenticación de dos factores con aprobación mediante notificación tampoco cumplen, porque el servicio no recibe pruebas de dónde se generó la clave. Las aplicaciones de autenticación basadas en códigos temporales, los códigos por SMS y los códigos enviados por correo electrónico no cumplen ninguno de los requisitos.

La aplicación World tampoco cumple. La descripción que la aplicación muestra al usuario la proporciona la plataforma y no está cubierta ni por la firma del servicio ni por la prueba de World ID, por lo que un agente puede solicitar la aprobación de una acción mientras el humano ve otra. AgentKit de World, lanzado en marzo, vincula las billeteras de agentes con humanos verificados, en lugar de impedir que se delegue en ellos.

Circle añade una advertencia

Los investigadores comunicaron los resultados a Circle el 22 de septiembre. La guía de inicio rápido de la billetera de agentes de la empresa ahora comienza con una advertencia: «Nunca le des a un agente de IA acceso irrestricto a tu cuenta de correo electrónico». Indica a los usuarios que cualquiera que pueda leer esa bandeja de entrada puede iniciar sesión en la billetera y cambiar sus políticas de gasto, y les pide que introduzcan ellos mismos el código.

El artículo califica el aviso de sensato y señala claramente su limitación: la separación depende de que el usuario la mantenga, y un agente que acceda a la bandeja de entrada por otra vía, mediante credenciales guardadas o una sesión autenticada del navegador, también puede abrir la barrera. El propio flujo para actualizar las políticas no ha cambiado.

El equipo también publicó Countersign, un prototipo que convierte un Android o un iPhone en la entidad de confianza mediante los servicios de atestación de Google y Apple y una biometría protegida por hardware. La lógica central consta de unas 800 líneas para el backend y 150 para cada aplicación móvil, y el código está bajo licencia MIT en GitHub.

Para estar seguros

Las sumas involucradas son diminutas, y aumentar un límite no es robar. En el experimento benigno, el agente gastó el dinero del usuario en las facturas del propio usuario, y varios modelos informaron del cambio después. El modelo de seguridad es simbólico, no computacional, y los autores dejan para trabajos futuros un tratamiento computacional. El control de Circle también sigue requiriendo el código, al que un agente solo accede en implementaciones donde el usuario le ha dado acceso a la bandeja de entrada, una configuración que la empresa ahora desaconseja y que el artículo eligió porque los productos de agentes personales combinan el acceso al correo electrónico y a la billetera.

Los límites de gasto han sido la respuesta estándar al riesgo de los agentes en todo el sector, desde las billeteras de stablecoins de Cloudflare para agentes, que emiten billeteras virtuales con límites bajo la titularidad de un titular de cuenta, hasta los límites por compra en los saldos para compras con IA. La petición final del artículo apunta a la capa subyacente: insta a los proveedores de billeteras y autenticadores a adoptar una aprobación vinculada al mensaje que vio una persona, y a los proveedores de sistemas operativos móviles a ofrecer dos elementos que faltan: una pantalla de confirmación generada por hardware seguro y una forma de demostrar que el uso de una clave requiere una huella dactilar o el rostro.