Une expérience publiée dans The New Stack révèle qu’accorder à un agent d’IA des autorisations plus larges que nécessaire peut transformer une simple erreur logique en une opération financière répétée que le modèle n’arrête pas de lui-même. Lors d’un test portant sur des factures clients, un agent d’assistance a confirmé que le paiement avait échoué et que les fonds du client n’avaient pas été débités, mais il a effectué un remboursement alors que les données ne le justifiaient pas, répétant l’erreur cinq fois.
Claude Sonnet 5 a réussi à détecter les six cas conçus pour tester cette faille, tandis que Claude Haiku 4.5 a échoué dans tous les cas. Une seule ligne dans les instructions système, demandant de vérifier l’état de la transaction avant d’exécuter une action financière, a également permis de résoudre le problème. Mais l’auteur estime que ces deux solutions sont fragiles : l’organisation peut remplacer le modèle par une version moins coûteuse ou modifier les instructions au cours d’une expérience, faisant disparaître la protection sans avertissement clair.
L’autorisation refusée comme barrière de sécurité
La protection qui a résisté à ces changements consistait à empêcher l’agent de disposer de l’autorisation billing:refund dès le départ. L’exécution échouait alors au niveau des autorisations, indépendamment du modèle ou de la formulation des instructions. C’est la conclusion du principe du moindre privilège dans l’architecture des agents d’IA : l’objectif n’est pas seulement d’empêcher un attaquant d’agir ou de protéger les secrets, mais aussi d’empêcher un agent bien intentionné d’exécuter rapidement des instructions erronées de manière automatisée et sans supervision humaine.
La nature d’un agent diffère de celle d’un compte de service traditionnel qui remplit une fonction fixe. L’agent d’assistance peut ainsi lire un ticket à 09:00, effectuer un remboursement à 09:04 et modifier le nombre de sièges à 09:11. Par conséquent, l’ensemble des autorisations nécessaires à toutes ses activités potentielles au cours d’une semaine ne reflète pas nécessairement ce dont il a besoin pour une seule tâche.
Qu’a mesuré l’expérience ?
L’auteur a construit un environnement de test comprenant 30 autorisations réparties entre neuf domaines dans une interface de programmation d’application d’entreprise fictive, couvrant les tickets, les utilisateurs, la facturation, les abonnements, les fichiers, les messages, l’audit, l’administration et la recherche. Treize autorisations permettaient de modifier ou d’extraire l’état. L’expérience comprenait 20 tâches, chacune ayant un résultat vérifiable automatiquement, comme fermer un ticket ou rembourser une facture.
Quatre modèles d’autorisation ont été comparés avec Claude Haiku 4.5 et Claude Sonnet 5, pour un total de 160 exécutions :
- Autorisation étendue : une attribution à long terme comprenant les 30 autorisations.
- Rôle fixe : un rôle d’assistance comprenant 17 autorisations tirées d’une description de poste type.
- Restriction selon la tâche : accorder les autorisations requises pour chaque exécution et les retirer à la fin de celle-ci.
- Activation à la demande : commencer sans autorisation et demander chaque autorisation au besoin en indiquant sa justification.
La restriction selon la tâche réduit l’étendue des dommages
Le modèle de restriction selon la tâche a permis l’accomplissement intégral des tâches en utilisant environ une autorisation sur quinze par rapport à l’attribution étendue. Les refus occasionnels et les nouvelles tentatives n’ont pas entraîné d’augmentation notable du nombre d’appels à l’interface.
Le modèle du rôle fixe a été le plus faible sur les deux axes. Il accordait 17 autorisations, dont quatre n’étaient utilisées par aucune tâche, tout en ne disposant pas de neuf autorisations essentielles. Étendre le rôle jusqu’à permettre la réussite de toutes les tâches aurait nécessité 26 autorisations, contre une médiane de seulement deux autorisations par tâche. Le rôle fixe devient ainsi à la fois trop large et insuffisant, car il fonde la décision sur l’intitulé du poste plutôt que sur le travail réellement effectué.
Le modèle d’activation à la demande a atteint un niveau d’étendue des dommages tout aussi faible, mais il a nécessité environ 80 % d’appels supplémentaires à l’interface. En outre, le refus d’autorisation dans le modèle fondé sur la tâche concernait généralement des parcours exploratoires facultatifs, tandis que le refus dans le modèle du rôle fixe était définitif, car il bloquait une autorisation essentielle.
Pourquoi est-ce important pour les organisations ?
Les résultats montrent que les capacités du modèle et les instructions système sont deux couches de défense susceptibles de changer, tandis qu’une autorisation non accordée reste efficace même lorsque le modèle est remplacé ou que le prompt est modifié. Les équipes devraient donc concevoir les autorisations de l’agent autour de la tâche actuelle et rendre les autorisations sensibles temporaires et vérifiables, au lieu de les regrouper dans un rôle permanent et étendu.
L’expérience reste limitée par un environnement artificiel, 20 tâches et deux modèles Claude ; elle ne prouve donc pas que les résultats seront identiques dans toutes les organisations ou avec tous les modèles. Elle fournit néanmoins un indicateur pratique clair : tester l’agent ne suffit pas si l’architecture lui permet d’exécuter des actions dont il n’a pas besoin, car un changement de modèle ou d’instructions peut modifier le comportement tandis que la capacité de causer des dommages demeure.