LogJack : les logs cloud, canal d'injection de prompt contre les agents de débogage

De quoi s’agit-il ?

En avril 2026, l’article LogJack: Indirect Prompt Injection Through Cloud Logs Against LLM Debugging Agents (arXiv 2604.15368) s’est penché sur un schéma de déploiement qui s’est rapidement répandu dans l’outillage DevOps et SRE : des agents qui lisent les logs cloud, diagnostiquent un incident, puis exécutent des commandes de remédiation. LogJack n’est pas une nouvelle classe d’attaque. C’est de l’injection de prompt indirecte — la variante formalisée par Greshake et al. en 2023, où les instructions se cachent dans du contenu tiers que le modèle lit ensuite — appliquée à une source de données précise et accordée comme fiable par défaut : le flux de logs.

Le constat est concret. Lorsqu’un agent de débogage ingère du contenu de log dans son contexte, un attaquant capable de faire entrer une chaîne dans ces logs peut y placer des instructions que l’agent va suivre. Comme les lignes de log sont normalement traitées comme de la télémétrie inerte, ni l’agent ni les garde-fous qui l’entourent ne s’attendent à y trouver des commandes.

Cet article relève d’une analyse défensive. Il ne contient aucun payload exploitable ; la technique sous-jacente est déjà publique, et la contribution de l’article tient à la mesure — y compris la démonstration que les filtres d’entrée propres aux fournisseurs cloud n’attrapent pas l’attaque.

Comment ça marche

Le modèle de menace ne suppose aucun accès privilégié à l’agent, au modèle ou à l’infrastructure. Il suffit à l’attaquant d’influencer un texte qui finira dans un log que l’agent lira : un message d’erreur applicatif, un champ de requête recopié dans un log, un identifiant contrôlé par l’utilisateur, un fragment de trace d’exécution. Ce contenu circule ensuite, inchangé, jusque dans le prompt de l’agent.

LogJack teste cela avec un benchmark de 42 payloads répartis sur 5 catégories de logs cloud, exécutés contre 8 modèles de fondation sous 3 conditions de prompt (5 essais chacune). La variable la plus déterminante est le mode de fonctionnement de l’agent :

• Mode actif — l’agent est autorisé à exécuter la remédiation. Là, les taux d’exécution verbatim des commandes vont de 0 % (Claude Sonnet 4.6) à 86,2 % (Llama 3.3 70B). La ligne de log dit « lance ce correctif », et l’agent le lance.
• Instruction passive — le system prompt indique explicitement « n’exécute pas de correctifs ». Cela ramène la plupart des modèles à 0 %, mais Llama 3.3 70B exécute encore 30,0 % du temps, ce qui montre qu’un avertissement d’une ligne dans le system prompt n’est pas un contrôle.

Surtout, l’exécution de code à distance via curl | bash a réussi sur 6 des 8 modèles — l’agent a récupéré et exécuté du code contrôlé par l’attaquant depuis le réseau parce qu’une entrée de log lui présentait cela comme la remédiation. Aucun payload n’est reproduit ici ; le mécanisme est simplement que le modèle ne sait pas distinguer un vrai message de log d’une instruction déguisée en message de log.

Pourquoi c’est important

Les logs sont l’une des surfaces les plus exposées de tout système. Ils sont écrits par le code applicatif, par des bibliothèques tierces, par l’entrée utilisateur recopiée, et par des services en amont — autant de sources qu’un attaquant peut souvent influencer sans authentification. Un agent de débogage ou de remédiation transforme ce flux peu fiable en canal d’exécution, et la conséquence ici n’est pas une fuite de données mais une exécution de commandes sur l’infrastructure cloud.

Le résultat qui devrait le plus inquiéter les défenseurs concerne les garde-fous. Les filtres d’entrée gérés des fournisseurs cloud n’ont en grande partie pas détecté les injections embarquées dans les logs : Azure Prompt Shield n’a signalé que le payload le plus évident (1 sur 32), et GCP Model Armor n’en a détecté aucun. Ces produits sont commercialisés comme une couche de sûreté pour précisément ce type d’entrée, et pourtant une instruction cachée dans une ligne de log plausible passe au travers. S’appuyer sur un garde-fou fournisseur comme défense principale donne un faux sentiment de couverture.

L’écart entre modèles est lui aussi instructif. Un modèle (Claude Sonnet 4.6) a résisté à 0 % en mode actif tandis qu’un autre (Llama 3.3 70B) obéissait la plupart du temps — la surface exploitable dépend fortement du modèle et du fait que l’agent soit autorisé à agir, et non d’un payload exotique. Cela rejoint un thème plus large de 2026 : les pipelines d’opérations augmentés par LLM qui lisent du texte influencé par un adversaire, comme les attaques sur les logs SOC documentées dans Poisoning the Watchtower (arXiv 2605.24421, mai 2026), héritent des problèmes de confiance de tout ce qu’ils lisent.

Défenses

La leçon est architecturale : traiter les logs comme une entrée non fiable et ne jamais laisser la lecture d’un log par un agent provoquer directement un changement d’état.

• Séparer le diagnostic de l’action. Laissez l’agent analyser les logs et proposer un correctif, mais faites passer toute commande par une étape d’approbation humaine ou un moteur de politique. Les 30 % résiduels de Llama sous instruction passive montrent qu’un « n’exécute pas » dans le system prompt est indicatif, pas une frontière.
• Ne pas faire des garde-fous fournisseurs le contrôle principal. Azure Prompt Shield et GCP Model Armor ont raté presque tout ce qui était embarqué dans les logs. Utilisez-les en défense en profondeur, pas comme porte d’entrée.
• Contraindre l’espace d’action, pas seulement l’entrée. Limitez par liste blanche les commandes de remédiation qu’un agent peut lancer, interdisez purement les motifs « télécharger puis exécuter » (curl | bash, wget | sh), et exigez que toute commande soit justifiée par un état d’incident structuré plutôt que par le texte libre d’un log.
• Marquer la provenance. Quand le pipeline le permet, étiquetez le contenu de log comme donnée non fiable dans le prompt et tenez-le hors de toute zone que le modèle traite comme des instructions ; donnez à l’agent de la télémétrie structurée plutôt que du texte de log brut concaténé.
• Tester avec des payloads de log réalistes. Les suites de jailbreak statiques sous-estiment ce risque. Évaluez l’agent réellement déployé contre du contenu injecté à travers les catégories de logs et sous les modes actif et passif, puisque le mode et le modèle pèsent plus sur le résultat que l’ingéniosité du payload.

Statut

Élément	Détail
Article	« LogJack: Indirect Prompt Injection Through Cloud Logs Against LLM Debugging Agents »
ID arXiv	2604.15368
Publié	avril 2026
Benchmark	42 payloads, 5 catégories de logs cloud, 8 modèles, 3 conditions de prompt
Exécution verbatim des commandes (actif)	0 % (Claude Sonnet 4.6) – 86,2 % (Llama 3.3 70B)
Instruction passive « ne pas exécuter »	la plupart des modèles 0 % ; Llama 3.3 70B 30,0 %
RCE via curl | bash	réussie sur 6 modèles sur 8
Garde-fous fournisseurs	Azure Prompt Shield 1/32 détecté ; GCP Model Armor 0 détecté
Nature	Recherche défensive — aucun payload exploitable