Sécuriser un agent IA : la sandbox ne suffit pas sans cinq contrôles

Pour sécuriser un agent IA connecté à des outils, des données et des services externes, la sandbox n’est qu’une couche d’isolation. Elle ne décide pas quelles données l’agent peut lire, quels arguments il peut transmettre ni quelles actions doivent attendre une autorisation humaine. La checklist de sécurité de l’OWASP distingue d’ailleurs l’exécution isolée du moindre privilège, de la validation, de la surveillance et du contrôle humain.

Le minimum défendable avant la production tient donc en cinq contrôles complémentaires : frontières de confiance explicites, privilèges minimaux, validation déterministe, surveillance exploitable et intervention humaine imposée hors du modèle. Pour chacun, l’équipe doit pouvoir présenter une configuration, une preuve de fonctionnement et un comportement sûr lorsque le contrôle échoue.

1. Cartographier les frontières de confiance

Tracez le parcours complet d’une requête : utilisateur, orchestrateur, modèle, mémoire, récupération documentaire, outils, API et stockage. Conservez la provenance et le niveau de confiance des données à chaque passage. Une réponse du modèle, un document récupéré par RAG ou le résultat d’un outil reste une donnée non fiable tant qu’un contrôle indépendant ne l’a pas validé.

La documentation de Microsoft Agent Framework décrit chaque entrée ou sortie de l’application comme une surface d’attaque potentielle. Elle demande notamment de traiter les arguments choisis par le modèle comme des entrées non approuvées et de ne jamais placer une entrée non fiable dans un message système.

• Configuration minimale : inventaire des composants et des flux, séparation des rôles système et utilisateur, provenance attachée aux contenus, chiffrement des échanges et destinations réseau autorisées.
• Preuve attendue : un schéma relié à des règles exécutables, accompagné d’un test où une instruction hostile issue du RAG est détectée ou empêchée de déclencher un outil sensible.
• Mode d’échec : si l’origine ou le niveau de confiance manque, l’action sensible est refusée et le contenu n’est jamais promu au rang d’instruction privilégiée.

2. Réduire l’identité, les outils et les permissions

Attribuez une identité distincte à chaque agent et à chaque environnement. Écartez les comptes partagés, les secrets inscrits dans le prompt et les jetons valables sur plusieurs services. Les autorisations doivent être limitées à la tâche, aux ressources visées et à la durée nécessaire.

Partez d’une liste d’outils vide, puis ajoutez uniquement les opérations indispensables. Séparez lecture et écriture, limitez les destinations réseau et fixez des plafonds d’appels, de durée, de coût et de volume. Le modèle Zero Trust de Microsoft recommande précisément une identité vérifiable par agent, aucune action autorisée par défaut, des schémas d’action explicites et une défense en profondeur où la défaillance d’une couche ne suffit pas à provoquer un dommage inacceptable.

• Configuration minimale : identité dédiée, contrôle d’accès par rôle, outils en liste d’autorisation, justificatifs de courte durée, quotas et blocage des sorties réseau inutiles.
• Preuve attendue : une matrice reliant chaque capacité à un besoin métier, plus des tests confirmant le refus d’un outil absent et de données situées hors du périmètre autorisé.
• Mode d’échec : un refus d’autorisation interrompt l’étape ; il ne provoque ni escalade automatique ni reprise avec un compte plus puissant.

3. Valider chaque donnée avant qu’elle produise un effet

Un prompt de sécurité reste une consigne interprétée par un modèle probabiliste. Placez donc les décisions de sécurité dans du code entre le modèle et chaque effet externe. Chaque outil doit accepter un schéma fermé précisant types, champs obligatoires, valeurs permises, longueurs, bornes, chemins accessibles et opérations autorisées.

Paramétrez les requêtes SQL, interdisez la construction libre de commandes shell et résolvez les chemins avant de vérifier leur appartenance à un répertoire autorisé. Contrôlez également les réponses du modèle avant affichage, exécution ou stockage : elles peuvent contenir du HTML actif, une commande, des données sensibles ou un appel d’outil hors périmètre.

• Configuration minimale : schémas fermés, listes d’autorisation, normalisation canonique, limites de taille et validation adaptée au contexte d’utilisation de la sortie.
• Preuve attendue : des tests de traversée de répertoires, de champs supplémentaires, d’injection indirecte, de valeurs hors plage et de charge malveillante renvoyée par un outil.
• Mode d’échec : toute valeur ambiguë ou non conforme est rejetée. L’agent reçoit une erreur structurée sans détail sensible et ne peut pas réessayer avec une règle plus permissive.

4. Rendre les écarts visibles et l’arrêt effectif

Consignez l’identité de l’agent, les versions du modèle et des politiques, l’outil demandé, les paramètres expurgés, la décision d’autorisation, le résultat et l’éventuel approbateur. Protégez ces journaux comme des données sensibles : masquage des secrets et données personnelles, accès restreint, intégrité contrôlée et durée de conservation définie.

Déclenchez des alertes sur les refus répétés, les changements brusques d’outils, les volumes anormaux, les nouvelles destinations et les accès hors périmètre. Chaque alerte critique doit conduire à une procédure testée : suspendre l’identité, révoquer ses jetons, arrêter les tâches en cours et préserver les traces nécessaires à l’enquête.

• Configuration minimale : traces corrélées de bout en bout, alertes attribuées à un responsable, budgets de consommation, mécanisme d’arrêt indépendant et procédure de révocation.
• Preuve attendue : une exécution reconstituable, puis un exercice montrant qu’une alerte entraîne réellement le blocage de l’identité concernée.
• Mode d’échec : si la télémétrie critique disparaît ou si un budget est dépassé, les capacités d’écriture sont suspendues au lieu de poursuivre sans visibilité.

5. Réserver les effets élevés à une décision humaine

L’approbation doit être appliquée par l’orchestrateur ou un service de politique indépendant, jamais laissée au raisonnement du modèle. Classez au minimum comme sensibles les suppressions, paiements, communications externes, changements de droits, écritures en masse, exécutions de code et accès exceptionnels à des données confidentielles.

L’approbateur doit voir l’action exacte, sa cible, ses paramètres normalisés et ses effets prévisibles. L’autorisation doit être de courte durée, liée à cette opération immuable et inutilisable après modification ou expiration. Un simple bouton générique validant le résumé rédigé par l’agent ne constitue pas une preuve suffisante.

• Configuration minimale : niveau de risque par action, validation obligatoire pour les effets élevés ou irréversibles, séparation des rôles et voie explicite de rejet.
• Preuve attendue : un test où la modification d’un paramètre après validation invalide l’autorisation, avec un journal attribuant la décision à une personne habilitée.
• Mode d’échec : sans réponse, après un refus ou à l’expiration de l’approbation, aucune action n’est exécutée et aucune décision antérieure n’est réutilisée.

Décider du passage en production

Autorisez la production seulement lorsque les cinq preuves existent simultanément. La sandbox réduit le rayon d’impact de l’exécution, mais ne compense ni une identité surpuissante, ni des paramètres non validés, ni une activité invisible, ni une approbation que l’agent peut contourner.

Versionnez la checklist avec l’agent, ses outils, son modèle et ses politiques. L’ajout d’une source de données, d’une permission, d’une mémoire persistante ou d’une action externe modifie la surface de confiance : le contrôle concerné doit alors être rejoué avant le déploiement.

À lire aussi:

• Google My Activity : effacer le compte ne vide pas le navigateur