Notion · Sécurité et conformité
Permissions d’un agent (moindre privilège)
Ne donner à un agent que les accès strictement nécessaires à sa tâche : lire ce dossier, écrire dans celui-là, rien d’autre. Si ça tourne mal, les dégâts restent contenus.
Comment ça marche
Le principe du moindre privilège vient de la sécurité informatique : chaque utilisateur, chaque programme, n’a que les droits nécessaires à sa fonction. Appliqué aux agents IA, il devient la défense centrale. Un agent peut se tromper, être trompé par une injection, ou interpréter mal une consigne. Si son périmètre est réduit, les conséquences le sont aussi. Si son périmètre est large, une erreur peut toucher n’importe quoi.
Le périmètre d’un agent se définit sur plusieurs axes. Les fichiers : quels dossiers en lecture, lesquels en écriture. Les outils : lesquels sont disponibles, avec quelles fonctions. Les comptes : quels identifiants, avec quels droits chez chaque service. Les actions : lesquelles demandent une validation, lesquelles sont interdites. Le réseau : quels sites, quels services. Tout ça se règle dans le harnais, les modes de permission, les hooks, et les comptes dédiés. Et tout ça s’écrit, pour être relu.
Un exemple concret
- Fichiers : lecture sur exports/ (les exports comptables) et gabarits/. Écriture uniquement sur rapports/, dans un sous-dossier daté. Aucun accès au reste du disque.
- Outils : lecture de tableurs, génération de graphiques, écriture de documents. Pas d’envoi d’e-mail, pas d’accès web, pas d’exécution de commandes hors d’une liste.
- Comptes : un compte de lecture seule sur l’outil comptable, créé pour l’agent, avec son propre identifiant. Pas le compte du contrôleur de gestion.
- Actions : suppression interdite par un hook. Le rapport produit est déposé, pas envoyé : le contrôleur l’envoie.
- Historique des élargissements : mars, lecture seule partout, pour observer. Avril, écriture sur rapports/. Juin, accès au compte comptable en lecture, après deux mois sans incident. Chaque étape notée dans le README.
Si une injection glissée dans un export demandait à l’agent d’envoyer les données ailleurs, il ne le pourrait pas. Il n’a ni outil d’envoi, ni accès web, ni droit d’écriture hors de rapports/.
Ce que ça change pour une équipe
- Les agents deviennent utilisables sur des données réelles. Parce qu’une erreur reste dans un périmètre connu.
- L’injection de prompt perd l’essentiel de son danger. Un agent qui ne peut rien envoyer ni supprimer ne peut pas être détourné pour le faire.
- Les périmètres sont lisibles. Une page par agent : qui peut quoi. Un client ou un auditeur peut la lire.
- L’autonomie se gagne. Un agent qui a fait ses preuves dans un petit périmètre en obtient un plus grand. C’est un chemin, pas un saut.
Les limites et les erreurs fréquentes
- Le compte personnel pour l’agent. L’agent hérite de tous vos droits. Un compte dédié, avec les droits de la tâche.
- « Au cas où ». Un accès de plus, pour éviter d’avoir à le rajouter. C’est l’accès qui servira à l’incident.
- Réduire sans vérifier. Un périmètre trop étroit fait échouer la tâche de façon obscure. On teste le périmètre avant de lancer en production.
- Ne jamais réduire. Les périmètres grandissent et ne rétrécissent jamais. Quand une tâche change ou disparaît, on retire ce qui ne sert plus.
Pour aller plus loin
Le principe du moindre privilège s’applique aux outils, aux fichiers, aux comptes et aux connecteurs. Il se combine à la sandbox et à la journalisation, et se révise à chaque extension du périmètre de l’agent.
Où ça se situe chez Opora
Programme 04 · Construire des agentsIngénierie agentique pour les équipes techniques
Définir le périmètre exact de chaque agent, et l’élargir seulement sur preuve, c’est une règle que nous appliquons à chaque agent construit dans le programme Construire des agents.
Questions fréquentes
Qu’est-ce que ça veut dire, pour un agent ?
Que l’agent n’a accès qu’aux fichiers, outils, comptes et services dont sa tâche a besoin, avec le niveau minimal : lecture quand la lecture suffit, écriture sur un périmètre réduit, jamais de suppression ou d’envoi sans validation. Si la tâche change, le périmètre change ; pas avant.
N’est-ce pas contraignant ?
Au début, un peu : il faut réfléchir à ce dont l’agent a besoin. Mais c’est cette réflexion qui rend l’agent utilisable sur des tâches sérieuses. Un agent qui a accès à tout ne peut être lancé que sur des tâches sans enjeu, parce qu’une erreur ou une injection pourrait toucher n’importe quoi.
Comment élargir le périmètre ?
Sur preuve. L’agent a fait ses preuves en lecture seule : on lui ouvre l’écriture sur un dossier. Il a géré un mois sans incident : on étend. Chaque élargissement est une décision, écrite, avec sa raison. Et chaque réduction de tâche est l’occasion de réduire le périmètre.