Le risque le plus gênant des agents IA autonomes n’est pas qu’ils écrivent du mauvais code. Les équipes le savent déjà. Le vrai problème apparaît quand un agent lit du texte non fiable et le transforme en action locale.

Agent IA derrière une frontière de confiance

Friendly Fire, publié par l’AI Now Institute le 8 juillet, illustre ce point. Boyan Milanov et Heidy Khlaaf décrivent un chemin vers l’exécution de code contre Anthropic Claude Code CLI et OpenAI Codex CLI lorsqu’ils sont utilisés pour auditer la sécurité d’une bibliothèque tierce.

Ce n’est pas une attaque massive contre tous les utilisateurs. Il faut un agent capable d’exécuter des commandes, une codebase non fiable et un mode autonome: auto-mode pour Claude Code ou auto-review pour Codex, selon AI Now et The Hacker News. Dans ce scénario, l’agent lit le dépôt, interprète la documentation et peut lancer une commande sans validation humaine.

Pour les entreprises, c’est le point central. Les agents arrivent dans le code review, le triage Sentry, la génération de patchs, l’analyse de dépendances et l’assistance CI. Plus l’agent est utile, plus il reçoit d’outils: shell, fichiers, package manager, dépôts, parfois secrets.

À ce stade, ce n’est plus un chatbot. C’est de l’automatisation privilégiée.

Ce que montre Friendly Fire

AI Now décrit une copie modifiée de la bibliothèque Python geopy. Les chercheurs ont ajouté une instruction dans le README, un script, un fichier leurre et un binaire précompilé. Le dépôt public précise que le binaire publié ne contient pas le code malveillant.

La leçon utile n’est pas le payload. Elle tient dans la frontière cassée: l’agent peut passer de “analyse ce projet” à “exécute cette commande suggérée par le projet”.

AI Now cite des tests avec Claude Code CLI 2.1.116, 2.1.196, 2.1.198 et 2.1.199, avec Claude Sonnet 4.6, Sonnet 5 et Opus 4.8, ainsi qu’OpenAI Codex CLI 0.142.4 avec GPT-5.5. Les auteurs parlent d’un problème de conception du workflow, pas d’une seule version vulnérable.

Pourquoi un README suffit

Un README sert à guider le lecteur. Il explique comment construire, tester ou vérifier un projet. Un humain peut s’arrêter avant d’exécuter un binaire inconnu.

Un agent, lui, cherche à terminer la tâche. Si sa politique autorise certaines commandes, le texte du dépôt peut devenir un chemin entre données non fiables et exécution locale.

C’est la même famille de risques que les injections via tickets, issues, logs, pages web ou sortie d’outil. L’entrée n’a pas l’air d’être du code, mais elle influence la prochaine action de l’agent.

Ce n’est pas un cas isolé

Friendly Fire suit Agentjacking de Tenet Security, où de faux événements Sentry pouvaient atteindre des agents via MCP. Tenet a parlé de 2 388 organisations exposées et d’un taux de réussite de 85% en tests contrôlés; ce sont les chiffres de cette étude, pas une moyenne du marché.

Sophos X-Ops a aussi montré que des agents de coding peuvent déclencher des règles EDR proches de comportements d’attaquant: PowerShell, accès aux identifiants, téléchargements via outils système et actions ressemblant à de la persistance.

Les rapports sont différents, mais la question est la même: que peut faire l’agent quand l’entrée est hostile?

Ce que les équipes doivent changer

Séparez les workflows fiables et non fiables. Nettoyer un dépôt interne et auditer une bibliothèque téléchargée ne devraient pas partager la même politique.

Désactivez l’approbation automatique de commandes pour les dépôts externes, logs, événements Sentry et issues non fiables.

Donnez aux agents une identité dédiée. Ils ne doivent pas hériter de tous les accès GitHub, cloud et production du développeur.

Retirez les secrets de l’environnement: variables, clés SSH, cookies navigateur, password managers, credentials cloud. Un sandbox qui contient les vrais secrets n’est pas une frontière.

Traitez scripts, installations, binaires, automatisation navigateur et réseau comme des actions à risque. Elles doivent demander une validation humaine ou être bloquées.

Journalisez la source d’entrée, les appels d’outils, les commandes approuvées, l’arbre de processus, les destinations réseau et les écritures fichiers.

Ce que les fournisseurs doivent fournir

Les agents ont besoin de frontières de confiance dans le produit. Le contenu non fiable devrait garder une étiquette: texte de dépôt, commentaire, log, événement Sentry, page web, sortie MCP. Une politique d’outils doit pouvoir dire: ceci peut informer l’analyse, mais ne peut pas autoriser une exécution.

“Autonomous” est trop vague. Les entreprises doivent savoir si l’agent peut lancer un shell, installer des paquets, exécuter des binaires, ouvrir le réseau, lire des fichiers cachés, utiliser MCP ou écrire hors du workspace.

Les admins ont aussi besoin de contrôles centraux: managed settings, audit export, allowlists, deny rules et defaults sûrs pour les audits de code non fiable.

Les agents deviendront normaux dans le développement. Normal ne veut pas dire inoffensif. Les runners CI sont normaux, et on les isole quand même. La règle pratique: ne demandez pas si vous faites confiance à l’agent; définissez ce qu’il peut faire quand vous ne faites pas confiance à l’entrée.