ClawTrojan: la inyección almacenada se convierte en una puerta trasera persistente del agente
Un paper de arXiv del 29 de mayo de 2026 muestra que una inyección oculta en un archivo puede ser almacenada por un agente local y ejecutada después — 95,5 % de éxito frente a casi cero de la inyección de un solo turno.
¿Qué es esto?
El 29 de mayo de 2026, Jiejun Tan, Zhicheng Dou, Xinyu Yang, Yuyang Hu, Yiruo Cheng, Xiaoxi Li y Ji-Rong Wen publicaron From Prompt Injection to Persistent Control: Defending Agentic Harness Against Trojan Backdoors (arXiv:2605.31042, cs.CR/cs.AI/cs.CL). El código y el benchmark se distribuyen bajo la organización de GitHub RUC-NLPIR.
La contribución no es un nuevo payload, sino la medición de un punto ciego: en un harness agéntico local —donde un LLM lee y escribe archivos, invoca herramientas y reutiliza el estado del workspace entre sesiones— una instrucción inyectada no tiene que actuar de inmediato. Puede almacenarse y ejecutarse mucho después. Los autores construyen un benchmark, ClawTrojan, para sacar a la luz estos troyanos de varios pasos, y una defensa, DASGuard, que rastrea el origen real del texto «de control» presente en un workspace. En un workspace simulado de tipo OpenClaw con GPT-5.4, ClawTrojan alcanza una tasa de éxito de ataque (ASR) del 95,5 %, mientras que las inyecciones clásicas de un solo turno rozan cero en el mismo modelo.
Cómo funciona
El ataque reparte un único objetivo malicioso en varios pasos de apariencia inocua. El atacante coloca una inyección en contenido que el agente va a encontrar: un archivo, la salida de una herramienta, un fragmento de contexto recuperado. El agente lee esa instrucción oculta y, punto decisivo, la escribe en el workspace: un archivo de configuración, un archivo de notas, un estado persistido. Más tarde —posiblemente en otra sesión— el agente vuelve a leer su propio workspace, trata el texto plantado como contenido de control legítimo y lo ejecuta.
Paso 1 El agente lee un archivo/salida de herramienta no confiable con texto oculto
Paso 2 El agente escribe ese texto en un archivo local sensible [puerta trasera plantada]
... (parece mantenimiento ordinario del workspace)
Paso N El agente vuelve a leer el archivo y ejecuta la instrucción plantada
La intuición clave es estructural: ningún paso individual parece malicioso. Escribir en un archivo de configuración es rutinario. Releer el estado del workspace es rutinario. El daño solo existe en la secuencia. El paper señala que las defensas existentes inspeccionan cada paso de forma aislada: pueden bloquear una acción final claramente dañina, pero pasan por alto por completo la escritura previa que plantó la puerta trasera. Por eso la inyección de un solo turno roza cero en GPT-5.4 mientras la variante de varios pasos tiene éxito el 95,5 % de las veces — el rechazo por paso del modelo permanece intacto; lo que se explota es el flujo de trabajo.
Es la lección de la contaminación temporal de la memoria y de la exfiltración por memoria latente, aplicada ahora al estado en archivo de un harness de código local en lugar de a una memoria vectorial.
Por qué importa
Los harnesses agénticos locales son precisamente los entornos más afectados. Conservan estado persistente por diseño —eso es lo que los hace útiles entre sesiones— y conceden al agente escritura de archivos y ejecución de herramientas. Esa combinación convierte una cadena almacenada en control latente. Es la tríada letal (contenido no confiable, capacidad sensible, persistencia) expresada a través del sistema de archivos.
Dos consecuencias. Primero, los guardarraíles por acción crean una falsa sensación de seguridad: un harness puede rechazar cada solicitud individualmente peligrosa y seguir totalmente comprometido, porque la instrucción peligrosa se «blanqueó» mediante una escritura inocua más temprano en su historial. Segundo, el radio de impacto es duradero. Una puerta trasera escrita en el estado del workspace sobrevive a los límites de sesión: una sola exposición a un archivo envenenado puede dar control sobre ejecuciones futuras que el operador nunca relaciona con la inyección original.
Son resultados simulados sobre un benchmark, no una campaña observada en el mundo real, y el harness es de tipo OpenClaw y no un producto comercial concreto. La lectura correcta es una cota inferior sobre una clase de debilidad, no un fallo propio de un fabricante.
Defensas
La defensa propuesta, DASGuard, se basa en el rastreo de procedencia, y su diseño se generaliza en pautas concretas.
-
Rastrear la procedencia del texto «de control». DASGuard analiza los archivos locales sensibles en busca de contenido que parezca instrucciones o flujo de control, rastrea su origen y elimina el contenido de control que no proviene de una fuente confiable. El principio: la autoridad de una cadena debe depender de su origen, no de dónde se encuentra ahora. Esto enlaza con los trabajos data-flow-is-not-authority y grafo de procedencia.
-
Defender la secuencia, no el paso. Como ninguna acción aislada es maliciosa, el filtrado por acción es insuficiente. Correlacione las operaciones de escritura con lecturas posteriores del mismo artefacto, y convierta «el agente escribe texto con forma de instrucción en su propio estado y luego actúa sobre él» en un objetivo de detección de primer orden.
-
Combinar bloqueo en ejecución con commits saneados. DASGuard combina el bloqueo del ataque en tiempo de ejecución con commits saneados al workspace: no solo detiene la acción en vivo, sino que limpia la puerta trasera plantada del estado persistido para que no se dispare después. Trate el estado del workspace como no confiable hasta su validación, tanto en escritura como en lectura.
-
Restringir el harness. Acceso a archivos con mínimo privilegio, separación del estado modificable por el agente respecto de la configuración legible por el agente, y control de egress acotan lo que una instrucción plantada puede lograr, sea cual sea su forma de blanqueo. Es la postura arquitectónica de la regla de dos de los agentes.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Paper publicado | arXiv:2605.31042 [cs.CR] | 2026-05-29 | «From Prompt Injection to Persistent Control: Defending Agentic Harness Against Trojan Backdoors» |
| Benchmark | ClawTrojan | — | Detección de troyanos de varios pasos en harnesses agénticos locales |
| Defensa | DASGuard | — | Escaneo de procedencia del texto de control + commits saneados |
| Evaluación | Workspace tipo OpenClaw, GPT-5.4 | — | 95,5 % de ASR de varios pasos vs. casi nulo en un solo turno |
| Código y datos | github.com/RUC-NLPIR/ClawTrojan | — | Publicados con el paper |
| Estado de explotación | Nada observado en el mundo real | — | Benchmark simulado; sin payloads contra sistemas vivos |
La conclusión no es «los agentes son vulnerables a la inyección» —eso ya se sabe—. Es que la persistencia convierte una instrucción rechazada en una instrucción almacenada, y la defensa debe leer el historial del workspace del agente, no solo su próxima acción.