Garde-fous d'agent cartographiés sur le cadre de gestion des risques de l'IA de la NIST

Pourquoi j'ai créé AgentGuard

J'ai lancé AgentGuard après avoir vu une équipe livrer un agent alimenté par qui pouvait lire une base de données, appeler une API de paiement et envoyer un e-mail, le tout avec une seule invite. L'agent fonctionnait dans la démo, mais un simple erreur de frappe dans la requête de l'utilisateur a provoqué le transfert de fonds vers le mauvais compte. Personne n'avait vérifié ce que l'agent était autorisé à faire avant l'appel, et il n'y avait pas moyen de l'arrêter une fois que l'erreur s'était produite.

J'ai réalisé que le problème ne venait pas du modèle lui-même, mais des limites manquantes autour de ses actions. Je voulais une méthode reproductible pour lister chaque outil que l'agent peut atteindre, décider qui peut activer chaque outil, tester l'agent contre les autorisations que nous pensons qu'il a, et réagir lorsque quelque chose se passe mal. Le cadre de gestion des risques de l'IA de la NIST m'a donné les quatre fonctions qui correspondent exactement à ces étapes.

Concepts fondamentaux : filtres d'entrée, autorisations d'outils, vérifications de sortie

Filtres d'entrée

Il s'agit de vérifications qui s'exécutent sur la invite de l'utilisateur ou la raison interne de l'agent avant qu'un outil ne soit invoqué. Des exemples incluent :

- La détection de modèles d'injection d'invite qui tentent d'ignorer les instructions précédentes. - La vérification de mots-clés ou de phrases interdits qui signalent une demande d'accès à un système restreint. - La validation du fait que l'invite contient un jeton d'approbation requis lorsque l'on fait référence à un outil à haut risque.

Nous mettons en œuvre des filtres d'entrée sous la forme de moteurs de regex légers combinés avec une petite liste d'autorisation de modèles sûrs. Ils ajoutent moins de deux millisecondes de latence par appel.

Autorisations d'outils

Les autorisations d'outils définissent les données qu'un outil peut lire, écrire ou supprimer, ainsi que les services externes qu'il peut contacter. Nous stockons chaque autorisation sous la forme d'un tuple :

- Identifiant d'outil - Sources de données autorisées (par exemple, accès en lecture seule à la table des clients, accès en écriture au journal d'audit) - Destinations réseau (par exemple, api.paymentprovider.com sur le port 443) - Niveau d'approbation requis (aucun, examen par les pairs, approbation du gestionnaire)

Lorsque l'agent demande à utiliser un outil, le service d'autorisation vérifie le tuple par rapport au contexte actuel et autorise l'appel, modifie les paramètres ou le bloque.

Vérifications de sortie

Après qu'un outil retourne un résultat, les vérifications de sortie vérifient que la réponse reste dans les limites attendues. Des exemples incluent :

- L'assurance qu'une requête SQL ne retourne pas plus de 100 lignes. - La confirmation qu'une charge utile de courrier électronique ne contient pas d'URL externes. - L'analyse de fuites de secrets tels que des clés API ou des mots de passe dans la réponse.

Si une vérification échoue, le système peut tronquer le résultat, masquer les parties sensibles ou déclencher une alerte.

Mapping des barrières de sécurité aux fonctions du cadre de référence NIST AI RMF

Le cadre est organisé autour de quatre fonctions qui donnent une structure claire pour organiser les travaux de barrières de sécurité. Ci-dessous se trouve un tableau qui montre à quelle fonction appartient chaque barrière de sécurité, l'artefact concret que nous produisons et un exemple court.

Fonction NIST | Type de barrière de sécurité | Artefact | Exemple Gouverner | Flux de travail d'approbation | Enregistrement d'activation de l'outil | Un document signé qui répertorie qui a approuvé l'outil d'envoi de courriel, la date et l'authentification multifacteur requise pour l'approbateur. Cartographier | Inventaire des outils | Matrice des autorisations | Une feuille de calcul qui énumère chaque outil, les tables qu'il peut lire/écrire et les points de terminaison externes qu'il peut appeler. Mesurer | Suite de tests | Ensemble de invites adverses | Une collection d'invites conçues pour déclencher une escalation de privilèges, une exfiltration de données ou des appels externes non autorisés. Gérer | Réponse en temps réel | Journal de l'interrupteur d'arrêt | Une entrée avec horodatage qui enregistre quand l'agent a tenté de supprimer un enregistrement de production, l'action qui a été bloquée et l'opérateur qui a été notifié.

Chaque fonction s'appuie sur la précédente. Gouverner décide qui peut ajouter un nouvel outil à l'inventaire. Cartographier crée l'inventaire que Mesurer testera. Mesurer produit des preuves que Gérer peut utiliser. La boucle se répète chaque fois que la liste des outils ou les invites de l'agent changent.

Comment nous évaluons un outil d'appel

Étape 1 : Identifier l'outil et sa classe de permission

Nous commençons par rechercher l'outil dans la matrice de permission. La matrice attribue un niveau de risque de base :

- Recherche en lecture seule (par exemple, récupération d'un catalogue de produits) → faible - Écriture dans un journal interne → moyen - Action externe avec des effets secondaires (par exemple, envoi d'argent, suppression d'un enregistrement) → élevé

Si l'outil nécessite un jeton d'approbation, nous ajoutons un niveau au niveau de risque de base.

Étape 2 : Analyser la invite pour le risque d'injection

Nous exécutons l'invite de l'utilisateur à travers le moteur de filtre d'entrée. Si le moteur détecte un modèle de la feuille de triche d'injection de prompt OWASP (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) nous augmentons le risque d'un niveau.

Étape 3 : Vérifier la sensibilité des données

Nous examinons les sources de données que l'outil peut toucher. Si une source contient des informations personnelles identifiables (PII) ou des données financières, nous ajoutons un autre niveau.

Étape 4 : Produire la note finale et les filtres suggérés

La note finale est la somme du niveau de base, des ajustements de niveau d'invite et des ajustements de niveau de données. Sur la base de la note, nous recommandons :

- Faible → aucun filtre supplémentaire, simplement enregistrer l'appel. - Moyen → ajouter un filtre d'entrée qui supprime les mots-clés non autorisés et une vérification de sortie qui limite le nombre de lignes. - Élevé → exiger une approbation humaine, appliquer une liste d'autorisation stricte de paramètres et activer la rédaction complète de la sortie.

Ce que cela n'est pas

Je veux être clair sur les limites des guardrails pour que vous ne les confondiez pas avec une solution miracle.

- Les guardrails ne garantissent pas qu'un agent ne causera jamais de dommages. Ils réduisent la portée d'une erreur, mais un attaquant déterminé ou un outil mal configuré peut toujours produire des effets indésirables à l'intérieur de la limite autorisée. - Ils ne remplacent pas les pratiques de codage sécurisées. Si l'outil sous-jacent comporte une vulnérabilité (par exemple, une faille d'injection SQL décrite dans la feuille de triche d'injection SQL https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), le guardrail ne peut pas corriger cette faille. - Ils ne fournissent pas une certification de sécurité à 100 %. Considérez-les comme des aides à la décision qui vous aident à prendre des choix éclairés sur l'utilisation des outils. - Ils ne constituent pas une configuration à paramétrer et à oublier. Chaque fois que la invite de l'agent, la liste des outils ou les données auxquelles un outil peut accéder changent, vous devez relancer le processus d'examen.

Mettre en pratique : un flux de travail d'examen étape par étape

1. Rassembler la liste des outils et des invites de l'agent

Exporter le texte exact que l'agent reçoit au démarrage et le fichier JSON ou YAML qui déclare chaque outil qu'il peut appeler.

2. Remplir la matrice de permissions

Pour chaque outil, enregistrer :

- Cibles de lecture autorisées - Cibles d'écriture autorisées - Points de terminaison externes et authentification requise - Tout jeton ou rôle d'approbation nécessaire

3. Exécuter l'évaluation des risques de base

Appliquer le processus d'évaluation des risques en quatre étapes décrit précédemment. Enregistrer le niveau de risque initial pour chaque outil.

4. Générer des suggestions de filtres d'entrée et de sortie

En fonction du niveau de risque, produire des règles de filtres concrètes (modèles de regex, limites de comptage de lignes, règles de rédaction). Les stocker aux côtés de la définition de l'outil.

5. Exécuter la suite de tests adverses

Exécuter l'agent contre l'ensemble d'invites de la colonne Mesure du tableau. Vérifier que les filtres bloquent ou atténuent les modes de défaillance attendus.

6. Documenter le résultat

Créer un court rapport qui répertorie :

- Nom de l'outil - Évaluation des risques initiale - Filtres appliqués - Résultats des tests (passer/échouer) - Toute étape d'approbation manuelle requise

7. Configurer la surveillance et les alertes

Configurer l'environnement d'exécution de l'agent pour consigner chaque appel d'outil, les filtres appliqués et les résultats de vérification de sortie. Router les anomalies vers votre canal de réponse aux incidents.

8. Planifier un déclencheur d'examen

Marquer le flux de travail pour se répéter lorsqu'il se produit l'un des événements suivants :

- Un nouvel outil est ajouté à la liste - L'invite du système est modifiée - Les permissions d'un outil changent (par exemple, une base de données gagne une nouvelle colonne avec des informations personnelles)

Pièges courants et la façon dont nous les évitons

Piège 1 : Dépendance excessive à un seul type de filtre

Les équipes pensent parfois qu'ajouter un bloqueur de mots clés suffit. Nous contrecarons cela en exigeant des vérifications d'entrée et de sortie pour tout outil à risque moyen ou élevé, et nous consignons lorsque l'une ou l'autre vérification se déclenche.

Piège 2 : Oubli de mettre à jour la matrice des autorisations

Lorsqu'un outil acquiert une nouvelle fonctionnalité (par exemple, une API de paiement prend désormais en charge les remboursements), la matrice doit être éditée avant que l'agent ne puisse l'utiliser. Nous imposons cela en faisant de la matrice un fichier contrôlé par version que le pipeline CI valide à chaque push.

Piège 3 : Ignorer les outils à faible risque qui deviennent à haut risque dans le contexte

Une recherche en lecture seule qui renvoie l'adresse e-mail d'un utilisateur peut devenir dangereuse si l'agent utilise ensuite cette adresse dans un flux de réinitialisation de mot de passe. Nous traitons la sensibilité des données comme un facteur de notation distinct, donc un outil de niveau inférieur qui touche les informations personnelles est automatiquement mis à niveau.

Piège 4 : Sauter l'étape de l'homme dans la boucle pour les outils à haut risque

Pour les outils qui peuvent déplacer de l'argent ou supprimer des enregistrements, nous exigeons une étape d'approbation explicite qui ne peut pas être contournée par l'automatisation. L'approbation est consignée dans un journal immuable.

Piège 5 : Traiter la configuration des barrières de sécurité comme une tâche ponctuelle

Nous intégrons le flux de travail d'examen dans la définition de l'équipe de tout ce qui est fait pour toute fonctionnalité qui modifie le comportement de l'agent. Cela rend le processus répétable plutôt qu'un élément de liste de vérification oublié.

Références

- https://genai.owasp.org/llmrisk/-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Questions fréquentes

Les garde-fous rendent-ils un agent sécurisé?

Non. Ils limitent la portée d'une erreur. Un attaquant déterminé, un outil mal configuré ou une invite incorrecte peuvent toujours causer des dommages à l'intérieur de la limite que vous avez autorisée.

Que devons-nous faire pour exécuter une revue?

L'invite système de l'agent et sa liste d'outils. C'est suffisant pour évaluer les appels et suggérer des filtres.

La cartographie du règlement UE sur l'IA est-elle un conseil juridique?

Non. C'est une cartographie pour vous aider à trouver les bonnes obligations. La classification de votre système et la satisfaction des obligations nécessitent toujours un examinateur qualifié.

Combien de fois devons-nous réexécuter la revue?

Chaque fois que la liste d'outils, l'invite système ou les données auxquelles un outil peut accéder changent.

Est-ce qu'il teste l'agent au moment de l'exécution?

Il examine l'invite et la configuration de l'outil. La surveillance au moment de l'exécution est une couche distincte dont vous avez toujours besoin.

Que se passe-t-il si un outil présente un risque élevé?

Exigez une étape d'approbation, restreignez ses paramètres et enregistrez chaque invocation. Les outils à haut risque nécessitent généralement un humain dans la boucle plutôt qu'un filtre.

Références

- OWASP — Top 10 pour les applications de grands modèles de langage - — Cadre de gestion des risques pour les modèles de langage

Essayez le produit : AgentGuard

Articles liés

- Les listes de contrôle des outils d'agent IA : pourquoi deny-by-default est gagnant - Explorez la matrice complète des sujets de micro-SaaS IA →