Limiter les permissions d'un agent IA

Un agent ne doit avoir que les outils, les droits et l'autonomie strictement nécessaires à sa tâche, et ces limites doivent être appliquées par votre code et vos systèmes, jamais seulement par une consigne écrite au modèle. C'est le principe du moindre privilège, appliqué à un programme dont on ne peut pas prévoir chaque décision.

Les trois excès à éviter

L'OWASP, fondation qui publie des référentiels de sécurité applicative, consacre une fiche de son référentiel des risques des applications de grands modèles de langage (LLM06:2025) à l'« agentivité excessive » (excessive agency). Elle en donne trois causes :

Les règles de l'OWASP, une par une

La fiche de l'OWASP sur l'agentivité excessive liste ces mesures de prévention :

1. Réduire le nombre d'extensions (outils) au strict nécessaire.
2. Réduire les fonctions de chaque extension : un outil de lecture de mails n'a pas besoin de savoir en envoyer.
3. Éviter les extensions ouvertes comme l'exécution libre de commandes système ; préférer des outils précis.
4. Réduire les permissions de chaque extension sur les systèmes en aval.
5. Exécuter les extensions dans le contexte de l'utilisateur, avec ses droits et pas davantage.
6. Exiger l'approbation de l'utilisateur avant les actions à fort impact.
7. Médiation complète : l'autorisation est vérifiée par le système en aval, pas par le modèle.
8. Assainir les entrées et sorties selon les bonnes pratiques de développement sécurisé.

Pour limiter les dégâts si une mesure échoue : journaliser et surveiller l'activité des extensions, et limiter le débit des actions.

Ce que demande l'ANSSI

Le guide « Recommandations de sécurité pour un système d'IA générative » de l'Agence nationale de la sécurité des systèmes d'information (ANSSI), publié le 29/04/2024, contient 35 recommandations. Celles qui visent directement un agent qui agit sur le système d'information (SI) :

L'ANSSI cite comme actions critiques les transactions bancaires, la production de contenu public, l'impact direct sur des personnes, mais aussi la reconfiguration de composants réseau, la création d'utilisateurs à privilèges ou le déploiement de serveurs virtuels. Pour R27, elle donne comme entrées non maîtrisées les données issues d'Internet ou de mails.

La mise en œuvre dans le code

Exemple avec le Claude Agent SDK, le kit de développement d'agents d'Anthropic, dont la documentation détaille l'ordre de vérification de chaque appel d'outil : points d'accroche (hooks), règles d'interdiction, règles de demande, mode de permission, règles d'autorisation, puis fonction de rappel canUseTool.

Un agent en lecture seule, d'après la documentation :

const options = {
  allowedTools: ["Read", "Glob", "Grep"],
  permissionMode: "dontAsk"
};

Les trois outils listés sont approuvés ; tout autre appel qui demanderait une validation est refusé.

Ce que la documentation demande de bien comprendre :

• allowed_tools approuve, il ne restreint pas : un outil non listé reste disponible et passe par le mode de permission. Pour retirer un outil, il faut l'interdire avec disallowed_tools (par exemple ["Bash"]), ou restreindre d'emblée les outils intégrés disponibles avec l'option tools.
• On peut restreindre un outil à certaines commandes : Bash(npm test *) n'autorise que les commandes qui correspondent ; Bash(rm *) en interdiction bloque ces commandes dans tous les modes, y compris bypassPermissions.
• Les règles d'interdiction passent avant tout : elles s'appliquent même en mode bypassPermissions et même si un point d'accroche a autorisé l'appel.
• bypassPermissions ne respecte pas allowed_tools : dans ce mode, des outils non listés comme Bash, Write ou Edit sont approuvés. La documentation le réserve aux environnements isolés (intégration continue, conteneurs).
• Une règle sur les chemins ne bloque pas tout : interdire l'écriture sous un dossier bloque les outils de fichiers et certaines redirections, mais un script lancé par l'agent peut encore y écrire. Pour une barrière au niveau du système d'exploitation, la documentation renvoie au bac à sable (sandbox).

Une liste de contrôle avant la mise en production

• Chaque outil correspond à une tâche précise ; aucun outil « exécuter n'importe quelle commande » sans nécessité.
• Chaque outil se connecte avec un compte dédié, aux droits minimaux, révocable.
• Les actions irréversibles passent par une validation humaine.
• Les droits sont vérifiés par le système cible, pas par le modèle.
• Un plafond de tours et de dépense arrête la boucle (max_turns, max_budget_usd dans le Claude Agent SDK).
• Chaque appel d'outil est journalisé (R29 de l'ANSSI).
• Les contenus extérieurs (mails, pages web, documents reçus) ne déclenchent pas d'action automatique sans contrôle (R27), à cause de l'injection de prompt.
• Une revue des droits est planifiée (R35).