Les agents IA deviennent plus intelligents, et leur surface d’attaque s’agrandit

À l’instant où les agents IA ont commencé à planifier des réunions, à exécuter du code et à parcourir le web en votre nom, la conversation sur la cybersécurité a changé. Pas progressivement, mais plutôt du jour au lendemain.

Ce qui était autrefois un système logiciel aux limites définies et prévisible est devenu quelque chose qui raisonne, planifie et agit au moyen d’outils et d’API dont il connaissait à peine l’existence un an auparavant.

C’est vraiment excitant, et c’est également vraiment terrifiant, car la surface d’attaque qui accompagne cette autonomie est énorme, et la plupart des organisations ne commencent qu’à comprendre ce que signifie laisser des agents pénétrer dans leur infrastructure.

Des chatbots aux opérateurs

La promesse initiale de l’IA était simple : poser une question, obtenir une réponse. C’est encore vrai pour la plupart des interactions avec les consommateurs, mais ce n’est pas ce qui se passe dans les déploiements d’entreprise aujourd’hui. Les agents d’aujourd’hui sont dotés d’identifiants, de clés API et de la capacité de supprimer, de créer et d’annoter des données, ainsi que d’effectuer des actions réelles à l’intérieur de systèmes ayant de réelles conséquences.

Le changement s’est produit rapidement. En moins de deux ans, les agents IA ont cessé de se limiter à la génération de texte pour nous permettre de faire fonctionner des systèmes multi-agents de manière fluide. Ils lisent des e-mails, déclenchent des flux de travail, interrogent des bases de données et, dans certains cas, gèrent des agents subordonnés. Ce niveau d’accès nécessitait autrefois un processus d’approvisionnement long et la participation humaine au processus. Maintenant, c’est un fichier de configuration et quelques appels API.

Plus d’accès signifie plus d’exposition

Les attaques traditionnelles contre les logiciels ont un profil quelque peu prévisible. Il y a un point d’entrée connu, une vulnérabilité connue, un correctif connu. Les agents IA brisent ce modèle car ils sont dynamiques par conception. Ils ne suivent pas un chemin de code statique. Ils raisonnent sur ce qu’ils doivent faire ensuite, ce qui signifie que leur comportement est plus difficile à prédire et beaucoup plus difficile à auditer après coup.

Cette imprévisibilité est utile pour accomplir le travail. C’est également un avantage pour quiconque tente d’exploiter le système. Lorsqu’un agent peut décider, au milieu d’une tâche, d’appeler une API externe ou de faire appel à un outil tiers, il n’y a pas de périmètre clairement délimité à défendre.

Les équipes de sécurité sont habituées à protéger des surfaces connues et à surveiller les coûts de Kubernetes. Les agents continuent de découvrir de nouvelles surfaces d’attaque et méthodes d’exploitation des failles, et personne ne les cartographie en temps réel. Avant même que vous ne vous en rendiez compte, quelqu’un peut pirater les informations d’identification et prendre le contrôle de tout votre « organisme » IA en un seul geste.

L’injection de prompt est la nouvelle injection SQL

S’il y a un vecteur d’attaque auquel les chercheurs en sécurité reviennent sans cesse, c’est l’injection de prompt. L’idée est simple : au lieu d’exploiter une vulnérabilité de code, un attaquant manipule les instructions qu’un agent reçoit via ses entrées. Une instruction malveillante intégrée dans une page Web, un document ou même un e-mail peut rediriger ce que l’agent fait ensuite.

Ce qui rend cette menace particulièrement grave, c’est que les agents font souvent exactement ce qu’on leur dit. Ils traitent du contenu provenant du web, de messages d’utilisateurs, d’outils tiers. Tout ce contenu est une surface d’injection potentielle. Un agent qui lit un document compromis et qui effectue ensuite des appels API en fonction de son contenu a été piraté, et il ne consignera probablement rien qui rende la chaîne de causalité évidente.

Les défenses ici sont réelles mais incomplètes. Le cloisonnement des actions des agents, la limitation des outils qu’un agent peut appeler dans certains contextes et la création de points de contrôle humains dans les flux de travail à haut risque réduisent le risque. Ces mesures ne l’éliminent pas. Et la plupart des organisations n’ont pas encore mis en œuvre les mesures les plus élémentaires.

Le problème de confiance à l’intérieur des systèmes multi-agents

Les systèmes multi-agents introduisent une couche de complexité qui est facile à sous-estimer. Lorsqu’un agent orchestre plusieurs autres, il y a une hiérarchie de confiance en jeu. L’orchestrateur transmet des instructions, et les sous-agents les suivent. Si cet orchestrateur est compromis, chaque agent subordonné est lui aussi compromis dans les faits, et l’étendue des dégâts augmente très rapidement.

Il y a également le problème de l’octroi excessif d’autorisations. Les agents sont souvent dotés d’un accès plus large qu’ils n’en ont besoin parce qu’il est plus facile de donner des autorisations générales dès le départ que de les affiner de manière itérative. Un agent de recherche n’a pas besoin d’accès en écriture à une base de données de production.

Un agent chargé de planifier des réunions n’a pas besoin d’accès aux dossiers financiers. Certes, il est rassurant que tout soit interconnecté, mais le risque est tout simplement trop élevé pour que les bénéfices se maintiennent sans diminuer. Mais les lignes deviennent floues dans la pratique, et les principes du moindre privilège qui fonctionnent bien en théorie sont abandonnés discrètement dans la précipitation pour livrer le produit.

Ce à quoi ressemble une sécurité raisonnable ici

Il n’y a pas de solution unique qui rende les déploiements d’agents sécurisés. C’est un problème en couches et il nécessite une réponse en couches. Les organisations qui font cela bien ont tendance à commencer par les contrôles d’accès : donner à chaque agent un périmètre d’action défini et restreint, et intégrer des étapes de révision dans toute action qui touche des systèmes sensibles ou des services externes.

L’observabilité est tout aussi importante que la prévention. Si un agent fait quelque chose d’inattendu, les équipes ont besoin d’une trace complète des instructions qu’il a reçues, des outils qu’il a appelés et de ce qu’il a retourné. La plupart des configurations de journalisation ne sont pas conçues avec ce niveau de granularité en tête, et y ajouter ce degré de détail après coup est laborieux. Il vaut la peine de surmonter les difficultés nécessaires pour l’intégrer dès le départ.

Les tests menés du point de vue d’un attaquant sont également sous-utilisés. Les tests red team sur les agents, notamment les tentatives d’injection d’instructions malveillantes et l’observation de leurs résultats, mettent en évidence des vulnérabilités que la revue de code statique ne détectera jamais. Il est désagréable d’y penser, mais les personnes qui tenteront un jour d’exploiter ces systèmes effectuent déjà ces tests. Les devancer est la seule démarche sensée.

Réflexions finales

Les agents IA vont devenir une composante plus importante du fonctionnement des organisations, et ce changement est déjà bien engagé. La conversation sur la sécurité doit rattraper son retard, et vite. Les risques sont réels, les vecteurs d’attaque sont nouveaux, et la fenêtre pour devancer ceux-ci se rétrécit.

Comprendre le paysage des menaces pour les systèmes IA autonomes n’est plus optionnel. C’est l’une des choses les plus importantes que les équipes de sécurité et d’ingénierie peuvent faire en ce moment, et le compte à rebours pour y parvenir correctement a déjà commencé.