Sécuriser des agents IA : cinq frontières à contrôler avant l’autonomie

Pour sécuriser des agents IA avant de leur déléguer des actions, il faut borner ce que chaque composant peut décider, transmettre et exécuter, puis prévoir un arrêt indépendant de leur coopération. La méthode couvre cinq frontières : modèle, orchestrateur, outils, environnement d’exécution et intervention humaine.

Pour chacune, consignez avant le déploiement la menace, le contrôle, la preuve attendue et la condition d’arrêt. Il ne s’agit pas de remplacer les pratiques classiques — identité, moindre privilège, segmentation, journalisation et réponse à incident — mais de les adapter aux décisions non déterministes : l’analyse des réponses publiée par le NIST constate un large accord sur cette nécessité.

1. Modèle : traiter toute sortie comme une proposition

Le modèle peut mal interpréter un objectif, suivre une consigne injectée dans un document ou produire un appel d’outil plausible mais interdit. Sa sortie ne doit donc jamais constituer, à elle seule, une autorisation de sécurité.

• Menace : détournement de l’objectif, injection de consignes, divulgation du contexte ou décision prise malgré une incertitude non signalée.
• Contrôle : séparer les instructions de confiance des données externes, imposer un schéma de sortie strict et refuser tout paramètre inconnu. Le modèle peut proposer un plan ; une politique déterministe extérieure décide si l’action est autorisée.
• Preuve attendue : un corpus versionné de tests adversariaux montrant que les contenus non fiables ne remplacent pas les règles du système et que les sorties non conformes sont rejetées.
• Condition d’arrêt : interrompre l’exécution si l’objectif change, si les validations échouent de manière répétée ou si le modèle réclame un secret, un outil ou une ressource hors de son mandat.

Renforcer le modèle ne suffit pas. L’analyse d’Anthropic distingue quatre composants — modèle, harnais d’exécution, outils et environnement — et précise qu’aucune ligne de défense ne garantit à elle seule une protection contre l’injection de consignes.

2. Orchestrateur : contenir la propagation entre agents

L’orchestrateur peut transformer une erreur locale en défaillance systémique s’il relaie sans contrôle un résultat, une mémoire ou une délégation. Chaque agent doit disposer d’une identité propre, d’un mandat borné et d’un budget d’exécution ; une identité commune au système ne permet pas d’attribuer ni de restreindre correctement les actions.

• Menace : escalade par délégation, boucle entre agents, falsification d’un message interne ou contamination d’une mémoire partagée.
• Contrôle : authentifier les échanges, vérifier leur schéma et leur provenance, puis limiter la profondeur des délégations, leur durée, leur coût et leur nombre d’appels. Une délégation conserve ou réduit les privilèges ; elle ne les élargit jamais implicitement.
• Preuve attendue : une trace reliant l’exécution, l’agent parent et l’agent délégué, accompagnée de tests montrant qu’un agent compromis ne peut pousser un autre agent au-delà de sa frontière de confiance.
• Condition d’arrêt : bloquer la chaîne lors d’un cycle, d’un dépassement de budget, d’un message non authentifié ou d’une demande dont la provenance ne peut être reconstituée.

La fiche de sécurité de l’OWASP préconise des frontières de confiance entre agents, la validation de leurs communications, l’isolation de leurs environnements et des coupe-circuits contre les défaillances en cascade.

3. Outils : appliquer le moindre privilège à chaque action

Un agent autorisé à lire un rapport n’a pas besoin d’un accès générique au système de fichiers ; un agent chargé de préparer un courriel n’a pas besoin de pouvoir l’envoyer. Exposez des opérations étroites et orientées métier plutôt qu’un terminal, une clé d’administration ou une API complète.

• Menace : suppression, exfiltration, modification d’un système externe ou détournement d’un outil légitime au moyen de paramètres dangereux.
• Contrôle : attribuer une identité de service distincte à chaque agent, avec des autorisations limitées aux opérations et ressources nécessaires. Séparer lecture, préparation et exécution, puis faire appliquer ces règles par le courtier d’outils au moment de chaque appel.
• Preuve attendue : une matrice agent-outil-opération-ressource et des journaux indiquant l’identité, la version de la politique, les paramètres expurgés des secrets, la décision et l’effet obtenu.
• Condition d’arrêt : suspendre l’agent et révoquer son autorisation s’il tente un outil hors liste, modifie un paramètre après approbation ou répète des appels refusés.

Dans un exemple conditionnel, un agent d’analyse peut seulement lire un répertoire de rapports, tandis qu’un agent de publication ne reçoit qu’une opération de création de brouillon. Aucun des deux n’hérite des droits du compte humain ayant lancé la tâche.

4. Environnement : contenir les effets et les données

Les permissions applicatives ne suffisent pas si le processus voit les secrets de l’hôte, le réseau interne ou les données d’une autre session. Séparez les environnements selon le niveau de confiance des entrées, la sensibilité de la mission et les ressources réellement nécessaires.

• Menace : évasion vers l’hôte, mouvement latéral, fuite entre sessions, persistance d’un contenu empoisonné ou accès réseau non prévu.
• Contrôle : exécuter sous un compte non privilégié, limiter le système de fichiers, injecter les secrets seulement au moment utile et autoriser explicitement les destinations réseau. Séparer la production, les tests et le traitement des contenus externes.
• Preuve attendue : une configuration d’isolation versionnée, un inventaire des montages et sorties réseau, ainsi qu’un test démontrant qu’une ressource interdite reste inaccessible.
• Condition d’arrêt : mettre l’environnement en quarantaine lors d’une tentative d’évasion, d’une connexion inattendue, d’un accès à un secret non requis ou d’une hausse anormale des fichiers manipulés et des requêtes.

Les journaux doivent permettre de reconstituer les effets sans recopier les secrets ni les données personnelles en clair. Conservez l’identité de l’agent, l’événement, la décision de politique, la référence de la ressource et le résultat ; empêchez les agents observés de modifier ces traces.

5. Intervention humaine : valider l’intention et garder la coupure

Une demande vague telle que « continuer » ne permet pas une validation éclairée. L’opérateur doit voir l’action exacte, sa cible, son effet, les données transmises et les possibilités de retour arrière ; l’autorisation doit être liée à ces paramètres, expirer et devenir invalide au moindre changement.

• Menace : approbation routinière, présentation trompeuse, action irréversible ou absence d’un opérateur compétent pendant un incident.
• Contrôle : exiger une validation pour les écritures externes, suppressions, paiements, changements de droits et communications publiques. Pour les opérations les plus critiques, séparer la personne qui demande l’autonomie de celle qui autorise l’action.
• Preuve attendue : un enregistrement associant l’approbateur, les paramètres présentés, la durée de validité, la décision et le résultat, complété par un exercice de suspension et de reprise.
• Condition d’arrêt : refuser l’exécution lorsque l’autorisation a expiré, que la cible diffère, que l’effet dépasse celui annoncé ou qu’aucun approbateur compétent n’est disponible.

Le mécanisme d’arrêt doit se trouver hors du chemin contrôlé par les modèles : il désactive l’orchestrateur, révoque les identités, ferme les sorties réseau et préserve les traces. L’autonomie ne doit être étendue qu’après démonstration de ces opérations et d’une restauration vers un état connu, sans relance automatique des tâches suspendues.

À lire aussi:

• QUASA lance une plateforme entièrement localisée en français, élargissant son hub d’économie des créateurs Web3 dans le monde francophone