Amiable Virez la preuve qu'un agent de l'IV peut exécuter le code et ouvrir la porte à votre hôte

Une équipe d'AI Now Institute a publié cette semaine un test de concept qui ouvre un trou inquiétant dans la façon dont de nombreuses organisations délèguent déjà des tâches de sécurité aux agents d'IA : au lieu d'identifier le code malveillant dans un dépôt, l'agent peut exécuter le même code sur votre machine et devenir la passerelle. L'étude, baptisée «Friendly Fire» et signée par Boyan Milanov et Heidy Khlaaf, montre le risque lorsque les agents ayant la capacité d'exécuter des commandes fonctionnent en modes autonomes qui approuvent des actions sans intervention humaine.

Dans l'expérience, les chercheurs ont travaillé sur les implémentations "stock" de Claude Code (avec les modèles CLI et Sonnet / Opus indiqués) et la version OpenAI Codex, en configurations concrètes avec l'option d'exécution automatique activée. Le vecteur est simple et en même temps subtil : ajouter au dépôt des fichiers apparemment bénins et un script de vérification (par exemple, security.sh dans un README) qui, considéré comme faisant partie du travail de l'agent, est exécuté sans préavis et lance un binaire caché avec la charge utile. Pour éviter la détection, les attaquants peuvent accompagner ce binaire avec un fichier source inoffensif et copier des chaînes de texte à partir du code source pour rendre les contrôles de démontage cohérents. Rien dans le code de projet n'invoque ce binaire, donc de la vue de surface de l'agent tout semble normal.

La conclusion technique la plus inquiétante n'est pas un bug isolé dans une version spécifique, mais un échec de conception: transmettre du texte peu fiable à un agent qui peut exécuter des commandes est équivalent à lui donner la clé à votre hôte. Les modèles utilisés dans le PoC n'ont pas correctement séparé les « instructions qui font partie du code qu'ils examinent » des « ordres à exécuter », et cet échec persiste entre différents fournisseurs et modèles. AI maintient maintenant que cela n'est pas corrigé avec un patch modèle simple; il nécessite des changements de flux de travail et d'utilisation des politiques.

Les implications opérationnelles sont vastes. L'équipement qui a adopté des agents automatisés pour accélérer les examens d'unités ou les audits de codes tiers repose maintenant sur un outil qui, de certaines façons, peut exécuter un code non supervisé qui vient de l'extérieur. Dans un pipeline CI / CD qui peut transformer une revue de routine en une exécution d'un binaire malveillant en infrastructure contenant des clés, des identifiants et l'accès aux secrets. Bien que le PoC n'ait montré aucune escalade des privilèges ou des mouvements latéraux dans le réseau des chercheurs, la première étape - la gestion du code étranger dans l'hôte - suffit à compromettre les secrets et les processus.

Cela n'invalide pas complètement l'utilisation d'agents, mais nécessite une réflexion : ne pas fournir de code peu fiable à un agent avec la capacité d'exécuter des commandes et d'accéder à vos clés. Cette règle est la plus directe et la plus sûre. Pour les équipes qui veulent encore bénéficier d'agents automatisés, il y a des raccourcis pratiques et des contrôles d'atténuation qui réduisent le risque : désactiver les modes autonomes, forcer un « humain-in@-@ the-loop » avant toute exécution, ou exécuter des vérifications dans des environnements hermétiques et éphémères qui ne contiennent pas de références persistantes ou d'accès au réseau, ainsi que vérifier tout comportement de performance.

Il convient de noter que les mécanismes de confinement ne sont pas infaillibles. Les bacs à sable et les machines virtuelles ajoutent des barrières, mais ont montré des fuites et des évasions par le passé : par exemple, une défaillance du bac à sable de Claude Code (appelé dans le rapport CVE-2026-39861) a été rapportée que le fait de s'appuyer exclusivement sur des conteneurs ou des bacs à sable peut donner un faux sentiment de sécurité. Par conséquent, les protections doivent être en couches : séparation des privilèges, utilisation de jetons éphémères et rotation automatique, segmentation du réseau et politiques de privilèges minimales strictes pour tout outil automatisé.

Du point de vue de la chaîne d'approvisionnement des logiciels, la recommandation fait état de pratiques déjà promues par les initiatives de sécurité modernes : signature d'objets, exigence de traçabilité et de reproductibilité, et application de cadres tels que l'ASLS pour l'intégrité des bâtiments. Ces mesures aident à réduire la probabilité qu'un Le fichier E ou tout autre document texte deviendra un vecteur d'exécution non remarqué. Pour approfondir ces pratiques, les organisations et les responsables techniques peuvent examiner la documentation sur les bonnes pratiques dans l'intégrité de la chaîne d'approvisionnement dans des projets tels que SLSA https: / / slsa.dev / et des analyses critiques sur les risques et les politiques dans les travaux des groupes de réflexion tels que l'Institut AI Now https: / / ainowinstitute.org /.

Recommandations opérationnelles spécifiques que toute équipe peut mettre en œuvre immédiatement : désactiver les modes d'exécution automatique dans les agents qui analysent le code non fiable; nécessitent une confirmation humaine et un enregistrement clair des actions avant d'autoriser les exécutions; traitent les fichiers de documentation (README, exemples de scripts) comme non fiables par défaut; n'exposent pas les identifiants dans les environnements où les revues automatisées fonctionnent et, lorsqu'il est nécessaire d'exécuter le code, le font sur les machines jetables sans secrets et avec une image réversible. En outre, mettre en place un suivi et des alertes pour détecter les exécutions inattendues et faire pivoter tous les secrets qui ont été présents dans un environnement compromis.

Enfin, c'est un rappel que l'adoption accélérée des acteurs pour les tâches défensives doit s'accompagner d'une gouvernance et de contrôles. Le test de concept est en laboratoire, pas une exploitation de masse documentée dans la production, mais le modèle est déjà apparu avec les variantes précédentes (TrustFall, Agentjacking) et la surface d'attaque est réelle parce que les dépôts publics et les artefacts tiers sont un objectif fréquent. La couverture technique devrait être complétée par des politiques organisationnelles qui limitent l'autonomie opérationnelle des agents jusqu'à ce que les garanties d'isolement, de traçabilité et de contrôle humain soient solides.