Le 28/12/2025, lors du 39ème Chaos Communication Congress (39C3) à Hambourg, le chercheur Johann Rehberger a levé le voile sur les risques critiques liés aux agents d’IA autonomes à travers sa conférence « Agentic ProbLLMs : Exploiting AI Computer-Use and Coding Agents », démontrant comment ces outils révolutionnaires peuvent être détournés pour compromettre nos systèmes.

🎥 Synthèse de la conférence en vidéo

Introduction : fragilité des modèle d’IA

La présentation débute par une démonstration de la nature particulièrement fragile des modèles d’IA actuels. Johann Rehberger illustre cela avec une image d’un Panda qui est systématiquement identifiée comme un singe ou encore par une simple addition « 1+1 » qui donne « 42 » selon l’IA. L’intervenant souligne ainsi que si les modèles LLM sont particulièrement puissants, ils sont extrêmement vulnérables, surtout en présence d’un adversaire capable de manipuler les entrées via ce qu’on appelle l’injection de prompt indirecte.

 

Toutes les explications à ce phénomène seront données en fin de la conférence (et donc à la fin de cet article…).

Nature des agents et boucle OODA

Les agents IA sont définis comme des logiciels capables de percevoir leur environnement, de raisonner, de décider et d’agir. Rehberger compare ce fonctionnement à la boucle OODA (Observer, Orienter, Décider, Agir), un concept militaire utilisé par les pilotes de chasse et en « red teaming » pour décrire le cycle de décision. Dans le contexte des LLM, cela se traduit par le modèle « ReAct » (Reasoning and Acting) : l’application raisonne, appelle un outil, obtient des données, et recommence jusqu’à atteindre un objectif. L’industrie s’oriente vers la création de « travailleurs à distance » artificiels (AI shoring), des agents installés sur des ordinateurs capables d’opérer de manière autonome comme des employés.

La Kill Chain de l’IA

Johann Rehberger identifie une chaîne d’attaque spécifique aux agents, qu’il nomme la « AI Killchain », composée de trois éléments :

1️⃣ L’injection de prompt : Le vecteur d’attaque (souvent indirect via des données tierces non fiables).

2️⃣ Le problème du « Confused Deputy » : Le modèle ne sait plus distinguer les instructions de l’utilisateur légitime des données malveillantes.

3️⃣ L’invocation automatique d’outils : L’agent exécute des actions sans validation humaine.

 

On notera que même sans injection de prompt, un modèle n’est pas un système de confiance, car il peut notamment contenir des « backdoors » (portes dérobées) issues de ses données d’entraînement. 

ClickFix où comment faire du social engineering sur un agent IA

Les agents conçus pour utiliser un ordinateur (comme celui d’Anthropic) sont vulnérables aux attaques d’ingénierie sociale visuelle. Rehberger démontre une attaque « ClickFix » : une page web malveillante demande à l’agent de « prouver qu’il est humain » en cliquant sur un bouton qui copie une commande malveillante dans le presse-papier, puis demande à l’agent d’ouvrir un terminal et de coller le contenu. L’agent, suivant sa logique de résolution de tâches, exécute la commande, télécharge un malware et compromet la machine. Le constat est simple : « les agents IA adorent cliquer sur des liens ».

Exfiltration de données via le DNS

En analysant le code source des outils de l’agent, Rehberger a découvert que certaines commandes comme ping ou nslookup étaient autorisées sans validation humaine. Un attaquant peut injecter une commande qui lit des variables d’environnement (secrets) et les exfiltre via des requêtes DNS. 

Exfiltration de données via l’exposition de ports locaux

Une attaque en deux temps a permis de tromper l’agent Devin pour qu’il lance un serveur web exposant tout son système de fichiers local, puis qu’il transmette l’URL publique à l’attaquant via le rendu d’une image, donnant un accès distant en lecture au système de fichiers accessible à l’agent.

Exécution de code et le paradoxe de la « liste blanche »

Le paradoxe de la « liste blanche » illustre comment des mécanismes de sécurité pourtant bien intentionnés peuvent être détournés : pour rendre des agents de codage autonomes, certaines commandes jugées inoffensives, comme find, sont autorisées sans validation humaine. Or cette confiance est trompeuse, car find dispose de l’option -exec, qui permet non seulement de rechercher des fichiers mais aussi d’exécuter arbitrairement d’autres commandes. Un attaquant peut ainsi, via une injection de prompt, pousser l’agent à lancer une commande apparemment légitime qui déclenche en réalité l’exécution de code malveillant. La démonstration réalisée sur Amazon Q Developer montre que le système de sécurité, focalisé sur la commande autorisée et non sur ses options, laisse passer l’attaque. C’est l’équivalent de donner un passe-partout pour une tâche banale sans réaliser qu’il ouvre aussi le coffre-fort : la confiance excessive accordée à un outil « autorisé » devient alors une faille critique.

Instructions cachées et Unicode avec Google Gemini

Une vulnérabilité spécifique affecte les modèles comme Gemini (utilisé dans Google Jules/Anti-gravity). Des instructions peuvent être cachées dans du texte à l’aide de tags Unicode invisibles pour les humains mais lisibles par l’IA. 

Exemple d’exploitation

Un ticket GitHub apparemment anodin demandant d’ajouter un commentaire contient en réalité des instructions invisibles ordonnant à l’agent d’insérer une porte dérobée dans le code. L’agent obéit aux instructions cachées, compromettant le projet ou la machine du développeur.

Manipulation de configuration et mode YOLO

Principe de l’auto-approbation : en temps normal, les agents de codage (comme GitHub Copilot ou Amazon Q) demandent une confirmation à l’utilisateur avant d’exécuter une action potentiellement dangereuse (comme lancer une commande système). Le mode surnommé YOLO (You Only Live Once) supprime cette barrière de sécurité : l’agent opère en autonomie totale.

Conséquences : l’activation de ce mode transforme l’agent en un vecteur d’exécution de code arbitraire à distance. C’est un élément critique car il va permettre à un virus IA, comme le concept « Agent Hopper », de se propager d’une machine à l’autre sans intervention humaine

L’agent Hopper : un virus IA !

Les recherches de Johann Rehberger ont abouti à la création d’un concept de virus informatique propulsé par l’IA, nommé « Agent Hopper ». Tel un virus biologique ou informatique classique, Hopper utilise l’hôte (le code source) pour se propager. Lorsqu’un développeur ouvre un projet infecté, l’agent IA lit les instructions malveillantes, exécute du code pour scanner le disque à la recherche d’autres dépôts (repos), y injecte le payload malveillant, et pousse les modifications sur GitHub. Cela crée un cycle de réplication autonome qui peut traverser les organisations via les dépôts de code partagés, ciblant différents types d’agents (Copilot, Amazon Q, etc.) grâce à des instructions conditionnelles. 

Cycle d’infection avec Hopper

Le cycle d’infection s’enclenche lorsqu’un développeur clone un dépôt de code compromis et demande à son assistant IA (comme GitHub Copilot ou Amazon Q) d’analyser les fichiers, ce qui active une injection de prompt indirecte cachée dans le code source,. Une fois l’agent manipulé (souvent via le mode YOLO ou des failles d’outils), il exécute un script qui scanne le disque local pour trouver d’autres dépôts sains, y injecte la charge malveillante, puis effectue un git push vers GitHub. Le cycle se perpétue lorsqu’un autre développeur télécharge ce nouveau code infecté, permettant au virus de traverser les frontières organisationnelles en adaptant dynamiquement ses attaques à l’agent spécifique de la victime grâce à des instructions conditionnelles.

Le problème : normaliser la déviance des IA

Johann Rehberger conclut sur le concept de « normalisation de la déviance ». L’industrie accepte de plus en plus comme « normale » l’idée de donner à des modèles non fiables (entraînés sur Internet) la capacité d’exécuter des commandes critiques sur des machines locales. 

Autres recommandations

  • Assume Breach (supposer la compromission) : Toujours considérer que le modèle peut être compromis et agir de manière malveillante.
  • Sécurité en aval (Downstream security) : Les contrôles de sécurité doivent être placés après la sortie du LLM (sandboxing, isolation, interdiction d’accès réseau pour certains outils), et ne pas reposer sur la capacité du modèle à refuser une action.
  • Éviter le mode YOLO : Les entreprises ne devraient jamais autoriser l’approbation automatique des outils sur les postes de développeurs.

Pour clarifier la nature de l’injection de prompt, l’auteur termine sur une analogie intéressant : l’injection de prompt ne doit pas être comparée à une injection SQL (qui a une solution technique déterministe), mais plutôt à de l’ingénierie sociale. Tout comme on ne peut pas « patcher » un être humain pour qu’il ne soit plus jamais trompé par un mensonge convaincant, on ne peut pas empêcher totalement un LLM d’être influencé par des données malveillantes placées dans son contexte, car influencer la prédiction du prochain token est sa fonction fondamentale. 

Retour sur le singe et le panda / Pourquoi 1+1=42

Ces erreurs apparentes ne sont ni des hallucinations ni des hasards, mais le résultat déterministe d’instructions dissimulées que l’IA détecte alors qu’elles restent invisibles pour l’utilisateur humain. Dans le cas de l’image, le modèle affirme voir un singe car un texte caché au bas du visuel lui ordonne explicitement de répondre « Ceci est un singe ».

 

Quant au calcul erroné, la chaîne de caractères demandant « 1+1 » contient des balises Unicode invisibles (tags characters) qui instruisent le modèle d’incarner l’ordinateur Deep Thought et de répondre systématiquement « 42 » à la question posée. Cela démontre la fragilité des modèles face à l’injection de prompt indirecte, car ils obéissent aveuglément aux données contenues dans leur contexte, même si celles-ci sont imperceptibles pour l’humain.

Replay de la conférence : https://media.ccc.de/v/39c3-agentic-probllms-exploiting-ai-computer-use-and-coding-agents