sistema: OPERATIVO
← volver a todos los hacks
DEFENSE LOW NEW

Auditar los flujos de tokens de un agente antes de los puntos sensibles

Un artículo de julio de 2026 replantea la seguridad de los agentes persistentes en torno a los flujos de tokens en lenguaje natural, inspeccionados en la frontera antes de escribir en memoria o llamar a una herramienta.

2026-07-14 // 6 min affects: llm-agents, openclaw, persistent-agents, gemini-3.1-pro, agent-memory

¿Qué es esto?

Un agente de IA persistente no es un chatbot. Funciona a lo largo de varias sesiones, escribe en una memoria de larga duración, instala y reutiliza habilidades, y llama a herramientas que tocan archivos, redes y servicios de terceros. Esa persistencia cambia el modelo de seguridad: una salida del modelo ya no es una respuesta efímera, sino una transición de estado — puede escribirse en memoria, disparar una acción o modificar un componente reutilizable, y luego condicionar el comportamiento del agente días después. Una entrada contaminada inyectada en una interacción puede quedar latente y activarse en otra.

Un artículo publicado en arXiv el 9 de julio de 2026, Token-Flow Firewall: Semantic Runtime Auditing for Persistent AI Agents (2607.08395), firmado por Puji Wang, Yingchen Zhang, Ruqing Zhang, Jiafeng Guo y Xueqi Cheng (State Key Laboratory of AI Safety e Institute of Computing Technology, Academia China de Ciencias), propone una defensa en tiempo de ejecución basada en una observación: dentro de un agente así, casi toda interacción sensible circula en forma de texto en lenguaje natural. Es un estudio defensivo, no una técnica de ataque.

Cómo funciona

Los autores llaman a estas transferencias flujos de tokens semánticos — las unidades mínimas de contenido visible por el modelo que cruzan una frontera del sistema y pueden comprometerse al estado persistente o a una ejecución externa. Escrituras en memoria, argumentos de herramientas, archivos recuperados y mensajes entre componentes son todos flujos de tokens. La idea: ese es el lugar donde debe imponerse la seguridad — no después de que una acción haya ocurrido (el nivel en el que suelen construirse las trazas de ejecución y los grafos de llamadas a herramientas), sino en el punto de transferencia semántica, antes de que cambie el estado.

Su marco, TokenWall, se sitúa en esas fronteras como un cortafuegos. Cada flujo se modela con un registro compacto — segmentos de la carga útil, origen, destino (sink), metadatos de ejecución y frontera a cruzar — y se clasifica en tres superficies: flujos de contexto (contenido a punto de entrar en el razonamiento, la memoria o las habilidades), flujos de autoridad (transferencias que cambian por quién actúa el agente, su sesión o sus objetivos de acción) y flujos de capacidad (argumentos de herramientas, comandos, operaciones sobre archivos, divulgación hacia el exterior). Para cada uno se toma una decisión entre cuatro opciones: permitir, reescribir y continuar, derivar a un humano, o bloquear.

La aplicación es por capas para mantener el coste bajo. Una comprobación previa determinista y ligera capta las violaciones explícitas — secretos, operaciones destructivas, destinos conocidos como maliciosos. Los casos ambiguos pasan a un pequeño modelo auditor local (el artículo usa Qwen3-4B) que puntúa el riesgo, la explotabilidad y el impacto, y puede reescribir un segmento riesgoso preservando la tarea legítima. Solo los flujos realmente de alto impacto o inciertos se escalan a un árbitro más potente. Mantener la vía por defecto en local es deliberado: las arquitecturas anteriores de «enviar todo el contexto a un gran modelo remoto» son lentas y exponen fuera de la máquina un estado de agente sensible. Informes mal formados, reescrituras inválidas y tiempos de espera del auditor fallan en posición cerrada (fail-closed).

En CIK-Bench — un banco de pruebas orientado a ataques sobre el estado persistente y entre sesiones contra agentes personales, ejecutado a través de un runtime de tipo OpenClaw instrumentado — los autores informan de una tasa de éxito de ataque que cae al 12,5 % (frente al 14,7 % de la mejor línea base de ejecución con igual presupuesto), manteniendo una tasa de aprobación benigna del 97,4 % y añadiendo solo 0,69 segundos de latencia por caso benigno. Se trata de la descripción de una clase de defensa: el valor está en la abstracción de flujos y en el punto de intervención, no en un payload listo para usar.

Por qué importa

El replanteamiento es lo esencial. La mayoría de las defensas de agentes actúan en la puerta (filtros de entrada) o sobre la acción (políticas de llamada a herramientas), dejando un punto ciego donde texto no confiable se convierte discretamente en estado persistente. Una mediación a nivel de frontera, antes de la transferencia, apunta precisamente a los fallos diferidos, acumulativos y difíciles de revertir — envenenamiento de memoria, redefinición de autoridad, mal uso de herramientas a destiempo — que los controles a nivel de acción no detectan, porque el daño se sembró mucho antes de que la acción se disparara. Visto desde el lado del atacante, el mismo mapa indica dónde buscar: toda transferencia que modifique la memoria, cambie por quién actúa el agente o alcance una herramienta es una frontera que sondear, y cada una dejada sin auditar es un punto ciego.

Defensas

Para los equipos que operan agentes de larga duración o dotados de memoria:

  • Instrumente las fronteras, no solo los extremos. Identifique cada punto donde un contenido entra en memoria, cambia la autoridad o alcanza una herramienta, e inspeccione la transferencia antes de que se comprometa — el registro a posteriori constata el daño una vez hecho.
  • Separe la intención de la evidencia. Derive el objetivo del agente únicamente de señales de ejecución confiables y de peticiones explícitas del propietario; trate los documentos recuperados, las salidas de herramientas y el texto de terceros como evidencia a verificar, nunca como instrucciones.
  • Prefiera una mediación local y fail-closed. Un pequeño auditor embarcado evita enviar contexto de agente sensible a un modelo remoto; ante una comprobación mal formada o expirada, bloquee en lugar de dejar pasar.
  • Reserve la revisión pesada para los casos difíciles. Reglas deterministas para las violaciones evidentes, un modelo ligero para los casos ambiguos, la escalada reservada a los flujos de alto impacto o inciertos — una inspección de cobertura completa solo es asumible si la mayoría de los flujos se resuelven a bajo coste.
  • Considere esto un resultado de investigación. Las cifras provienen de un solo banco de pruebas y de modelos concretos (Gemini 3.1 Pro como modelo de tarea, Qwen3-4B como auditor); la robustez frente a atacantes adaptativos y a otras pilas de agentes sigue siendo una cuestión abierta.

Estado

ElementoDetalle
HallazgoLos cambios de estado sensibles de los agentes persistentes circulan como flujos de tokens en lenguaje natural; auditarlos en las fronteras de transferencia permite una contención antes de la ejecución
FuenteToken-Flow Firewall: Semantic Runtime Auditing for Persistent AI Agents, Wang et al., State Key Laboratory of AI Safety / ICT, Academia China de Ciencias, arXiv, 9 de julio de 2026
MarcoTokenWall — comprobación previa determinista + pequeño modelo auditor local + arbitraje de reserva; acciones: permitir, reescribir, derivar, bloquear
Resultado claveTasa de éxito de ataque del 12,5 % frente al 14,7 % de la mejor línea base; 97,4 % de aprobación benigna; +0,69 s de latencia por caso benigno en CIK-Bench
TipoInvestigación defensiva / método de contención en ejecución (preprint; sin CVE)

Sources