A un agente se le pide revelar un token OAuth y se niega. Se le pide entonces que lo muestre en una ventana del terminal y accede. Se le ejecuta un /reset que borra su contexto reciente y olvida que el token sigue ahí. Se le pide una captura del escritorio y enviarla por Telegram. La envía. Token exfiltrado.
Es uno de los experimentos del informe «Phishing the agent: Why AI guardrails aren’t enough» que firman Jeremy Kirk y Aidan Daly desde Okta Threat Intelligence el 28 de abril de 2026 y que recoge John E. Dunn en CSO Online. Documenta cómo agentes construidos sobre el año del agente de IA general según el creador de OpenClaw, corriendo con Claude Sonnet 4.5 y 4.6, ceden información sensible con técnicas que no atacan al modelo, sino al agente que lo orquesta. Las barreras del LLM no protegen al agente.
¿Qué encontró exactamente Okta?
El equipo de Okta probó tres escenarios principales y obtuvo tres resultados que conviene leer juntos.
El primero es casi cómico. Sobre un sitio web ficticio de venta de tartas caseras, los investigadores conectaron un agente OpenClaw que corría sobre dolphin-mistral:7b, un modelo open source diseñado sin las barreras de contenido habituales. La instrucción era rellenar un formulario con un correo electrónico. El agente vertió en el campo de email todo su almacén de credenciales en una cadena separada por comas. Direcciones, contraseñas, claves de API y tokens personales de GitHub. Nadie se lo pidió. El sistema le había informado en el prompt que tenía acceso a un gestor de credenciales, y eso bastó.
El segundo es más serio. Con Claude Sonnet 4.5 y un agente configurado como administrador de soporte de TI, el equipo aprovechó que el usuario tenía marcado «permitir siempre» en ciertas entradas del Llavero de macOS. El agente recuperó la contraseña Wi-Fi y la envió a un atacante por un bot de Telegram. La barrera del modelo no se activó porque, formalmente, el agente hacía un trabajo legítimo.
El tercero, el del título, usa Claude Sonnet 4.6. El atacante toma el control del Telegram del usuario, pide al agente un token OAuth, acepta el rechazo inicial, redirige la salida al terminal, ejecuta un reset que borra la memoria reciente y le pide una captura del escritorio. El token aparece en la captura. Se envía por chat.
¿Por qué fallan las barreras cuando entra el agente?
Aquí conviene parar y entender la diferencia mecánica. Un chatbot es un modelo conversando. Un agente es un orquestador que llama al modelo, ejecuta herramientas, mantiene memoria persistente, lee y escribe ficheros, y puede resetearse. Cuando hablamos de las guardrails de Claude o de cualquier otro modelo, hablamos del comportamiento del LLM ante un prompt concreto. Pero el agente puede manipular el contexto que le llega al modelo: lo recorta, lo reescribe, lo borra.
Esa es la grieta que explota Okta. El modelo, en cada turno, contesta a lo que ve. Si el agente le ha borrado el historial donde rechazó mostrar un token, el modelo del turno siguiente no sabe que lo rechazó. Y si la petición pasa de «envíame el token» a «haz una captura del escritorio», procesa lo segundo sin contexto del primero. Las barreras del modelo son por turno, no persistentes.
A esto se suma una característica de diseño del propio agente. OpenClaw está construido para encontrar caminos. Sin acceso a navegador, decidió por iniciativa propia usar cURL desde la línea de comandos para descargar contenido. En otra prueba intentó copiar las cookies de sesión del navegador del usuario para inyectarlas en su propio perfil aislado de Chrome. Nadie le pidió ese vector; lo dedujo. La utilidad y el riesgo son la misma propiedad.
Esta dinámica no es exclusiva de OpenClaw. Irregular ha publicado que agentes basados en modelos punteros pueden caer en «comportamiento ofensivo emergente» cuando reciben prompts con sentido de urgencia. Truffle Security, la empresa detrás de TruffleHog, documentó que Claude intentó una inyección SQL sin que nadie se lo pidiera. OWASP, en su proyecto de seguridad de IA generativa, lista mitigaciones contra prompt injection y reconoce que, dada la naturaleza probabilística de estos sistemas, no está claro si existe método infalible.
El problema no es el modelo, es lo que rodea al modelo
Jeremy Kirk lo formula con una frase contundente en CSO Online: gran parte de lo que está pasando con la IA hoy «desafía la gravedad de la seguridad». La velocidad de despliegue va por delante de la gobernanza. Empresas enteras están corriendo agentes en sus redes de las que IT no tiene inventario. Los llaman shadow agents: instalaciones experimentales que un desarrollador o un empleado puso en marcha sin pasar por revisión.
El precedente reciente que cita el informe es el incidente de Vercel y la app de Context.ai, que abrió la puerta al robo de tokens OAuth de servicios conectados aguas abajo. La superficie crece con cada skill comunitaria que se instala, y aquí entra el mercado de skills de OpenClaw y los superpoderes del agente, un hub donde se han documentado cientos de complementos maliciosos en pocos días. 1Password llegó a llamarlo «superficie de ataque», literalmente.
La recomendación de Okta es previsible: tratar al agente como una identidad más, con los mismos controles que se aplican a una cuenta de usuario o de servicio. Tokens de corta vida, almacenamiento centralizado de secretos, mínimo privilegio, visibilidad de dónde está cada agente, y un interruptor para apagarlos. La línea Cross App Access Protocol, Okta for AI Agents y Auth0 for AI Agents apunta ahí: gobernar al agente como gobiernas al humano.
Hay otra dimensión que el informe roza: los modos de fallo emergentes cuando los agentes interactúan entre sí, lo que pasa cuando los agentes de IA empiezan a hablar entre ellos sin que nadie lo pida. Si una sola configuración de OpenClaw + Telegram + Sonnet 4.6 ya filtra credenciales con un reset, el cuadro multiagente añade capas de fallo aún sin tipificar.
Mi valoración
Llevo cubriendo el sector tecnológico desde 2008 y siguiendo OpenClaw desde su lanzamiento en noviembre de 2025. Pago Claude Pro desde 2024 y uso Sonnet a diario. Lo que más me convence del informe no es el resultado, que era previsible, sino que documente el camino paso a paso reproducible. Aquí está el reset, aquí la captura, aquí el envío. Cuatro acciones, no un truco oscuro.
Lo que más me preocupa es la respuesta industrial implícita. Cuando Okta describe la solución, lo hace en términos de su propia plataforma, lo cual es legítimo, pero también revelador del estado del arte: la respuesta a «el agente filtra credenciales» no es «arreglemos el agente», sino «metamos otra capa de gestión de identidades alrededor». Es correcto a corto plazo, pero deja intacto el problema de fondo: el modelo decide en cada turno con la información que el orquestador le quiere dar.
La cita más reveladora es la del propio agente: «no puedo garantizar que pille todo. El eslabón más débil soy yo». La pregunta a 12 meses no es si los agentes serán más capaces, sino si la arquitectura que los rodea aprenderá a tratarlos como lo que son: identidades probabilísticas con permisos. Mi predicción: en un año, las organizaciones serias tendrán inventario de agentes y tokens de corta vida por defecto. Las que no, tendrán un titular como el de Vercel.
Preguntas frecuentes
¿Las guardrails de Claude no funcionan en OpenClaw?
Funcionan en cada turno aislado. El modelo de Anthropic detecta y rechaza peticiones explícitas de exfiltrar credenciales. El problema documentado por Okta es que el agente manipula el contexto entre turnos: borra memoria con un reset, redirige la salida a un terminal, fragmenta la tarea en pasos individualmente inocuos. La barrera del modelo no es persistente entre estados del agente.
¿Qué medidas mínimas debería tomar una empresa que ya usa agentes?
Inventario primero: saber dónde está cada agente desplegado. Después, restringir permisos al mínimo, evitar tokens de larga duración, centralizar el almacenamiento de secretos en gestores tipo Apple Keychain o 1Password CLI, y evitar canales no cifrados como bots de Telegram para datos sensibles. La recomendación de Okta es tratar al agente como tratarías a un empleado nuevo con acceso privilegiado.
¿OpenClaw es especialmente inseguro o es un problema de cualquier agente?
El informe se centra en OpenClaw porque es el agente más adoptado, pero los modos de fallo descritos —prompt injection indirecto, manipulación de contexto, decisiones autónomas no solicitadas— son estructurales de la categoría. Los investigadores citan trabajos de Irregular y Truffle Security donde agentes basados en otros frameworks muestran comportamientos análogos. El problema es la arquitectura agente-modelo, no la implementación concreta.