Le « harness » des agents IA devient une nouvelle faille de sécurité

Quand on demande à un responsable de la sécurité où se situe le risque des agents IA, la première réponse porte presque toujours sur le modèle lui-même : peut-on le contourner par jailbreak, peut-on faire confiance à ses poids. Ce réflexe est de plus en plus dépassé. Un nombre croissant de démonstrations d'exploitation, de tests red team indépendants et d'évaluations de chercheurs pointe plutôt vers le code qui se situe entre le modèle et le monde extérieur. Ce code porte un nom : le « harness ». Il équipe le modèle d'outils et transforme sa production textuelle en actions réelles — une commande shell, une écriture de fichier, un appel API. Or cette couche logicielle reste, dans beaucoup d'entreprises, mal inventoriée, peu testée et sans responsable clairement identifié.

Ce qu'est concrètement un harness d'IA

Interrogés séparément, les praticiens convergent vers des métaphores différentes mais complémentaires. Michael Bargury, cofondateur et directeur technique de l'éditeur de sécurité IA Zenity, le décrit comme « les mains, les jambes et les yeux » du modèle : celui-ci ne produit que des jetons de texte, c'est le harness qui les transforme en commande shell, en écriture de fichier ou en appel d'API. Rob T. Lee, responsable IA et de la recherche au SANS Institute, compare le modèle à un moteur et le harness au châssis. Michael Sromin, ingénieur senior en apprentissage automatique chez Lasso Security, y voit le système d'exploitation qui pilote toute la boucle d'une application agentique et relie modèle, outils et utilisateur. Omar Santos, ingénieur émérite chez Cisco, en donne la définition la plus formelle : la couche qui entoure un modèle et le rend utilisable — orchestration, usage des outils, prompts, contexte, rôles, évaluations et garde-fous compris. Ces quatre définitions convergent vers le même constat : c'est dans le harness que s'exerce concrètement l'autorité d'un agent. Il se situe entre le raisonnement du modèle et un système de fichiers réel, une clé d'API ou une base de données de production. Un modèle parfaitement aligné ne sert à rien s'il tourne dans un harness qui fait confiance à un motif shell générique ou qui réutilise un espace de travail contenant du contenu non fiable sur plusieurs passages.

Trois manières dont un harness peut céder

Elad Meged, ingénieur fondateur et chercheur en sécurité chez Novee Security, a montré lors de la conférence Black Hat USA comment il s'est introduit dans les dépôts d'automatisation officiels d'Anthropic, Google et OpenAI en ne s'appuyant que sur des issues GitHub. Les failles précises différaient selon l'éditeur — exécution de code, identifiants exposés, instructions injectées qu'un composant plus puissant en aval acceptait sans les revalider. L'erreur architecturale sous-jacente, elle, était remarquablement identique chez les trois : un composant prenait une décision de sécurité qu'un composant plus puissant, plus loin dans la chaîne, réutilisait sans la vérifier à nouveau. « Ce n'est pas un échec du modèle, c'est un échec de frontière de confiance », résume Meged.

La deuxième source de défaillance tient à la conception même du harness, sans qu'aucune erreur de code ne soit nécessaire. Les chercheurs de Lasso Security ont simplement remplacé le harness d'un même modèle ouvert, en laissant modèle, prompt et outils identiques. Le taux de réussite des attaques est passé de 1 à 24 %, et le résultat s'est complètement inversé sur 43 combinaisons modèle-tâche sur 100 testées. « Changer de harness, c'est obtenir en pratique un système entièrement différent », affirme Sromin, qui recommande d'évaluer le harness et le modèle ensemble plutôt que d'adopter une configuration par défaut sans la tester.

La troisième faille concerne la chaîne d'approvisionnement du harness. L'équipe de Michael Bargury chez Zenity a examiné des « skills » — des fichiers qui apprennent une nouvelle tâche à un agent — et y a trouvé des logiciels malveillants voleurs d'identifiants, capables de passer tous les scanners du marché, y compris ceux d'Anthropic et de Cisco. Un skill malveillant s'écrivait dans le fichier de mémoire qu'un agent recharge à chaque démarrage : supprimer le skill ne suffisait pas, car l'instruction de réinstallation restait active et le logiciel malveillant revenait au redémarrage suivant. Un autre skill se faisait passer pour un outil officiel d'Anthropic, supprimait l'outil légitime une fois exécuté et le remplaçait par sa propre version, sans changement visible pour l'utilisateur. La campagne la plus marquante a cloné des outils open source populaires en y ajoutant discrètement du vol d'identifiants : ces versions piégées ont cumulé environ 1,7 million de téléchargements avant d'être repérées et stoppées.

• Inventaire : recenser chaque harness en production, même désigné en interne comme « copilote », « assistant de workflow » ou « plugin »
• Cartographie des accès : identifier les outils et données que chaque harness peut atteindre, puis réduire ces droits au strict nécessaire
• Test indépendant : évaluer le harness et le modèle ensemble plutôt que d'adopter une configuration par défaut sans la vérifier

Les équipes pensent en termes d'applications, de services, de pipelines ou de bots. Les harness disparaissent dans des dépôts de code, des produits SaaS et des écrans de configuration d'éditeurs, au lieu d'apparaître comme des actifs à part entière dans l'inventaire de sécurité.

Ce que ça change pour les entreprises françaises

Pour une entreprise française qui déploie des agents IA en interne — extension d'outils Copilot, automatisation maison ou framework d'agents —, le harness ne figure aujourd'hui presque jamais comme une ligne à part dans l'inventaire de sécurité. Santos recommande de ne pas attendre une visibilité totale : 60 à 70 % du parc peut être couvert relativement vite en commençant par les systèmes en production, avant de traiter prototypes et IA fantôme dans un second temps. Cette approche recoupe l'obligation déjà en vigueur avec le règlement européen sur l'IA, qui impose de documenter les cas d'usage à haut risque : l'outil qui exécute les actions de l'agent doit figurer dans le même inventaire que le modèle. Concrètement, les équipes sécurité doivent traiter le harness comme un composant à part dans les processus d'achat et d'audit — avec sa propre évaluation de risque, son propre cycle de correctifs et un principe de moindre privilège pour les accès, quel que soit le modèle qui tourne derrière.