Outils autorisés vs agents à fin ouverte

Définitions d'outils à privilèges minimaux

Je commence par rédiger un contrat d'outil qui spécifie exactement ce que l'agent est autorisé à faire et ce qu'il ne peut pas faire. Un outil « lire ticket » ne devrait exposer qu'une opération GET sur un identifiant de ticket spécifique, sans possibilité de modifier le ticket, d'attacher des fichiers ou d'appeler d'autres points de terminaison. Un outil « envoyer un e-mail » ne devrait accepter qu'une liste de destinataires prédéfinie, un modèle de ligne d'objet fixe et un corps qui est désinfecté pour l'injection de nouvelles lignes. En rétrécissant le contrat, une erreur unique dans la sortie du modèle devient un événement limité au lieu d'une cascade.

Définir l'ensemble de verbes

Lister chaque méthode HTTP, commande de base de données ou opération de fichier dont l'outil a besoin. Si l'outil n'a besoin que de lire, omettre POST, PUT, DELETE et toutes les commandes administratives. Je garde une feuille de calcul qui mappe chaque nom d'outil aux verbes autorisés et je la revoie chaque fois qu'un nouveau point de terminaison est ajouté.

Restreindre les arguments

Pour chaque argument, je spécifie un type, une limite de longueur et un jeu de caractères autorisé. Un ID de ticket peut être un UUID, limité à 36 caractères. Un chemin de fichier peut être restreint à un sous-répertoire sous /var/agent/data et ne doit pas contenir «.. » ou des chemins absolus. J'utilise une bibliothèque de validation de schéma qui rejette toute demande qui ne correspond pas avant que l'outil ne s'exécute.

Versionner le contrat

Je stocke la définition de l'outil sous forme de fichier JSON dans le contrôle de version. Tout changement déclenche une demande de tirage qui nécessite une approbation d'un réviseur de sécurité. Cela crée une traçabilité qui montre quand la surface de privilège a été étendue et pourquoi.

Pour voir comment l'injection de prompt peut abuser d'outils trop larges, consultez le guide OWASP LLM01 : https://genai.owasp.org/llmrisk/llm01-prompt-injection. La feuille de triche montre des exemples concrets où un modèle a été trompé pour invoquer une commande shell parce que l'outil acceptait une entrée non restreinte.

Nom de l'outil | Verbe autorisé | Contraintes d'argument | Appel sécurisé d'exemple lire_ticket | GET | ticket_id : UUID, 36 caractères | /tickets/123e4567-e89b-12d3-a456-426614174000 envoyer_un_e-mail | POST | à : liste à partir de domaines approuvés, sujet : maximum 78 caractères, corps : désinfecté | {"à":["user@example.com"],"sujet":"Mise à jour","corps":"Veuillez examiner le rapport joint."} list_files | GET | chemin : doit commencer par /var/agent/data/, sans «.. » | /var/agent/data/logs/2024-09-01.txt

Confirmation des actions irréversibles

Les actions qui modifient l'état en dehors du bac à sable de l'agent - telles que l'envoi d'un message, la suppression d'un enregistrement ou le déploiement d'une version - doivent être gérées par une étape d'approbation distincte que l'agent ne peut pas invoquer lui-même. Je traite ces actions comme des portes à sens unique et je conçois la politique pour exiger un jeton humain ou un service d'approbation à court terme avant que l'outil ne s'exécute.

Point de terminaison d'approbation distinct

J'expose une API interne qui accepte une demande signée de l'agent, enregistre la demande, puis attend qu'un humain clique sur « approuver » dans une interface utilisateur ou réponde à une commande de chat. L'agent reçoit uniquement un identifiant en attente ; il ne peut pas interroger le point de terminaison d'approbation pour forcer une concession.

Jetons à durée de vie limitée

Lorsque l'approbation est accordée, le système émet un jeton qui est valide pour une seule utilisation et expire après cinq minutes. Le point de terminaison de l'outil vérifie la signature et l'expiration du jeton avant de procéder. Si le jeton est manquant ou obsolète, l'outil renvoie une erreur et la tentative est enregistrée.

Enregistrement de la porte

Chaque demande d'approbation et chaque décision sont écrites dans un journal immuable avec des horodatages, l'identifiant de l'agent, le nom de l'outil et les arguments qui ont été présentés. Ce journal me permet de reconstruire si une instruction empoisonnée a réussi à contourner la porte ou a été arrêtée à l'étape d'approbation.

Pour obtenir des conseils sur la sécurité de l'hygiène des informations d'identification dans les pipelines automatisés, consultez la feuille de risques de sécurité OWASP CI/CD : https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene. Elle renforce le principe selon lequel les secrets ne devraient jamais être stockés dans un endroit où un agent peut les lire sans un flux d'approbation explicite.

Les journaux d'audit comme un contrôle, et non comme une après-pensée

Je traite le journal d'audit comme la preuve principale que une politique est appliquée. Sans un journal fiable, les déclarations sur les privilèges minimum sont des allégations non vérifiables. Je conçois la couche de journalisation pour être en écriture seule du point de vue de l'agent et pour être stockée dans un système que l'agent ne peut pas modifier ou supprimer.

Ce qui doit être journalisé

- Horodatage avec une précision à la milliseconde - Identifiant de l'agent (version du modèle, ID de déploiement) - Nom de l'outil et verbe appelé exact - Tous les arguments passés à l'outil, après validation - Code de statut de résultat et résumé des données renvoyées (taille, pas contenu complet) - Source de la demande (initiée par l'utilisateur, déclencheur planifié ou moteur de politique)

Garanties de stockage

J'écris chaque entrée de journal dans un magasin en écriture seule, tel qu'un journal de pré-écriture dans un bac de stockage cloud avec la version d'objet activée. La stratégie du bac refuse toute opération de suppression ou de réécriture à partir du compte de service de l'agent. Cela garantit que même si le modèle est compromis, l'historique reste intact.

Requêter pour les investigations

Lorsqu'un incident est signalé, j'exécute une requête SQL simple contre l'index de journal pour trouver toutes les exécutions d'un outil particulier dans une fenêtre de temps. J'évite les joints complexes qui pourraient être lents ; au lieu de cela, je me fie à des tables partitionnées par date et nom d'outil. La requête renvoie la liste des identificateurs que je retire ensuite pour une analyse forensique plus approfondie.

Pour comprendre comment la validation des entrées peut empêcher les arguments malveillants d'atteindre un outil, consultez la feuille de triche de prévention des injections SQL : https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html. La feuille montre des requêtes paramétrées et un typage strict, qui reflètent l'approche de validation des arguments que j'utilise pour les outils d'agent.

Lorsque l'accès ouvert est justifié

Il existe des cas légitimes où un agent nécessite une portée plus large, tels que l'analyse de données exploratoires ou la chasse aux menaces dans un environnement isolé. Dans ces situations, j'accorde l'ouverture uniquement après avoir placé l'agent dans un bac à sable qui bloque tout chemin d'accès aux données de production ou aux systèmes de paiement externes.

Limites du bac à sable

Le bac à sable fournit un shell, un moteur de navigateur et une boîte aux lettres qui ne peut envoyer des messages qu'à un domaine de test dédié. La stratégie réseau bloque le trafic sortant vers toute adresse IP appartenant aux plages CIDR internes de l'entreprise. La sortie est autorisée uniquement vers un ensemble de miroirs publics approuvés pour l'installation de packages.

Isolement des informations d'identification

Aucun secret de production n'est monté dans le système de fichiers du bac à sable. Au lieu de cela, l'agent reçoit un jeton temporaire qui peut lire à partir d'un bac de données public. Si l'agent tente de lire un fichier en dehors du point de montage autorisé, le noyau renvoie une erreur de permission et la tentative est consignée.

Sessions à durée limitée

Chaque session de bac à sable dure au maximum deux heures. Après l'expiration du délai, l'environnement est détruit et une image fraîche est lancée. Cela limite la fenêtre pendant laquelle un agent malveillant pourrait explorer ou exfiltrer des données.

J'applique toujours des définitions d'outils de privilèges minimum à l'intérieur du bac à sable ; la différence est que les conséquences d'une erreur sont contenues dans l'environnement jetable plutôt que dans les systèmes de production.

Considérer les politiques générées comme des brouillons

Lorsqu'un modèle ou un ingénieur junior produit un fichier de politique, je le révise exactement comme je réviserais du code non fiable qui est sur le point d'être déployé sur un service critique. La liste de contrôle de révision comprend la vérification de chaque règle par rapport aux définitions d'outils réelles, la confirmation de l'existence de chemins de refus et la garantie que le fichier est versionné.

Mappage règle-outil

Je crée une feuille de calcul qui liste chaque outil sur un axe et chaque règle de politique sur l'autre. Pour chaque cellule, je marque si la règle permet, refuse ou est silencieuse sur le fonctionnement de l'outil. Toute cellule silencieuse déclenche un commentaire qui demande à l'auteur de clarifier l'intention.

Vérification par défaut de refus

J'exécute un script d'analyse statique qui tente d'appeler chaque outil avec un ensemble d'arguments malformés. Si le script trouve une combinaison que la politique permet mais qui devrait être refusée (par exemple, un outil « supprimer » acceptant un identifiant générique), le script échoue la construction et la politique doit être révisée.

Contrôle de version et révision

Le fichier de politique vit dans un référentiel Git avec une protection de branche qui nécessite deux approbations avant de fusionner. Je marque chaque version publiée avec un numéro sémantique (par exemple, v1.2.0) et j'attache l'instantané de définition d'outil correspondant. Cela permet de revenir à un état connu-sûr si une nouvelle version introduit une règle trop permissive.

Je ne considère jamais une politique générée comme définitive jusqu'à ce qu'elle ait passé ce cycle de révision. Une politique qui n'est jamais examinée crée un faux sentiment de sécurité et peut cacher des lacunes qui n'apparaissent que sous une charge réelle.

Ce que ce n'est PAS

Ce guide ne promet pas que suivre les étapes éliminera chaque mode de défaillance possible. Je ne prétends pas 100 % de protection contre l'injection de prompte, la fuite de données d'identification ou les erreurs de logique. Je ne déclare pas non plus qu'un agent ne manquera jamais une instruction malveillante ; la détection dépend de la qualité des journaux, de la rapidité de la révision humaine et de la correction des contrats d'outil. Traitez les modèles comme des mesures de réduction des risques, et non comme une garantie de sécurité absolue.

Articles liés

- Les packs de stratégie d'agent d'IA via une lentille NIST AI RMF - Explorez la matrice complète du sujet micro-SaaS d'IA →