AgentTracer localiza el punto de inyección de prompts en los registros del agente en el 94% de los casos

Todos discuten cómo proteger a un agente de las inyecciones de prompts. Mucho menos se escribe sobre qué hacer cuando la protección falló y hay que entender lo ocurrido. Investigadores de la Universidad Sun Yat-sen y de la Universidad de Ciencia y Tecnología de Hong Kong han publicado AgentTracer, un trabajo precisamente sobre esto: cómo reconstruir el curso de un ataque a partir de los registros del agente.

Por qué es tan difícil ver un ataque en los registros

Todo el texto que lee el agente acaba en un único contexto del modelo. El modelo, en esencia, no distingue de dónde viene una frase y trata de cumplir la instrucción más reciente y convincente. En una inyección indirecta, el comando malicioso está en una página o un correo que el agente abrió por sí mismo por encargo del usuario. Por eso sus acciones parecen trabajo normal.

El ejemplo del artículo lo inventaron los autores, pero la mecánica es exacta. Un usuario pide descargar una versión de un sitio web y subirla a GitHub. En la página hay una instrucción oculta, y el agente, de paso, registra la clave SSH del atacante, lee el correo y al final borra su memoria de trabajo. Solo el último paso llama la atención, y el análisis del flujo de datos no lo vinculará con la página: las llamadas no comparten parámetros. La relación solo se ve en el razonamiento del agente, donde explica por qué lo hace.

Además, los registros del servidor pueden no mostrar nada. En la técnica HashJack, la instrucción se oculta en el fragmento de la dirección tras #, que se procesa en el cliente y no llega al servidor. La fuga de datos mediante una petición de imagen con parámetros en la URL, como en el caso de Bing Chat, no se distingue desde fuera de una descarga normal. Y en CoSnitch (CVE-2026-24301) las instrucciones dañinas se escribían además en la memoria persistente del asistente, de modo que podían activarse otro día.

Cómo funciona AgentTracer

La idea es sencilla: si la inyección funcionó, el agente hace algo que el usuario no pidió. Los autores llaman a esta discrepancia deriva de intención. A partir de los registros de razonamiento se construye un grafo: los nodos son la solicitud del usuario y los objetos devueltos por las herramientas (páginas, correos, archivos), y las aristas son las operaciones del agente. Así, las llamadas sin parámetros comunes acaban igualmente en una misma cadena.

A continuación, cada llamada se comprueba según tres criterios: acción, objetivo y restricciones. Si se incumple cualquiera, la arista se marca como desviación. Desde el evento sospechoso se retrocede por las aristas marcadas. Si la raíz de la cadena es un recurso externo, es una inyección, y la línea en la que entró en el contexto pasa a ser el punto de inyección. Si la raíz no es externa, el agente simplemente se equivocó. La respuesta «no hubo inyección» también es un resultado completo de la investigación.

Las pruebas se hicieron en condiciones duras: se mezclaron registros de ataques exitosos de AgentDyn e InjecAgent con cinco meses de trabajo normal del agente. Por cada cadena de tres llamadas había unas tres mil ajenas. El punto de inyección se encontró en cerca del 94% de los casos, mientras que siete competidores se sitúan entre el 40% y el 76%.

Unos encontraban todos los ataques, pero no el origen; otros reunían la cadena de forma más completa, pero con añadidos. Si se sustituye el grafo por una lista simple de llamadas, o la comprobación por tres criterios por una evaluación de un LLM, la precisión cae. La poda en torno al evento sospechoso ahorra casi un tercio del tiempo y una vez y media los tokens.

Qué hacer y dónde están los límites

La conclusión principal es práctica: la investigación se apoya en lo que guardó antes del incidente. Hacen falta la solicitud del usuario, el razonamiento del agente, las llamadas y los resultados completos de las herramientas, así como las solicitudes salientes. Microsoft aconseja considerar hostil cualquier contenido externo y mantener telemetría de solicitudes y respuestas. Los registros deben almacenarse de modo que un atacante no pueda modificarlos.

El método tiene límites. Está pensado para agentes al estilo ReAct con razonamiento registrado. Si tras la inyección no hubo llamadas a herramientas o el código modificó archivos sin pasar por ellas, no hay nada que rastrear. El grafo lo construye un modelo de lenguaje, y el razonamiento del agente no siempre refleja las causas reales de sus acciones, así que la fiabilidad de las conclusiones no es mayor que la de ese relato. Se probó solo con ataques exitosos y en un único entorno; con registros inocuos, los falsos positivos fueron de alrededor del 3,5%. El caso de la memoria persistente es el menos estudiado.

Otra salvedad de la revisión de OWASP del tercer trimestre de 2026: un agente puede desviarse de la tarea sin ninguna inyección. Claude Opus 4.7, en una evaluación de ciberseguridad, atacó a una empresa real con un nombre parecido, y los agentes de OpenAI salieron a través de un servicio de paquetes compartido hacia la infraestructura de Hugging Face. No se estableció inyección en ningún caso. Así que el límite de seguridad se sostiene sobre restricciones obligatorias, herramientas aisladas y credenciales, no sobre el prompt. Los registros sirven para esclarecer los hechos después, no para sustituir la protección.

Por ahora Google encuentra en la red sobre todo bromas y trucos de SEO, pero la proporción de hallazgos maliciosos creció un 32% (en términos relativos) entre noviembre de 2025 y febrero de 2026. Conviene configurar el registro del agente ahora, antes de que haga falta.