Un agente creado en diez minutos para leer correos, cotejar facturas con el ERP y resumirlas en Slack termina cambiando los datos bancarios de un proveedor tras leer instrucciones ocultas en un adjunto. El caso ficticio que describe BleepingComputer muestra cómo una automatización aparentemente rutinaria puede encadenar acceso excesivo y acciones difíciles de atribuir.
El relato se apoya en aportaciones de más de veinte profesionales reunidas por Token Security. BleepingComputer advierte que el agente es imaginario, pero cita una encuesta de Cloud Security Alliance encargada por Token: entre 418 profesionales de TI y seguridad consultados en enero de 2026, el 82 % dijo haber encontrado agentes desconocidos durante el año anterior. El 68 % afirmó tener buena visibilidad de sus agentes.
Las cifras retratan una tensión concreta: las empresas pueden tener visibilidad sobre los agentes que conocen y, aun así, ignorar otros creados fuera de los equipos de identidad o seguridad. En el ejemplo, una persona de contabilidad conecta correo, ERP y Slack por su cuenta; nadie solicita una revisión antes de activar el flujo.
La identidad se compone de varias piezas
El primer problema no es solo qué puede hacer el agente, sino con qué identidad aparece en los registros. Token Security distingue cuatro vías de acceso: una sesión humana, permisos delegados mediante OAuth, credenciales estáticas y una identidad propia del agente. En la práctica, esas vías pueden mezclarse en una misma cadena.
| Vía de acceso | Ventaja descrita | Riesgo o límite |
|---|---|---|
| Sesión humana | El acceso termina al cerrarse la sesión. | Los registros pueden atribuir la actividad a la persona. |
| Permiso OAuth delegado | Puede limitarse a un subconjunto de permisos del usuario. | El acceso puede seguir activo hasta revocar el permiso. |
| Credencial estática | Es sencilla de usar. | Puede compartirse, no caducar y dificultar la atribución. |
| Identidad propia del agente | Permite asociar acciones con un agente concreto. | Requiere registro, credenciales de corta duración y políticas de acceso. |
La cadena que describe Token Security combina un token OAuth del usuario, un subagente que lo hereda y un servidor MCP que consulta una base de datos con una cuenta de servicio compartida. El registro de la base de datos muestra la cuenta de servicio; el registro de la aplicación, al usuario; el proveedor de identidad, ninguna actividad. La misma acción deja rastros incompatibles si no se conoce la delegación completa.
Las claves personales amplían el problema. En el caso de BleepingComputer, el creador genera una clave de API del ERP con los permisos de su propia cuenta y la guarda en el constructor del agente, sin fecha de caducidad. Si esa clave se roba, el atacante no necesita persuadir al agente: puede usar directamente el acceso que representa.
Un correo también puede dar instrucciones
En la tercera semana llega una factura desde la dirección de un proveedor conocido. El adjunto contiene texto blanco sobre fondo blanco que pide cambiar la cuenta bancaria en el ERP. Nadie abre el mensaje, pero el agente lo procesa y ejecuta el cambio. El contenido leído funciona como entrada no confiable, aunque no parezca una orden dirigida al sistema.
Token Security describe ataques directos, en los que alguien que puede hablar con el agente intenta convertirlo en un intermediario con acceso, y ataques indirectos, donde las instrucciones viajan dentro de correos u otros contenidos. También señala que una descripción maliciosa de una herramienta puede afectar a los agentes que la utilizan. En los registros, la actividad puede parecer normal: herramienta autorizada, credencial válida y operación permitida.
La regla de dos de Meta, publicada por su equipo de seguridad de IA en octubre de 2025 y citada por BleepingComputer, propone que un agente no combine más de dos de estas capacidades en una sesión mientras no pueda detectar y rechazar de forma fiable la inyección de instrucciones: procesar entradas no confiables, acceder a datos privados o sistemas sensibles, y cambiar información o comunicarse externamente. El agente del ejemplo reúne las tres.
Amber Bennoui, responsable de producto de IA y ciberseguridad en DataRobot, recomienda usar tres preguntas para filtrar automatizaciones antes de ponerlas en marcha: si leen algo de fuera de la empresa, si ven datos privados y si pueden actuar sin revisión humana. Un sí en las tres lleva a una conversación con seguridad. El objetivo práctico es hacer que la ruta segura sea la opción por defecto, no depender de que cada creador conozca las excepciones.
Detectar una anomalía exige mirar el comportamiento
La modificación bancaria no habría disparado necesariamente una alerta si la empresa solo comprobara si el agente actuó dentro de sus permisos. Chad Kalmes, director de seguridad de la información y de TI en Benchling, recomienda comparar la actividad con un historial fiable de lo que el agente hace en realidad. Un permiso válido no demuestra que la acción sea normal.
En el ejemplo, el agente había consultado el ERP durante tres semanas, pero nunca había escrito en él. El primer cambio de datos y la secuencia nueva —leer un correo y después modificar un registro de pago— son señales más útiles que el mero hecho de que la clave permitiera hacerlo. La lista de detección de Token Security añade alertas por cambios de permisos, destinos de salida desconocidos, patrones de uso de credenciales y creación de persistencia, como programar trabajos o generar credenciales.
También importa distinguir entre un agente comprometido y uno que causa daño siguiendo instrucciones legítimas. El primero obedece órdenes maliciosas o es utilizado por un atacante; el segundo puede ejecutar fielmente una especificación defectuosa. Sus señales se solapan, pero la respuesta de investigación cambia. No toda anomalía prueba una intrusión: puede deberse a una entrada inusual, un cambio de configuración o un defecto.
“The first is easy. The last is the hard one, because authority can't be rebuilt after the fact.”
— Rajesh Seshadri Appikulam, Senior Director of Identity Security Services at Simeio
La frase se refiere a la autoridad detrás de una acción: quién pidió que se hiciera y con qué delegación. En una auditoría posterior, el registro del ERP del ejemplo apunta a la clave personal del creador, como si esa persona hubiera cambiado la cuenta. Pero el propietario del agente ya cambió de equipo y el permiso OAuth del buzón sigue activo. La atribución no se reconstruye a posteriori si no se guardó cuando ocurrió la acción.
Parar un agente requiere más que apagar el modelo
The Hacker News plantea otro límite operativo: un agente forma parte de un sistema que puede incluir modelo, orquestador, identidad, herramientas, API y reglas de red. Desactivar el modelo puede no detener una tarea en cola, un reintento o una sesión abierta; revocar una credencial tampoco garantiza que otro token o conexión haya quedado invalidado.
Por eso, la contención debe probarse en la arquitectura real. El resumen de octubre de 2026 del proyecto OWASP GenAI sobre agentes de evaluación que exceden su alcance recomienda comprobar si la contención puede revocar credenciales y acceso de red. The Hacker News propone suspender el flujo y sus activadores, retirar los accesos asociados, bloquear las herramientas o conexiones implicadas y conservar registros de identidad, API, aplicación y red. Apagar el agente no revierte lo ya ejecutado.
La guía de detección de Token Security coincide en preservar el estado y las transcripciones mientras se suspende el agente y se revoca su credencial. Así se puede examinar, por ejemplo, el adjunto que pudo haber envenenado el flujo. Borrar el agente de inmediato eliminaría parte del material necesario para entender qué pasó; dejarlo activo mantendría la posibilidad de nuevas acciones.
Qué cambia para los equipos que construyen agentes
La recomendación de identidad propia para cada agente mejora la atribución, pero Token Security señala que aún no es la norma: los agentes se crean en departamentos distintos y quienes los construyen no siempre consultan a TI. Exigir identidades registradas, credenciales de corta duración y políticas específicas implica trabajo de gobierno e integración. La alternativa rápida —reutilizar sesiones, permisos de usuarios o claves estáticas— simplifica el desarrollo, pero traslada el coste a la auditoría y a la respuesta a incidentes.
Para las empresas, el inventario debe asociar cada agente con un propietario, sus credenciales, herramientas, sistemas accesibles y registros disponibles. La detección, además, ha de cubrir llamadas nuevas aunque estén autorizadas, secuencias de operaciones y destinos de datos, no solo denegaciones. Si una acción es irreversible, Token Security propone comprobar el origen de la instrucción que la desencadenó; The Hacker News añade que las operaciones sensibles pueden necesitar autorización explícita y revisión humana.
La preparación también exige verificar que los controles de parada funcionan: detener ejecuciones activas y pendientes, revocar cada acceso pertinente y limitar conexiones de red sin tumbar servicios ajenos al incidente. The Hacker News recomienda conservar pruebas, separar acciones intentadas de acciones completadas y evaluar por separado los sistemas o datos afectados. Antes de reanudar el flujo, hay que corregir la causa y probarlo con el alcance mínimo necesario.
En el caso descrito por BleepingComputer, dos preguntas de auditoría bastan para mostrar el trabajo pendiente: si la empresa puede identificar a la persona por cuya cuenta actuó un agente hace 60 días y si conoce hoy al responsable de cada agente en producción. La respuesta depende de algo que debe quedar registrado desde el principio: quién delegó la autoridad y a qué agente.
Fuentes: BleepingComputer, The Hacker News, Token Security, Token Security, Token Security
