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 contenu et prévisible est devenu quelque chose qui raisonne, planifie et prend des actions à travers des outils et des API qu’il connaissait à peine il y a un an.

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 originale 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 de codes d’accès, de clés API et de la capacité de supprimer, de créer et de annoter des données, ainsi que de prendre 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 sont passés de générateurs de texte à permettre l’exécution de configurations multi-agents fluides. Ils lisent des e-mails, déclenchent des flux de travail, interrogent des bases de données et, dans certains cas, gèrent d’autres agents en dessous d’eux. Ce niveau d’accès nécessitait autrefois un processus d’approvisionnement long et un humain dans la boucle. Maintenant, c’est un fichier de configuration et quelques appels API.

Plus d’accès signifie plus d’exposition

Les attaques de logiciels traditionnelles 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 propre à 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 et d’exploiter, et personne ne les cartographie en temps réel. Avant que vous ne le sachiez, quelqu’un peut pirater les informations d’identification et prendre le contrôle de votre organisme IA entier avec un seul mouvement.

L’injection de prompt est la nouvelle injection SQL

S’il y a un vecteur d’attaque que les chercheurs en sécurité continuent de répéter, 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 le rend particulièrement aigu 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. Ils ne l’éliminent pas. Et la plupart des organisations n’ont même pas mis en œuvre les bases encore.

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, tout agent en dessous de lui est effectivement compromis également, et le rayon d’explosion devient grand très rapidement.

Il y a également le problème de la sur-autorisation. 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 de planification n’a pas besoin d’accès aux dossiers financiers. Certes, il est rassurant d’avoir tout entrelacé, mais c’est tout simplement trop risqué pour voir des rendements non diminués. Mais les lignes deviennent floues dans la pratique, et les principes de permission minimale qui fonctionnent bien en théorie sont abandonnés discrètement dans la précipitation pour expédier.

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 une portée définie et étroite, 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 les rétrofitter après coup est douloureux. Les construire dès le départ vaut la friction.

Les tests adverses sont également sous-utilisés. Les équipes rouges des agents, en essayant spécifiquement d’injecter des instructions malveillantes et en regardant ce qui se passe, mettent en évidence des vulnérabilités que la revue de code statique ne détectera jamais. C’est inconfortable de penser, mais les personnes qui essayeront finalement d’exploiter ces systèmes le font déjà. Arriver les premiers est le seul mouvement sensé.

Pensées finales

Les agents IA vont devenir une plus grande partie de la façon dont les organisations opèrent, 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 l’horloge pour obtenir cela a déjà commencé.