Limites d’un agent d’IA

Pourquoi un agent a besoin de limites

Un assistant conversationnel qui répond à des questions peut se tromper, ce qui est un problème. Un agent qui agit peut se tromper et passer à l’acte : rembourser la mauvaise commande, écrire au mauvais client, supprimer le mauvais fichier. Les modèles de langage sont aussi faciles à induire en erreur, que ce soit par la personne qui les utilise ou par le texte qu’ils lisent en chemin.

Le Top 10 de l’OWASP pour les applications de grands modèles de langage nomme les risques qui comptent le plus ici, dont l’injection de requêtes, l’autonomie excessive et la consommation sans limite ^[1]. Chacun a une réponse pratique, et aucune ne dépend d’un comportement parfait du modèle. Ce sont les mêmes contrôles que vous mettriez autour d’un nouvel employé ayant accès à de vrais systèmes : un accès limité, une supervision des décisions importantes, une limite de dépenses et un registre de ce qu’il a fait.

Le moins d’outils et d’accès possible

Les outils d’un agent sont les fonctions qu’il peut appeler : chercher dans la base de connaissances, consulter une commande, créer un billet, émettre un remboursement. L’OWASP décrit l’autonomie excessive comme un système doté de plus de fonctions, de permissions ou d’autonomie que sa tâche n’en demande, et recommande de limiter au strict nécessaire les outils qu’un agent peut appeler et ce que chacun peut faire ^[2].

• Des outils étroits valent mieux que des outils généraux. Un outil qui consulte une commande par son numéro est plus sûr qu’un outil qui exécute n’importe quelle requête sur la base de données.
• Lire avant d’écrire. Commencez avec des outils en lecture seule; ajoutez la capacité de modifier, une action à la fois, à mesure que l’agent gagne la confiance.
• Agir comme l’utilisateur, pas comme un administrateur. L’OWASP recommande d’exécuter les outils dans le contexte de l’utilisateur plutôt que par un compte privilégié, pour que l’agent ne puisse jamais faire plus que la personne qu’il aide ^[2].
• Vérifier les permissions dans le système appelé, pas seulement dans la requête. Le système en aval doit refuser une action interdite à l’utilisateur, quoi que le modèle ait demandé ^[2].

Traitez tout ce qu’il lit comme non fiable

L’injection de requêtes, c’est du texte qui tente de changer ce que fait le modèle. Elle peut venir directement de l’utilisateur, ou indirectement d’un contenu que le modèle lit, comme une page web, un courriel ou un fichier ^[3]. Un agent qui lit le courriel d’un client et dispose aussi d’un outil de remboursement peut se faire dire, par ce courriel, d’émettre un remboursement.

• Séparez les instructions des données, et marquez clairement le contenu externe comme non fiable, comme le recommande l’OWASP ^[3].
• Définissez le format de sortie et vérifiez-le avec du code ordinaire, pas avec un autre modèle, avant d’agir ^[3].
• Ne laissez jamais le contenu que lit l’agent augmenter ses permissions. Un document ne peut pas accorder d’accès; seuls vos systèmes le peuvent.
• Testez avec des données hostiles avant le lancement et régulièrement ensuite, comme pour tout autre contrôle de sécurité ^[3].

Placez des personnes aux bons points de contrôle

Toutes les actions n’ont pas besoin d’une personne, et demander une approbation pour tout apprend aux gens à cliquer oui sans lire. Classez les actions selon ce que coûterait une erreur, et n’exigez d’approbation que là où cela compte. L’OWASP recommande l’approbation humaine des actions à fort impact ^[2].

Les budgets : étapes, temps et dépenses

Un agent travaille en boucle : réfléchir, appeler un outil, lire le résultat, réfléchir encore. Sans limites, un agent confus peut tourner longtemps, et chaque tour consomme des jetons ou du temps GPU. L’OWASP classe la consommation sans limite comme un risque à part entière, y compris des attaquants qui font grimper exprès une facture à l’usage, et recommande des limites de débit, des quotas, des délais d’expiration et une surveillance ^[4].

• Un nombre maximal d’étapes par tâche. Une fois atteint, l’agent s’arrête et passe la main à une personne avec ce qu’il a déjà.
• Un délai par tâche et par appel d’outil, pour qu’un système lent ne bloque pas tout.
• Une limite de dépenses par tâche, par utilisateur et par jour, appliquée par votre code avant chaque appel au modèle.
• Des limites sur la taille des entrées, pour que personne ne puisse coller une bibliothèque dans la zone de clavardage.
• Des alertes quand l’usage s’écarte de la normale, envoyées à quelqu’un qui peut agir.

Les budgets rendent aussi le coût d’exploitation prévisible. Les exemples ci-dessous montrent le coût mensuel du modèle à un niveau d’usage donné; ce sont les limites qui le maintiennent là.

L’évaluation avant et après le lancement

Impossible de savoir si un agent est sûr et utile en l’essayant quelques fois. Il faut un ensemble de tâches réalistes aux résultats connus, exécuté automatiquement avant le lancement et avant chaque changement. Le cadre de gestion des risques liés à l’IA du NIST, un cadre volontaire pour intégrer la fiabilité à la conception, au développement, à l’utilisation et à l’évaluation des systèmes d’IA, offre une structure utile pour décider quoi mesurer et qui en répond ^[5].

1. 01

   Rassemblez de vraies tâches

   Des questions et des demandes des personnes qui utiliseront l’agent, avec le bon résultat pour chacune, y compris les tâches qu’il doit refuser ou transférer.

2. 02

   Ajoutez des cas hostiles

   Des instructions injectées dans des documents, des demandes interdites à l’utilisateur et des tentatives de le faire tourner en boucle.

3. 03

   Notez plus que la réponse

   A-t-il utilisé les bons outils, dans le bon ordre, dans le budget, et s’est-il arrêté au bon moment?

4. 04

   Fixez une barre et tenez-la

   Convenez du score à atteindre pour la mise en ligne. Un changement qui passe en dessous n’est pas déployé.

5. 05

   Continuez d’évaluer en production

   Échantillonnez de vraies conversations, révisez-les et ajoutez les échecs au jeu de test.

Journaux, surveillance et interrupteur

• Journalisez chaque étape : ce qu’on a demandé à l’agent, quels outils il a appelés avec quelles entrées, ce qui est revenu et ce qu’il a fait. Masquez les renseignements personnels dans les journaux comme partout ailleurs.
• Rendez chaque action traçable jusqu’à un utilisateur et une tâche, pour qu’une modification étrange d’un enregistrement puisse s’expliquer.
• Surveillez les taux d’erreur, les transferts, les refus et les dépenses, et révisez chaque semaine un échantillon de conversations.
• Prévoyez un interrupteur qui ne demande pas de déploiement : un seul réglage qui désactive l’agent, ou un seul outil, sur-le-champ.
• Écrivez qui répond du comportement de l’agent, et qui décide de l’arrêter.

Commencer petit, élargir sur des preuves

Les agents les plus sûrs commencent petit. Lancez-les avec une seule tâche bien définie, des outils en lecture seule et une poignée d’utilisateurs de confiance. Suivez les journaux et les scores d’évaluation pendant quelques semaines. Élargissez ensuite une chose à la fois : plus d’utilisateurs, puis un outil qui écrit, puis moins d’approbations pour les actions qui ont fait leurs preuves. Chaque étape est une décision prise sur des preuves, et chacune peut être annulée.

C’est plus lent que de tout activer d’un coup, et c’est ainsi que les agents finissent par inspirer confiance plutôt que d’être arrêtés après le premier incident. Cela donne aussi aux personnes qui travaillent avec l’agent le temps d’apprendre ce qu’il fait bien, et de vous dire où il échoue.

Deux agents, chiffrés selon notre grille

Les exemples ci-dessous montrent la fourchette selon notre grille tarifaire d’aujourd’hui, avec le développement et le coût mensuel d’exploitation. Le développement comprend les outils, les permissions, les étapes d’approbation, les budgets et le jeu d’évaluation : ils font partie de l’agent, ce ne sont pas des options.

La liste de contrôle avant la mise en ligne

1. 01

   Outils listés et resserrés

   Chaque outil nommé, avec ce qu’il peut lire et modifier, et rien de plus.

2. 02

   Permissions appliquées en aval

   Les systèmes que l’agent appelle vérifient eux-mêmes les droits de l’utilisateur.

3. 03

   Approbations pour les actions à fort impact

   L’argent, les suppressions, les permissions et les messages sortants exigent une personne.

4. 04

   Budgets fixés et appliqués dans le code

   Étapes, temps, dépenses par tâche et par jour, et taille des entrées.

5. 05

   Évaluation réussie

   Des tâches réelles et hostiles, notées, à la barre convenue ou au-dessus.

6. 06

   Journaux, alertes et interrupteur testés

   Quelqu’un l’a arrêté puis redémarré, exprès, avant le lancement.