Les agents IA deviennent plus intelligents et leur surface d’attaque s’élargit

Le moment où les agents IA ont commencé à réserver des réunions, à exécuter des codes et à parcourir le web en votre nom, la conversation sur la cybersécurité a changé. Pas lentement, mais plutôt du jour au lendemain.

Ce qui était auparavant 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 les 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 toujours 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 dans des systèmes qui ont des conséquences réelles.

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 auparavant 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 traditionnels 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, en cours de 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 des exploits, et personne ne les cartographie en temps réel. Avant que vous ne le sachiez, quelqu’un peut pirater les codes d’accès et prendre le contrôle de l’ensemble de votre organisme IA 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 que reçoit un agent via ses entrées. Une instruction malveillante intégrée à une page Web, un document ou même un e-mail peut rediriger ce que fait l’agent ensuite.

Ce qui le rend particulièrement aigu, c’est que les agents font souvent exactement ce qu’on leur dit. Ils traitent le contenu du Web, des messages des utilisateurs, d’outils tiers. Tout ce contenu est une surface d’injection potentielle. Un agent qui lit un document compromis et qui effectue 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. La mise en sandbox 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 à haute priorité 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 passe des instructions, et les sous-agents les suivent. Si cet orchestrateur est compromis, chaque agent en dessous de lui est effectivement compromis lui aussi, et le rayon d’explosion devient grand très rapidement.

Il y a également le problème de la sur-autorisation. Les agents reçoivent souvent plus d’accès qu’ils n’en ont besoin parce que c’est plus facile de donner des autorisations larges 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. Oui, cela peut sembler rassurant d’avoir tout entrelacé, mais c’est 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 lancer.

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 bien cela tendent à 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étrofitting 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 rouge, en essayant spécifiquement d’injecter des instructions malveillantes et en regardant ce qui se passe, mettent au jour des vulnérabilités que la révision de code statique ne détectera jamais. C’est inconfortable à penser, mais les personnes qui essayeront éventuellement d’exploiter ces systèmes le font déjà. Arriver en premier est le seul mouvement sensé.

Pensées finales

Les agents IA vont devenir une partie plus importante 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 autonomes IA 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é.