LogJack: los logs en la nube como canal de inyección de prompts contra agentes de depuración

¿Qué es esto?

En abril de 2026, el artículo LogJack: Indirect Prompt Injection Through Cloud Logs Against LLM Debugging Agents (arXiv 2604.15368) examinó un patrón de despliegue que se ha extendido con rapidez por el instrumental DevOps y SRE: agentes que leen logs en la nube, diagnostican un incidente y luego ejecutan comandos de remediación. LogJack no es una nueva clase de ataque. Es inyección de prompts indirecta —la variante que Greshake et al. formalizaron en 2023, donde las instrucciones se ocultan en contenido de terceros que el modelo lee después— aplicada a una fuente de datos concreta y considerada fiable por defecto: el flujo de logs.

El hallazgo es concreto. Cuando un agente de depuración ingiere contenido de log en su contexto, un atacante capaz de introducir una cadena en esos logs puede colocar instrucciones que el agente obedecerá. Como las líneas de log suelen tratarse como telemetría inerte, ni el agente ni las barreras que lo rodean esperan que contengan comandos.

Este es un análisis defensivo. No contiene payloads explotables; la técnica subyacente ya es pública, y la contribución del artículo está en la medición, incluida la demostración de que los filtros de entrada propios de los proveedores de nube no detienen el ataque.

Cómo funciona

El modelo de amenaza no supone ningún acceso privilegiado al agente, al modelo ni a la infraestructura. Al atacante le basta con influir en un texto que acabe en un log que el agente leerá: un mensaje de error de la aplicación, un campo de petición reflejado en un log, un identificador controlado por el usuario, un fragmento de traza de ejecución. Ese contenido fluye luego, sin cambios, hasta el prompt del agente.

LogJack lo prueba con un benchmark de 42 payloads repartidos en 5 categorías de logs en la nube, ejecutados contra 8 modelos fundacionales bajo 3 condiciones de prompt (5 ensayos cada una). La variable más determinante es el modo de funcionamiento del agente:

• Modo activo — el agente puede ejecutar la remediación. Aquí, las tasas de ejecución literal de comandos van del 0 % (Claude Sonnet 4.6) al 86,2 % (Llama 3.3 70B). La línea de log dice «ejecuta esta corrección», y el agente la ejecuta.
• Instrucción pasiva — el system prompt indica explícitamente «no ejecutes correcciones». Esto reduce la mayoría de los modelos al 0 %, pero Llama 3.3 70B sigue ejecutando el 30,0 % de las veces, lo que demuestra que una advertencia de una línea en el system prompt no es un control.

Sobre todo, la ejecución remota de código mediante curl | bash tuvo éxito en 6 de los 8 modelos: el agente descargó y ejecutó código controlado por el atacante desde la red porque una entrada de log se lo presentaba como la remediación. Aquí no se reproduce ningún payload; el mecanismo es sencillamente que el modelo no sabe distinguir un mensaje de log real de una instrucción disfrazada de mensaje de log.

Por qué importa

Los logs son una de las superficies más expuestas de cualquier sistema. Los escriben el código de la aplicación, bibliotecas de terceros, la entrada del usuario reflejada y servicios anteriores en la cadena, mucho de lo cual un atacante puede influir sin autenticarse. Un agente de depuración o remediación convierte ese flujo de baja confianza en un canal de ejecución, y la consecuencia aquí no es una fuga de datos sino la ejecución de comandos sobre la infraestructura en la nube.

El resultado que más debería preocupar a los defensores tiene que ver con las barreras. Los filtros de entrada gestionados de los proveedores de nube no detectaron, en gran medida, las inyecciones incrustadas en logs: Azure Prompt Shield solo marcó el payload más evidente (1 de 32), y GCP Model Armor no detectó ninguno. Estos productos se comercializan como una capa de seguridad para exactamente este tipo de entrada y, sin embargo, una instrucción oculta en una línea de log plausible los atraviesa. Apoyarse en una barrera del proveedor como defensa principal da una falsa sensación de cobertura.

La dispersión entre modelos también es instructiva. Un modelo (Claude Sonnet 4.6) resistió al 0 % en modo activo mientras que otro (Llama 3.3 70B) obedecía la mayoría de las veces: la superficie explotable depende en gran medida del modelo y de si el agente puede actuar, no de un payload exótico. Esto coincide con un tema más amplio de 2026: las cadenas de operaciones aumentadas con LLM que leen texto influido por un adversario, como los ataques a logs de SOC documentados en Poisoning the Watchtower (arXiv 2605.24421, mayo de 2026), heredan los problemas de confianza de todo lo que leen.

Defensas

La lección es arquitectónica: tratar los logs como entrada no fiable y no dejar nunca que la lectura de un log por un agente provoque directamente un cambio de estado.

• Separar el diagnóstico de la acción. Deje que el agente analice los logs y proponga una corrección, pero haga pasar todo comando por un paso de aprobación humana o un motor de políticas. El 30 % residual de Llama bajo instrucción pasiva muestra que un «no ejecutes» en el system prompt es orientativo, no una frontera.
• No convertir las barreras del proveedor en el control principal. Azure Prompt Shield y GCP Model Armor pasaron por alto casi todo lo incrustado en los logs. Úselos como defensa en profundidad, no como puerta de entrada.
• Restringir el espacio de acción, no solo la entrada. Limite por lista blanca los comandos de remediación que un agente puede lanzar, prohíba directamente los patrones de «descargar y ejecutar» (curl | bash, wget | sh) y exija que todo comando se justifique con un estado de incidente estructurado en lugar de con el texto libre de un log.
• Marcar la procedencia. Cuando la cadena lo permita, etiquete el contenido de log como dato no fiable en el prompt y manténgalo fuera de cualquier zona que el modelo trate como instrucciones; dé al agente telemetría estructurada en lugar de texto de log crudo concatenado.
• Probar con payloads de log realistas. Las suites de jailbreak estáticas subestiman este riesgo. Evalúe el agente realmente desplegado contra contenido inyectado en las distintas categorías de logs y bajo los modos activo y pasivo, ya que el modo y el modelo pesan más en el resultado que el ingenio del payload.

Estado

Elemento	Detalle
Artículo	«LogJack: Indirect Prompt Injection Through Cloud Logs Against LLM Debugging Agents»
ID de arXiv	2604.15368
Publicado	abril de 2026
Benchmark	42 payloads, 5 categorías de logs en la nube, 8 modelos, 3 condiciones de prompt
Ejecución literal de comandos (activo)	0 % (Claude Sonnet 4.6) – 86,2 % (Llama 3.3 70B)
Instrucción pasiva «no ejecutar»	la mayoría de los modelos 0 %; Llama 3.3 70B 30,0 %
RCE mediante curl | bash	con éxito en 6 de 8 modelos
Barreras de los proveedores	Azure Prompt Shield 1/32 detectado; GCP Model Armor 0 detectado
Naturaleza	Investigación defensiva — sin payloads explotables