Toutes les équipes de sécurité que je connais ont un plan pour le trafic hostile qui frappe leurs API. Limitation du débit, jetons limités, détection des anomalies : tout y passe. Ce plan part généralement du principe que l’appelant hostile se trouve à l’extérieur.
L’appelant qui m’inquiète est déjà à l’intérieur, authentifié, et fait exactement ce qu’on lui a demandé. C’est un agent IA et, du point de vue de votre API, un agent qui se comporte mal et un agent abusif se ressemblent exactement.
Je conçois des services back-end et des agents IA chez Amazon Advertising. Les agents que j’exploite appellent des outils et des API pour effectuer de vraies tâches : lire les données analytiques des annonceurs, assembler des réponses et agir en fonction de ce qu’ils trouvent. Leur exploitation m’a appris que l’abus des appels d’outils n’est pas seulement une technique d’attaquant. C’est aussi ce que fait un agent normal les mauvais jours, à la vitesse d’une machine, avec des identifiants valides.
Les scénarios d’abus sont intégrés
Commençons par les nouvelles tentatives. Un appel d’outil expire et l’agent ne peut pas savoir si l’action a été effectuée. Il appelle donc à nouveau. Une écriture qui était simplement lente devient une écriture effectuée deux fois. Les attaquants appellent cela une relecture. Votre agent appelle cela être serviable.
Vient ensuite la démultiplication. Une question d’utilisateur devient un plan, le plan devient des dizaines d’appels d’outils, et chaque appel récupère généreusement les données, car un filet plus large semble plus sûr au modèle. Multipliez cela par tous les utilisateurs qui posent une question simultanément et vous obtenez un profil de charge qu’aucune étude de capacité n’avait prévu, généré entièrement par des appelants autorisés.
Enfin, il y a l’élargissement des permissions, au sens littéral. Un agent doté d’un jeton étendu l’utilisera. Donnez à un outil l’autorisation de lire toutes les tables et l’agent lira des tables dont sa tâche n’avait jamais eu besoin, car rien dans ses instructions ne lui indiquait que ces tables étaient particulières. L’identifiant était le contrôle, et l’identifiant disait oui.
Défendez l’interface, pas l’intention
Vous ne pouvez pas sécuriser cela en inspectant les intentions de l’agent. Sécurisez-le comme n’importe quel client puissant : au niveau de l’interface.
Donnez à chaque flux de travail d’agent sa propre identité et un jeton limité aux outils et aux données dont ce flux a besoin. Un flux de synthèse n’a aucune raison de détenir un jeton d’écriture, et un flux qui écrit n’a aucune raison de lire l’intégralité de l’entrepôt de données.
Rendez les outils d’écriture idempotents. Transmettez une clé avec chaque requête, stockez le résultat et, lorsque la même clé arrive de nouveau, renvoyez le résultat stocké au lieu d’exécuter l’action une seconde fois. Correctement mis en œuvre, ce mécanisme empêche les requêtes répétées de déclencher plusieurs fois la même écriture.
Il réduit également le risque d’actions en double provoquées à la fois par des nouvelles tentatives légitimes et par certaines tentatives de relecture.
Surveillez l’activité des agents et imposez des limites
Consignez les appels d’outils comme vous consignez les actions d’utilisateurs privilégiés : quel agent, quel flux de travail, ce qu’il a lu, ce qu’il a modifié et à la demande de qui. Quand quelque chose tourne mal — et cela arrivera —, l’enquête devrait prendre des heures, pas relever de l’archéologie.
Fixez des budgets. Un plafond par tâche sur le nombre d’appels et le volume de données transforme un comportement incontrôlé en incident évité : la tâche s’arrête avec une erreur explicite. Les agents comprennent les budgets à peu près aussi bien que les ingénieurs débutants — autrement dit, le budget doit être imposé par le système, et non demandé dans une invite.
Ces limites doivent être appliquées par la passerelle API, la couche d’exécution des outils ou un autre service de confiance, plutôt que de compter sur l’agent pour s’arrêter de lui-même.
Rien de tout cela ne ralentit un agent qui se comporte correctement. Tout cela trace une ligne nette entre un agent qui fait son travail et un agent — ou quelqu’un qui le pilote — qui cause des dommages avec vos propres identifiants. C’est exactement là que la défense des API a toujours eu sa place.
Vous voulez obtenir de meilleurs résultats avec l’IA ? Les lecteurs d’eSecurity Planet peuvent profiter gratuitement pendant The Neuron Academy, une plateforme d’apprentissage pratique regorgeant d’astuces, de conseils et de techniques de rédaction d’invites pour l’IA. Commencez par notre cours gratuit de six minutes, Comment parler à l’IA, pour découvrir des méthodes simples afin de rédiger de meilleures invites et d’obtenir des réponses plus utiles, puis explorez d’autres leçons pour développer vos compétences en IA et votre assurance au travail.