Guide express : auditer les permissions d’un agent IA

Un agent IA ne se contente plus de générer du texte. Connecté à des API, des fichiers, des bases de données ou des outils d’administration, il peut agir à la place d’un utilisateur. Son principal risque n’est donc pas seulement l’erreur de réponse : c’est l’excès de privilèges.

Pourquoi les permissions des agents IA changent la donne

Une application classique exécute généralement un ensemble de fonctions prévues à l’avance. Un agent, lui, interprète une demande, choisit un outil, enchaîne plusieurs actions et conserve parfois un état. Cette autonomie introduit une chaîne de confiance plus longue : modèle, orchestrateur, connecteurs, identité technique et ressources ciblées.

Une simple permission « lecture-écriture » peut ainsi devenir très large. Si l’agent dispose d’un accès à un dépôt de code, à une messagerie interne et à un outil de déploiement, une instruction malveillante ou une sortie manipulée peut provoquer une fuite de données ou une modification en production.

L’audit doit donc répondre à une question concrète : quelles actions cet agent peut-il réellement effectuer, avec quelle identité et dans quelles conditions ?

1. Dresser la cartographie complète des accès

Commencez par inventorier l’agent comme s’il s’agissait d’un nouveau service critique. Ne vous limitez pas aux permissions déclarées dans sa configuration : vérifiez les droits hérités, les variables d’environnement, les jetons présents dans le coffre de secrets et les accès accordés par les outils appelés.

• Identité : compte humain, compte de service, rôle cloud ou identité fédérée ;
• Ressources : fichiers, bases, API, dépôts, queues et environnements accessibles ;
• Actions : lecture, création, modification, suppression, exécution ou partage ;
• Contexte : réseau source, horaires, appareil, environnement et niveau de confiance ;
• Dépendances : extensions, modèles externes, bibliothèques et services d’orchestration.

Cette cartographie doit être exploitable par un tiers. Un tableau associant chaque outil à son identité, son périmètre et son propriétaire suffit souvent à révéler les droits orphelins ou les connexions installées sans validation formelle.

2. Vérifier le principe du moindre privilège

Le moindre privilège ne consiste pas à donner peu de droits « en général », mais uniquement les droits nécessaires à une tâche précise. Un agent chargé de classer des tickets n’a aucune raison de supprimer un utilisateur, de lire les salaires ou de publier directement une version logicielle.

Préférez des rôles séparés et temporaires. Un agent peut consulter une base anonymisée, préparer une modification sous forme de proposition, puis laisser un humain autoriser l’écriture. Pour les opérations sensibles, utilisez des jetons à durée de vie courte, limités à une ressource et à une méthode HTTP donnée.

3. Contrôler les entrées et les sorties

Une permission correcte peut être détournée par une injection indirecte. Un document indexé, une page web ou un commentaire de code peut contenir une instruction qui tente de faire ignorer les règles de l’agent. Le problème ne relève donc pas uniquement du modèle : il concerne la frontière entre contenu non fiable et outil privilégié.

Marquez les données provenant de l’extérieur, filtrez les instructions extraites de documents et imposez une validation côté serveur. Les règles de sécurité doivent être appliquées par l’API, pas seulement dans le prompt système. Un agent qui reçoit l’ordre de ne pas supprimer un fichier ne doit pas pouvoir contourner cette consigne par un appel direct à l’outil.

Dans les environnements éducatifs, cette séparation est tout aussi importante : les plateformes de suivi, les données d’élèves et les outils d’orientation ne doivent pas exposer les mêmes niveaux d’accès. Pour mieux comprendre les parcours scolaires et les usages numériques associés, vous pouvez en savoir plus sur les ressources consacrées à la réussite éducative et à l’orientation.

4. Examiner les journaux et les scénarios d’abus

Un audit sans traces fiables reste une photographie incomplète. Journalisez l’identité utilisée, l’outil appelé, la ressource ciblée, le résultat, le volume de données et la décision humaine éventuelle. Évitez toutefois d’enregistrer les secrets ou le contenu intégral de données sensibles dans les journaux.

Construisez ensuite des tests adverses reproductibles. Parmi les scénarios à couvrir :

• demande d’accès à une ressource située hors du périmètre ;
• document contenant une instruction contradictoire ou une tentative d’exfiltration ;
• enchaînement de petites actions menant à une opération à haut impact ;
• réutilisation d’un jeton expiré ou changement de rôle en cours de session ;
• défaillance d’un outil externe et comportement de repli de l’agent.

Le résultat attendu n’est pas nécessairement un refus systématique. Il peut s’agir d’une demande de confirmation, d’une réduction automatique du périmètre ou d’un passage en mode lecture seule. L’important est que le comportement soit prévisible, observable et documenté.

5. Inscrire l’audit dans une boucle Zero Trust

Les agents IA doivent être traités comme des identités non fiables par défaut, même lorsqu’ils s’exécutent dans le réseau interne. Authentifiez chaque appel, vérifiez le contexte à chaque étape et segmentez les ressources. Cette approche rejoint les architectures Zero Trust et les modèles ZTNA : l’emplacement réseau ne suffit plus à accorder la confiance.

Planifiez une revue après chaque évolution du modèle, de l’outil ou du connecteur. Comparez les permissions effectives avec les permissions attendues, mesurez les refus et recherchez les accès inutilisés. Un rapport court, produit chaque mois, vaut mieux qu’un audit exceptionnel oublié dans un dossier.

Pour suivre les évolutions de l’IA générative, de la cybersécurité et des architectures logicielles, retrouvez les analyses de Galibyte sur notre page d’accueil.