Le harnais IA est la nouvelle surface d’attaque

Demandez à un chercheur en sécurité ce qui rend un agent d’IA dangereux, et l’instinct est de parler du modèle : ce qu’il refusera et ne refusera pas, avec quelle facilité il peut être jailbreaké, si ses poids sont fiables.

Cet instinct est de plus en plus dépassé. Un nombre croissant de recherches sur la sécurité – démonstrations d’exploitation, équipes rouges indépendantes et évaluations par des chercheurs en sécurité – mettent plutôt en évidence le code situé entre le modèle et le monde.

Ce code, de plus en plus appelé harnais, enveloppe le modèle, lui donne des outils et transforme sa sortie jeton par jeton en une commande shell, une écriture de fichier, un appel API. Il est également sous-inventorisé, sous-testé et souvent sous-approprié au sein des entreprises.

Elad Meged, ingénieur fondateur et chercheur en sécurité chez Novee Security, a pénétré par effraction dans les référentiels d’automatisation officiels d’Anthropic, Google et OpenAI en utilisant uniquement des problèmes GitHub.

Les chercheurs de Lasso Security ont découvert que le remplacement d’un élément de plomberie d’agent soi-disant neutre par un autre faisait passer le taux de réussite d’attaque d’un modèle de 1 % à 24 %, en utilisant le modèle, l’invite et les outils identiques.

Et Michael Bargury, co-fondateur et directeur technique de la société de sécurité IA Zenity, a découvert que les attaquants cachaient des logiciels malveillants voleurs d’informations d’identification dans des « compétences » d’IA qui avaient déjà dépassé tous les scanners du marché, y compris ceux officiels d’Anthropic et de Cisco.

Les échecs sont différents, mais ils partagent une caractéristique importante : aucun n’exige qu’un modèle devienne malveillant ou même se comporte de manière inattendue. Ils exploitent le logiciel qui l’entoure – la couche qui détermine ce que le modèle peut voir, ce qu’il peut toucher et ce qui se passe lorsqu’il agit.

C’est pourquoi un nombre croissant de chercheurs en sécurité de l’IA soutiennent que le harnais doit être traité comme une surface d’attaque à part entière, plutôt que comme un échafaudage invisible qui accompagne le modèle.

Qu’est-ce qu’un « harnais » ?

Demandez aux praticiens de définir un harnais et les métaphores convergent dans différentes directions.

Omar Santos, ingénieur distingué chez Cisco, propose une définition plus formelle.

Les descriptions pointent toutes vers le même problème de sécurité, à savoir que le harnais est l’endroit où l’autorité d’un agent s’exerce. Il se situe entre le raisonnement d’un modèle et un véritable système de fichiers, une clé API ou une base de données de production.

« Les équipes de sécurité doivent traiter le harnais comme une surface d’attaque, car c’est là que l’agent obtient son autorité, son contexte et ses moyens d’agir », explique Santos.

Et le code d’exploitation présente des vulnérabilités, comme n’importe quel autre logiciel.

Un modèle parfaitement aligné peut être placé à l’intérieur d’un harnais qui fait confiance à un modèle de shell générique ou réutilise un espace de travail sur deux passes de contenu non fiable. À ce stade, l’alignement du modèle est largement hors de propos. La vulnérabilité n’est pas dans le modèle.

Trois modes de défaillance, une surface d’attaque

Certaines des recherches les plus détaillées de cette année ont révélé trois manières distinctes d’échouer les harnais : les limites de confiance architecturales, les choix de mise en œuvre et la compromission de la chaîne d’approvisionnement.

Meged a démontré la première (limites de confiance architecturales) chez Black Hat après avoir pénétré dans les automatisations officielles d’Anthropic, de Google et d’OpenAI en utilisant uniquement des problèmes GitHub.

Le schéma récurrent, dit-il, était le suivant : « Décider à un endroit, consommer dans un autre avec plus de pouvoir. »

La vulnérabilité de chaque fournisseur était différente. On lui a donné l’exécution de code. L’une des informations d’identification divulguées que le harnais pensait avoir supprimées. Un autre lui a permis de planter des instructions auxquelles une étape ultérieure, plus privilégiée, faisait confiance sans les revérifier.

Mais l’erreur architecturale sous-jacente était remarquablement cohérente. Un composant a pris une décision de sécurité et un composant plus puissant en aval a fait confiance à cette décision sans la valider à nouveau.

Ce n’est pas un échec de modèle. C’est un échec des limites de confiance.

Les recherches de Lasso exposent un deuxième problème. Même sans erreur de codage exploitable, la conception même du harnais peut altérer radicalement la sécurité d’un agent.

« Lorsque vous choisissez votre LLM, les outils et tout, et que vous choisissez le harnais, vous obtenez un agent », explique Sromin. « Et lorsque vous choisissez un autre harnais, vous obtenez un agent complètement différent. »

Il s’agit d’une distinction plus grande que ce que de nombreuses organisations pourraient imaginer. Certains professionnels de la sécurité considèrent encore le harnais comme une simple boucle de passage – une plomberie interchangeable entre le modèle et ses outils.

Les chiffres du Lasso suggèrent le contraire. L’échange de harnais sous un modèle identique à poids ouvert a fait passer son taux de réussite d’attaque de 1 % à 24 % et a entièrement inversé le résultat sur 43 des 100 paires modèle-tâche.

« Ce n’est pas simplement un choix arbitraire », déclare Sromin. « C’est un choix prudent. Cela peut vraiment affecter et faire bouger les choses dans tout ce que vous faites. »

Sa recommandation est de comparer le harnais avec le modèle. En sélectionner un dans le commerce sans le tester, c’est faire un choix de sécurité conséquent sans savoir que vous en avez fait un.

La chaîne d’approvisionnement du harnais se développe rapidement, comme le montrent les recherches de Bargury chez Zenity, et elle est déjà exploitée.

Son équipe a étudié les « compétences » (des fichiers qui apprennent à un agent comment effectuer de nouvelles tâches) et a découvert qu’un ancien problème de sécurité apparaissait sous une nouvelle forme.

« Il s’agit simplement d’un problème de chaîne d’approvisionnement, qui refait surface avec les compétences », a déclaré Bargury chez Black Hat.

Mais les compétences des agents créent des variations inhabituelles sur ce problème, car elles peuvent modifier l’environnement auquel un agent fait confiance de manière répétée.

Chaque fois qu’un agent démarre, par exemple, il peut recharger un fichier mémoire contenant des instructions sur ce qu’il est censé faire. Zenity a découvert qu’une compétence malveillante pouvait s’inscrire dans cette mémoire. Supprimez la compétence et les instructions pour la réinstaller restent, permettant au logiciel malveillant de revenir lors de la prochaine exécution de l’agent.

Une autre compétence malveillante examinée par Zenity se fait passer pour un outil anthropique légitime. Une fois exécuté, il supprimait le véritable outil et le remplaçait par la version de l’attaquant, laissant l’agent exécuter du code malveillant sans changement évident visible pour l’utilisateur.

L’exemple le plus frappant est une campagne de versions clonées d’outils open source populaires, secrètement modifiées pour voler les identifiants de connexion. Les compétences malveillantes ont surpassé les outils légitimes qu’elles ont copiés sur skills.sh et ont accumulé environ 1,7 million de téléchargements avant que la campagne ne soit interrompue.

La leçon à retenir dans les trois domaines de recherche est la même : sécuriser le modèle n’est pas la même chose que sécuriser l’agent.

Ce que les RSSI devraient savoir

Pour les RSSI, la recherche met en évidence trois problèmes immédiats : trouver les harnais déjà en place au sein de l’organisation, contrôler ce qu’ils sont autorisés à toucher et tester de manière indépendante si leurs contrôles de sécurité fonctionnent réellement.

La première peut être plus difficile qu’il n’y paraît, car la plupart des organisations ne maintiennent pas de catégorie appelée « harnais d’IA ».

« Les équipes pensent en termes d’applications, de services, de pipelines ou de robots », explique Santos. Les harnais disparaissent dans les référentiels de code, les produits SaaS et les écrans de configuration des fournisseurs au lieu d’apparaître comme des actifs discrets dans les inventaires de sécurité.

Même la terminologie est incohérente.

« Une équipe peut appeler quelque chose un agent, une autre un copilote, une autre un assistant de flux de travail, une autre encore une automatisation basée sur un plugin », explique Santos, « même si tous ces éléments sont effectivement des exploits ».

Sa recommandation est de constituer un inventaire en direct de chaque agent de production, d’identifier son harnais et de cartographier tous les outils et ressources auxquels il peut accéder. Réduisez ensuite ces autorisations au minimum requis.

Les organisations ne doivent pas attendre une visibilité parfaite. Santos estime qu’une visibilité de 60 à 70 % peut être obtenue relativement rapidement en commençant par les systèmes de production, en laissant les prototypes et l’IA fantôme pour une deuxième phase.

Le deuxième problème est de contrôler tout ce à quoi le harnais fait confiance.

Les agents n’agissent pas de manière isolée. Ils ingèrent des instructions et du contenu provenant d’outils, de plugins, de compétences, de serveurs MCP, de sites Web et d’autres systèmes, souvent tout en détenant des informations d’identification et des autorisations qui leur permettent d’agir au nom des utilisateurs.

Les attaquants n’ont donc pas besoin de compromettre le modèle. Ils doivent faire un compromis sur quelque chose auquel le harnais est prêt à faire confiance.

« Vous partagez votre ordinateur portable avec vos agents, et votre ordinateur portable contient tout : votre identité, vos fichiers, vos secrets », explique Bargury.

Pour les organisations ne disposant pas d’un budget dédié à la sécurité de l’IA, il recommande, au minimum, d’exécuter des agents dans des outils de confinement open source. « Ce n’est pas une solution », prévient-il, « mais c’est utile ».

La taille de la chaîne d’approvisionnement potentielle rend le problème qualitativement différent de la gestion conventionnelle des dépendances logicielles.

« La chaîne d’approvisionnement des logiciels comprend, quoi, 10 ou 15 registres de packages ? » dit Bargury. « La chaîne d’approvisionnement des agents comprend n’importe quel contenu, n’importe quelle image, n’importe quel texte, n’importe quel site Web, n’importe quel objet CRM, n’importe quelle compétence, n’importe quel serveur MCP, n’importe quel contenu sur Internet. »

Le troisième problème est de supposer que les revendications de sécurité d’un fournisseur sont transférées à l’environnement dans lequel un agent sera réellement exécuté.

Un fournisseur affirmant qu’il bloque 99 % des injections rapides, dit Bargury, cite peut-être « une référence qui n’est pas attachée à la réalité du terrain ».

Les découvertes de Lasso démontrent pourquoi c’est important. Maintenez le modèle, l’invite et les outils constants et modifiez uniquement le harnais, et le résultat en matière de sécurité peut changer radicalement.

Cela signifie que les organisations évaluant les agents posent peut-être la mauvaise question. Il ne s’agit pas simplement de savoir quel modèle est le plus sûr. Il s’agit de savoir quelle combinaison de modèle, de harnais, d’outils, d’autorisations et d’entrées externes reste sûre dans les conditions dans lesquelles l’organisation la déploiera réellement.

Meged a tiré la leçon de la rupture des automatisations officielles de trois fournisseurs : « Lisez les valeurs par défaut, pas la documentation. »

« Le produit disait qu’il était sûr », a-t-il déclaré, « et c’est là que nous avons commencé. »