Limiter les droits d’accès de l’IA à la tâche confiée

Imaginons que vous utilisiez une IA pour ajouter une fonction de téléchargement à un logiciel de suivi des interventions. Une responsable des opérations veut ouvrir dans Excel la liste des interventions terminées dans le mois. L’IA doit modifier le code qui produit le fichier CSV, un format compatible avec les tableurs, puis vérifier le résultat.

Pour cette tâche, l’équipe peut lui fournir une copie de l’application et des interventions fictives. L’IA n’a pas besoin de consulter les dossiers réels des entreprises clientes. Elle n’a pas non plus besoin de déployer elle-même la modification dans le logiciel qu’elles utilisent.

Cette séparation limite les conséquences d’une commande erronée ou d’une instruction trompeuse rencontrée pendant le travail. Les outils doivent la faire respecter, et l’équipe doit vérifier qu’elle fonctionne.

Relier chaque droit d’accès à une action nécessaire

Demandez à l’équipe quelles opérations la tâche exige. Lire les fichiers concernés, les modifier et exécuter les tests sont des besoins précis. Un accès administrateur à l’ensemble des services dépasse largement ces besoins.

L’organisation suivante convient à cet exemple. Les outils de développement et de déploiement déjà en place peuvent remplir ces rôles.

Étape	Accès nécessaire dans cet exemple	Limite à faire respecter
Développer	Code concerné, copie de travail et données fictives	Aucun accès aux dossiers clients réels ni à l’application en production
Vérifier	Version proposée et environnement d’essai	Le code exécuté pendant les tests ne peut pas obtenir les identifiants d’accès à la production
Déployer	Version approuvée et autorisation de la mettre en production	Les droits de déploiement ne permettent pas d’exécuter du code quelconque non vérifié
Modifier les règles	Proposition soumise à la personne responsable	L’IA ne peut pas élargir ses propres droits ni supprimer une vérification obligatoire

Portez une attention particulière au service qui exécute les tests : il lance le code proposé par l’IA. S’il détient des identifiants donnant accès aux dossiers réels, ce code peut s’en servir même si l’IA ne voit jamais directement les identifiants.

Faire respecter les limites par les outils

La consigne « ne pas toucher aux données clients » indique l’intention. La configuration doit aussi empêcher cet accès. L’IA peut lire des pages, des billets de suivi ou des fichiers contenant des instructions incorrectes ou malveillantes. Leur contenu ne doit pas suffire à autoriser une opération.

Les recommandations de l’OWASP sur la sécurité des agents IA situent le contrôle des autorisations dans le composant qui exécute l’action, à l’extérieur du contexte du modèle. Le système peut ainsi vérifier qui demande l’action, quelle ressource est visée, quelle opération est prévue et si l’approbation requise a été obtenue.

Examinez ce que l’environnement peut lire et à quoi il peut se connecter : dossiers accessibles, programmes exécutés, connexions réseau et services externes. Bloquer une commande peut laisser une autre voie d’accès à la même ressource. Le retour d’expérience d’Anthropic sur le confinement des agents illustre pourquoi les restrictions sur les fichiers et sur le réseau doivent être étudiées ensemble.

Débloquer une tâche sans ouvrir tout le système

Supposons que l’IA ait besoin d’un rapport de test pour comprendre un échec. L’équipe peut lui donner accès à ce rapport pour une durée déterminée, après en avoir retiré les renseignements sensibles. L’exception répond alors à un besoin précis.

La personne qui approuve cet accès doit savoir ce qui sera lu ou modifié et pourquoi. Si la ressource visée ou l’action change, l’approbation précédente ne s’applique pas automatiquement à la nouvelle demande. Un accès temporaire doit avoir une date d’expiration et pouvoir être retiré.

Lorsqu’une opération est refusée, déterminez d’abord ce qui manque. L’outil peut avoir besoin d’une commande plus précise ou d’une connexion à un service de test. Lui fournir un compte administrateur par commodité annulerait la limite établie au départ.

Maintenir le contrôle jusqu’à la mise en production

La version approuvée doit rester identifiable jusqu’à son installation. Les fichiers déployés doivent correspondre à ceux dont les résultats ont été examinés. Une modification de dernière minute exige de relancer les vérifications concernées.

Les changements aux règles de déploiement doivent être examinés séparément des modifications de l’application. La documentation de sécurité de GitHub explique les risques de droits trop étendus et d’exécution de code non fiable dans un processus privilégié. L’équipe doit prévoir des protections équivalentes sur sa propre plateforme.

Tester les refus autant que les actions autorisées

Dans un environnement d’essai, vérifiez que l’IA peut accomplir la tâche confiée, tout en étant empêchée de lire un fichier interdit, de se connecter à une destination non autorisée ou de déployer une version non approuvée. Répétez les vérifications pertinentes lorsque les outils ou les droits changent.

L’article précédent examine la qualité des tests. Les limites d’accès décrites ici protègent leur exécution et la mise en production. L’article suivant explique comment réagir lorsqu’une modification défectueuse atteint malgré tout les utilisateurs.