Guide · Cybersécurité
Permissions des agents IA : guide du moindre privilège
Sécurisez les appels d’outils de vos agents IA avec le moindre privilège : registre des permissions, approbations, révocation et tests de refus.
Gérer les permissions d’un agent IA consiste à décider ce qu’il peut réellement faire, pas ce qu’il affirme vouloir faire dans une réponse. Un agent peut analyser une demande, mais les fichiers, API, outils et comptes auxquels il accède doivent être définis en dehors du modèle. Le principe du moindre privilège réduit l’impact d’une erreur, d’une instruction hostile ou d’un connecteur mal configuré.
Le but n’est pas de rendre l’agent inutile. Il est de lui accorder les droits minimaux pour une tâche précise, avec une étape d’approbation lorsque l’effet devient externe ou irréversible.
Ce que vous allez apprendre
Vous allez créer un registre d’outils et de permissions, associer les identités aux tâches, séparer lecture et écriture, ajouter des approbations, préparer la révocation et tester les refus. Ces contrôles s’appliquent à un agent local, un SaaS ou un workflow orchestré.
Prérequis
- La liste des tâches confiées à l’agent.
- Un inventaire des outils, fichiers, APIs et comptes disponibles.
- Des identités de test à portée limitée.
- Un environnement qui permet de simuler un refus sans effet réel.
- Un propriétaire humain pour les actions à impact.
Ne donnez pas une permission globale « administrateur » à un agent de test pour gagner du temps. Cette exception devient souvent un comportement de production non documenté.
1. Créer un registre des outils
Pour chaque outil, documentez son nom, sa version, son propriétaire, les données lues, les données écrites, les domaines réseau, les identités utilisées et les actions interdites. Distinguez les outils de recherche, lecture, écriture, exécution et publication. Un connecteur qui paraît anodin peut donner accès à une collection complète ou transmettre des résultats à un tiers.
Ajoutez un statut : autorisé, autorisé après approbation, désactivé ou en revue. Une source lue par l’agent ne doit jamais pouvoir modifier ce registre. Toute extension d’outil est une décision de configuration qui mérite une revue.
Vérification : choisissez un outil et demandez quel secret, dossier et action il peut atteindre. Si cette information n’est pas disponible, désactivez-le jusqu’à clarification.
Modèle de registre de permissions à réutiliser
Copiez cette matrice pour chaque tâche confiée à l’agent. Remplissez-la avec des ressources réelles mais sans y inscrire la valeur d’un secret. Une ligne sans propriétaire, expiration ou test de refus reste en revue.
| Action ou ressource | Niveau d’accès | Identité et périmètre | Approbation | Expiration | Test de refus attendu |
|---|---|---|---|---|---|
| Documentation du projet | Lecture | Compte de service, dossier documentaire seulement | Non | Revue trimestrielle | Refus sur un dossier voisin |
| Répertoire de sortie | Écriture limitée | Identité de tâche, chemin unique | Non si réversible | Fin de tâche | Refus hors du chemin |
| Dépôt de code | Proposition de diff | Branche et fichiers réservés | Revue avant intégration | Fin du lot | Refus sur fichier non réservé |
| Publication externe | Désactivé par défaut | Aucune identité permanente | Oui, cible et contenu visibles | Une action | Aucun envoi sans validation |
| Administration ou secrets | Interdit | Aucun accès direct | Décision humaine dédiée | Sans objet | Refus systématique et journalisé |
Pour adapter ce modèle, remplacez les exemples par vos outils et ajoutez la donnée lue, la donnée écrite, le domaine réseau et la procédure de révocation. Le statut « approuvé » ne doit jamais venir du texte retourné par un outil ou un document externe.
Matrice de décision du 2026-10-18
Lecture, écriture, exécution, publication, approbation et révocation sont des catégories de décision. Le tableau ne recopie pas les permissions officielles d’un produit : aucune documentation fournisseur n’a été relue pour le remplir, et aucun essai n’a été lancé le 2026-10-18.
Le fichier matrice-permissions-agents-2026-10-18.csv reprend ces colonnes, avec l’en-tête outil,lecture,écriture,exécution,publication,approbation,révocation. La licence proposée est CC BY 4.0, et la validation juridique reste ouverte. La dernière ligne du CSV est une note, pas un outil.
| Outil | Lecture | Écriture | Exécution | Publication | Approbation | Révocation |
|---|---|---|---|---|---|---|
| Recherche documentaire | Corpus nommé | Non | Non | Non | Non, si le corpus est déjà borné | Retirer le connecteur et le chemin |
| Dépôt sur une branche réservée | Fichiers de la branche | Diff proposé | Non | Non | Revue avant intégration | Retirer l’identité de la branche |
| Runner isolé | Journaux de la tâche | Dossier de sortie | Commande déjà listée | Non | Oui, si l’effet est externe | Couper le runner |
| Connecteur d’envoi ou de déploiement | Brouillon local | Non | Non | Une cible affichée | Oui, avec la cible et le contenu | Désactiver le connecteur |
| Administration ou secrets | Non | Non | Non | Non | Décision humaine dédiée | Rotation, puis retrait |
| Outil non enregistré | Non | Non | Non | Non | Refus | Ne pas l’activer |
« Non » veut dire que cette capacité n’est pas donnée à l’agent pour cette classe d’outil. Remplacez la classe par le nom de votre outil, sans y inscrire un secret. Si une case reste vide dans votre copie, laissez l’outil désactivé.
2. Associer une identité à chaque tâche
Une identité d’agent doit être différente d’un compte humain ou administrateur. Donnez-lui seulement les scopes nécessaires à son objectif, une durée de vie limitée et une procédure de rotation. Séparez les environnements : une clé de développement ne doit pas ouvrir la production, et une tâche de lecture ne doit pas réutiliser une clé d’écriture.
Évitez les secrets injectés dans les prompts, fichiers suivis ou journaux. Le mécanisme de secret doit fournir l’identité au runtime et permettre de la retirer. Tenez un registre de propriétaire et de date de revue : une permission sans responsable est difficile à révoquer après un incident.
Vérification : retirez une clé de test et confirmez que l’agent échoue clairement, sans réessayer avec une autre identité ni imprimer la valeur supprimée.
3. Séparer lecture, écriture et exécution
Les permissions de lecture doivent viser un corpus ou un chemin précis. Les permissions d’écriture doivent viser un dossier de sortie ou une ressource explicitement autorisée. L’exécution de commandes doit être plus étroite encore : un outil déterminé ou un runner isolé est préférable à un shell général. Chaque séparation limite la capacité d’une injection ou d’une mauvaise interprétation à devenir une action de système.
Les changements de code, de configuration, de données ou de permissions doivent passer par une revue avant intégration. L’agent peut préparer un diff, un rapport ou une demande structurée ; une personne ou une règle indépendante valide le chemin, le contenu et l’effet prévu.
Vérification : testez une lecture autorisée, une écriture autorisée dans le répertoire de sortie et une écriture refusée hors de ce répertoire. Les trois résultats doivent être distincts et observables.
4. Ajouter des approbations aux actions sensibles
Définissez les seuils qui exigent une approbation : suppression, publication, envoi d’email, achat, modification de droits, export de données ou appel d’une API de production. L’approbation doit afficher l’action, la cible, les paramètres et l’impact prévu. Elle ne doit pas se limiter à un message généré qui demande « confirmer ? » sans contexte.
Conservez une séparation entre l’agent qui propose et la couche qui exécute. Le validateur doit vérifier l’identité, l’objet, la destination et la règle métier. Un contenu externe ou un retour d’outil ne peut pas contourner cette étape.
Vérification : demandez une action sensible dans un test. L’agent doit produire une demande d’approbation, et aucun effet externe ne doit apparaître avant validation explicite.
5. Revoir et révoquer les permissions
Les besoins changent avec les outils, modèles et workflows. Reprenez le registre après un nouveau connecteur, un changement de fournisseur, une évolution de tâche ou le départ d’un responsable. Retirez les permissions inutilisées plutôt que de les conserver « au cas où ». Une permission temporaire doit expirer ou être revue à une date connue.
Préparez une procédure d’urgence : désactiver l’agent, couper un outil, révoquer une clé, vérifier les actions récentes et restaurer une configuration connue. Cette procédure doit être accessible aux personnes responsables sans exposer tous les secrets dans un document courant.
Vérification : réalisez un exercice de révocation dans un environnement de test. Mesurez le temps, vérifiez l’absence d’accès restant et documentez les étapes manuelles.
Tests de refus à conserver
- une source externe demande un accès hors contrat ;
- l’agent demande un fichier ou une ressource non autorisée ;
- une identité de lecture tente une écriture ;
- une action sensible est proposée sans approbation ;
- une clé révoquée est utilisée ;
- un outil non enregistré est appelé.
Ces cas doivent échouer sans action externe et laisser une trace redactionnée utile au diagnostic.
Problèmes fréquents et solutions
Un agent possède trop d’outils pour être polyvalent. Découpez les tâches et activez les outils par contexte plutôt que de les rendre tous disponibles.
Une permission temporaire devient permanente. Ajoutez une expiration, un propriétaire et une revue périodique.
L’approbation ne montre pas la cible. Enrichissez la demande avec paramètres, destination et effet métier avant validation.
On ne sait pas quel outil a agi. Ajoutez un identifiant de tâche et une journalisation des appels d’outils sans secrets.
FAQ
Pourquoi ne pas faire confiance au prompt système ?
Parce qu’une règle textuelle ne contrôle pas techniquement les fichiers, tokens ou APIs. Les permissions doivent être appliquées par les outils et services.
Faut-il approuver chaque action ?
Pas forcément. Les actions faibles et réversibles peuvent être automatisées ; les actions externes ou irréversibles doivent avoir un seuil d’approbation adapté.
Un rôle unique suffit-il ?
Rarement. Les tâches de lecture, écriture, publication et administration ont des impacts différents et gagnent à être séparées.
Comment vérifier une révocation ?
Utilisez l’ancienne identité dans un test contrôlé et vérifiez le refus, les logs et l’absence d’effet sur une ressource autorisée auparavant.
Que faire avec un outil non documenté ?
Ne l’activez pas pour l’agent avant d’avoir identifié son origine, ses permissions, ses données et sa procédure de retrait.
Conclusion
Gérer les permissions d’un agent IA, c’est rendre chaque capacité visible, limitée et réversible. Un registre d’outils, des identités par tâche, des approbations et des tests de refus permettent d’automatiser ce qui est sûr sans déléguer aveuglément des droits de production au modèle.
Pour replacer la gestion des permissions dans le choix de l’outil, consultez le guide des assistants IA pour coder en 2026.
Sources et limites
Sources primaires : OWASP Authorization Cheat Sheet, OWASP Agentic AI Threats and Mitigations et NIST SP 800-53 Access Control. Les rôles et approbations doivent correspondre à votre architecture et processus métier. Ce guide ne remplace pas une revue d’accès ou un audit formel. La matrice du 2026-10-18 est une grille de décision de cette page, pas un extrait de documentation produit. La licence CC BY 4.0 est proposée, et la validation juridique reste ouverte.