Limiter les pouvoirs d’un agent

Décrire la tâche avant d’accorder l’accès

Un agent qui lit du code n’a pas besoin des mêmes pouvoirs qu’un agent qui déploie un service. N’accordez pas les deux ensembles de permissions parce qu’un même produit prend en charge les deux actions.

Définissez les pouvoirs en trois parties : une action, une ressource et une condition. Pour une correction fictive de rapport, l’agent peut écrire sur une seule branche de fonctionnalité pendant que la tâche est active. Il peut lire les fichiers approuvés du dépôt. Il ne peut modifier ni les données de production ni les règles de protection du dépôt.

Le mécanisme exact dépend de l’outil. Si un token ne permet pas de limiter l’accès à une branche, ajoutez des contrôles dans le dépôt ou passez par un service d’exécution. Décrivez honnêtement les pouvoirs qui restent disponibles.

Imposer la limite en dehors du modèle

Un prompt n’est pas un système de contrôle d’accès. Le composant d’exécution doit vérifier l’action demandée et sa cible au regard des permissions actuelles. Il ne doit pas accepter la simple affirmation du modèle selon laquelle l’approbation existe déjà.

AWS recommande des permissions limitées et des identifiants temporaires pour les workloads qui s’y prêtent. L’OWASP applique un raisonnement similaire de moindre privilège aux agents et à leurs outils. Ces principes doivent être mis en œuvre dans les systèmes réels d’identité et d’exécution. Conseils AWS IAM, conseils OWASP pour les agents.

Utilisez des identifiants de courte durée lorsque le système le permet. Ne placez pas de secrets sans rapport avec la tâche dans l’environnement. Une tâche de lecture du dépôt ne doit pas hériter d’un mot de passe de base de données de production présent dans le shell du développeur.

Lier l’approbation à l’action réelle

L’approbation de la préparation d’une modification ne vaut pas approbation de son déploiement. Une décision de déploiement doit identifier l’artefact, l’environnement cible et les conditions pertinentes. Si ces éléments changent, la décision précédente peut ne plus s’appliquer.

Imaginez un agent qui propose une lecture sans danger dans une base de données, puis exécute une autre requête après avoir obtenu l’approbation. Un mécanisme d’approbation utile vérifie l’opération réellement exécutée. Un message générique « continuez » sans cible définie peut masquer cette différence.

Distinguez aussi l’identité des capacités. Consignez la personne ou le workload à l’origine de l’exécution. Vérifiez que cette identité dispose encore des permissions nécessaires au moment de l’action. Le retrait de l’accès d’une personne doit avoir un effet explicite sur les travaux en attente.

Tester un refus et une interruption

Vérifiez autre chose que le parcours réussi. Dans un environnement de test isolé, tentez une action sur une ressource non autorisée. Confirmez que le système d’exécution la refuse. Examinez l’événement d’audit sans enregistrer d’identifiants secrets.

Testez ensuite l’annulation ou l’expiration des identifiants. Déterminez quels travaux s’arrêtent immédiatement et quelle opération peut se terminer. Un bouton d’arrêt n’annule pas nécessairement une action déjà parvenue à un autre système.

Joignez à la tâche une courte fiche de permissions. Indiquez le responsable, le périmètre approuvé, les contrôles réels, le test de refus et l’expiration. Une revue ultérieure disposera ainsi d’éléments assez précis pour améliorer le processus.