Listes d'autorisation d'outils d'agent IA : pourquoi le déni par défaut est gagnant

Pourquoi l'approche par défaut de refus fonctionne mieux que d'essayer de bloquer chaque appel malveillant

Lorsque vous commencez avec une approche de refus par défaut, vous n'avez qu'à réfléchir à ce dont l'AgentGuard a vraiment besoin. Chaque autre appel est arrêté automatiquement, sans avoir à prédire chaque utilisation abusive possible.

Considérez un agent qui rédige des rapports. Il doit lire un fichier de modèle, extraire des données d'une base de données, et envoyer le PDF terminé à une boîte aux lettres interne. Si vous n'énumérez que ces trois appels, toute tentative d'exécuter une commande shell, d'interroger une API externe, ou de supprimer une table est refusée instantanément. Vous n'avez jamais à écrire une règle qui dit « bloquer rm -rf », « bloquer curl vers evil.com », ou « bloquer DROP TABLE ».

Dans la pratique, j'ai vu des équipes passer des semaines à construire de longues listes de blocage qui manquent encore d'un nouveau vecteur d'attaque, alors qu'une courte liste d'autorisation de cinq éléments a arrêté les mêmes attaques le premier jour.

Comment créer une liste d'autorisation pour un nouvel agent

Je suis un processus répétitif qui maintient la liste concise et vérifiable.

- J'écris les tâches exactes que l'agent doit exécuter aujourd'hui. J'ignore les idées « qui pourraient être utiles plus tard ». - Pour chaque tâche, je trouve l'outil unique qui fait le travail avec les paramètres les plus étroits possibles. Si un outil propose un indicateur qui élargit la portée, je ne l'active pas à moins que la tâche n'en ait explicitement besoin. - Je consigne le nom de l'outil, la commande exacte ou le point de terminaison de l'API, ainsi que les valeurs de paramètres autorisées dans un fichier YAML simple. Ce fichier est stocké à côté du code de l'agent afin que les vérificateurs puissent le voir d'un seul coup d'œil. - J'exécute l'agent dans un bac à sable et je vérifie que chaque appel répertorié réussit et que tout appel non répertorié dans le fichier renvoie une erreur. - Je demande à un pair de vérifier la liste. Le travail du vérificateur est de confirmer que chaque entrée correspond à une tâche réelle et qu'aucune capacité supplémentaire ne se cache derrière les paramètres par défaut. - Je stocke le fichier dans le contrôle de version. J'attribue une balise à chaque validation avec la version de l'agent afin que je puisse retracer quelle liste d'autorisation a été livrée avec quelle version. - Je configure une étape de l'IC qui fait échouer la construction si le fichier YAML est manquant ou si celui-ci contient un outil non approuvé dans le registre d'outils du projet.

Ce processus me prend environ une heure pour un agent simple et produit un document que n'importe qui peut vérifier.

Classifier les outils par ce qu'ils peuvent modifier

Tous les outils ne présentent pas les mêmes risques. J'ai divisé les outils autorisés en trois classes d'impact pour savoir où ajouter des vérifications supplémentaires.

Classe d'impact | Ce que cela signifie | Exemple d'outil | Garde-fou typique Lecture seule | Peut récupérer des données mais ne peut pas modifier l'état | Lecture de fichier, sélection de base de données, API GET publique | Enregistrer l'appel, aucune approbation supplémentaire requise Écriture ou mutable | Peut créer, mettre à jour ou supprimer des données | Écriture de fichier, insertion/mise à jour/suppression de base de données, publication de message interne | Exiger un deuxième validateur pour la première utilisation, enregistrer avec l'ID utilisateur Effet externe irréversible | Peut affecter des systèmes en dehors de la limite de confiance | Envoi d'e-mail, publication sur les réseaux sociaux, initiation de paiement, appel de webhook externe | Approbation manuelle obligatoire, traçage détaillé, délai d'attente pour l'appel

Lorsque je révise un nouvel outil, je me demande : « Si cet appel est exécuté, quelle est la pire chose qui pourrait se produire ? » La réponse me indique quelle ligne du tableau s'applique. Pour les outils en lecture seule, j'ajoute uniquement une ligne de journal. Pour les outils d'écriture, j'ajoute un flux de travail d'approbation léger. Pour les effets irréversibles, j'impose une porte de garde manuelle et je garde la fenêtre d'appel courte.

Association des listes d'autorisation avec des filtres d'entrée et de sortie

Une liste d'autorisation supprime des capacités inutiles. Les filtres interceptent les mauvaises données qui passent à travers les appels autorisés. Je les traite comme des couches complémentaires, et non comme des remplacements.

Du côté de l'entrée, j'exécute un vérificateur d'injection de prompt qui recherche des modèles de jailbreak connus. J'utilise la feuille de triche de prévention d'injection de prompt LLM d'OWASP (lien) comme référence pour les règles que j'active. Si le vérificateur signale un prompt, je le rejette ou je sanitize le segment offensant avant que l'agent ne le voie.

Du côté de la sortie, j'analyse le texte généré par l'agent pour rechercher des secrets, des tentatives d'injection SQL ou des URL non autorisées. La feuille de triche de gestion des secrets (lien) m'aide à créer des modèles de regex pour les clés API, les mots de passe et les jetons. La feuille de triche de prévention d'injection SQL (lien) guide les modèles que j'utilise pour intercepter les chaînes de requête dangereuses qui pourraient être renvoyées dans une réponse.

Les deux ensembles de filtres s'exécutent comme un middleware léger. Ils ajoutent quelques millisecondes de latence, mais arrêtent de nombreuses attaques de faible effort avant qu'elles n'atteignent la couche d'outils. Puisque la liste d'autorisation a déjà supprimé des classes entières d'appels, les filtres ont une surface d'inspection plus petite, ce qui maintient les faux positifs à un niveau faible.

Ce que cela n'est pas

Je veux être clair sur les limites d'une liste d'autorisation pour que vous ne vous attendiez pas à ce qu'elle résolve des problèmes qu'elle n'était pas censée résoudre.

- Ce n'est pas une garantie que l'agent ne se comportera jamais de manière incorrecte. Un attaquant déterminé qui trouve un moyen d'appeler un outil autorisé avec des paramètres malveillants peut toujours causer des dommages. - Cela ne remplace pas les pratiques de codage sécurisées. Si le code de l'agent contient une vulnérabilité, la liste d'autorisation ne peut pas empêcher l'exploitation de cette faille. - Cela ne constitue pas un substitut à une gestion correcte des secrets. Même si l'agent ne peut pas appeler un outil d'exfiltration de secrets, les secrets divulgués dans les journaux ou la sortie posent toujours un risque. - Cela n'arrête pas l'injection de prompt indirecte qui manipule l'agent pour utiliser un outil autorisé d'une manière inattendue. Vous avez toujours besoin d'une validation des entrées et d'un filtrage des sorties. - Cela ne constitue pas une tâche ponctuelle. Chaque fois qu'un outil est ajouté, que ses paramètres changent ou que l'objectif de l'agent change, vous devez réexaminer la liste. - Cela ne constitue pas un remède miracle pour la conformité. Des réglementations telles que l'EU AI Act exigent une documentation, des évaluations des risques et une surveillance humaine qui vont au-delà d'une simple liste d'autorisation.

Comprendre ces limites vous aide à allouer vos efforts là où ils ajoutent une valeur de sécurité réelle.

Pièges courants que j'ai vus et comment je les évite

Même avec un processus clair, les équipes peuvent parfois tomber dans des habitudes qui affaiblissent la liste d'autorisation. Ci-dessous sont les modèles que je surveille et les étapes concrètes que je prends pour maintenir la liste honnête.

- Paramètres trop larges – Quelqu'un ajoute un outil avec un indicateur comme « --recursive » ou « --all » parce que cela semble pratique. Je contre cela en demandant : « Quel est l'ensemble minimal d'options qui satisfait à la tâche? » Si la réponse est un sous-ensemble, je verrouille l'indicateur sur ce sous-ensemble dans le YAML. - Mises à jour d'outils oubliées – Une bibliothèque met à jour et ajoute une nouvelle commande qui est exposée automatiquement. Je mitige cela en épinglant la version exacte de l'outil dans le fichier de dépendance de l'agent et en ajoutant une étape de CI qui échoue si une nouvelle version introduit des commandes non documentées. - Mélange de politique et de invite – Un développeur tente d'imposer des limites en ajoutant des instructions comme « ne pas appeler delete » à l'intérieur de l'invite.

Références

- Feuille de triche de prévention des injections de prompt LLM d'OWASP - Feuille de triche de prévention des injections SQL d'OWASP - Feuille de triche de gestion des secrets d'OWASP - Équipes d'Agent - Guide des fichiers de configuration

Questions fréquentes

Une instruction de prompt suffit-elle pour restreindre les outils?

Non. Les restrictions au niveau du prompt peuvent être contournées. Appliquez la liste d'autorisation au registre d'outils ou au niveau d'exécution.

Qu'est-ce qui constitue un effet externe irréversible?

L'envoi d'un e-mail ou de messages, le déplacement d'argent, la suppression de dossiers, la publication de contenu - tout ce que vous ne pouvez pas annuler.

Combien d'outils est trop?

Il n'y a pas de nombre. Le test est de savoir si vous pouvez expliquer, pour chaque outil de la liste, quelle tâche l'exige et ce qu'il peut détruire.

Les filtres remplacent-ils une liste d'autorisation?

Non. Les filtres capturent le contenu malveillant ; les listes d'autorisation suppriment les capacités inutiles. Utilisez les deux.

Cela couvre-t-il l'injection de prompt indirect?

Cela limite les dégâts que l'on peut faire. La détection et le blocage de l'injection elle-même constituent un contrôle d'entrée distinct.

La revue est-elle une audit de sécurité?

Non. Il s'agit d'un support de décision qui évalue les appels et suggère des filtres. Une évaluation complète du déploiement nécessite toujours une revue de sécurité.

Références

- OWASP — Top 10 pour les applications de modèles de langage à grande échelle - — Cadre de gestion des risques pour les modèles de langage

Essayez le produit : AgentGuard

Articles liés

- Les garde-fous de l'agent cartographiés sur le NIST AI RMF - Explorez la matrice complète des sujets de micro-SaaS IA →