Sécuriser un agent IA : permissions et garde-fous

Sécuriser un agent IA consiste à limiter ce qu’il peut lire, modifier et transmettre, puis à contrôler ses actions sensibles avant leur exécution. Les protections doivent être appliquées par les outils, les comptes et l’environnement d’exécution : des instructions écrites au modèle ne suffisent pas. Permissions minimales, secrets séparés, bac à sable, validation humaine et journalisation forment des couches complémentaires.

Partir des conséquences possibles

Un agent qui prépare une réponse commerciale n’a pas besoin des mêmes accès qu’un agent qui modifie un serveur. Commencez par décrire la tâche, les données nécessaires et les conséquences d’une erreur : document divulgué, destinataire incorrect, fichier écrasé, dépense engagée ou service indisponible.

Distinguez également les sources consultées. Une demande provenant de l’utilisateur autorisé, une pièce jointe reçue et une réponse d’outil n’ont pas la même valeur. Le contenu trouvé pendant une tâche doit rester une donnée à examiner, même lorsqu’il ressemble à une consigne technique.

L’OWASP distingue les excès de fonctionnalités, de permissions et d’autonomie dans sa présentation du risque d’autonomie excessive. Cette séparation permet de poser des questions concrètes : faut-il proposer cet outil, lui donner ces droits et laisser l’agent l’utiliser sans contrôle ?

Écrivez une fiche de périmètre avant de connecter des comptes :

objectif autorisé et résultat attendu ;
dossiers, applications et catégories de données accessibles ;
opérations permises, soumises à validation ou interdites ;
personne responsable et procédure d’arrêt ;
conditions de reprise après une erreur.

Le diagnostic de sécurité des agents peut aider à repérer les points à examiner. Il ne remplace pas la vérification des droits effectivement accordés dans votre environnement.

Appliquer le moindre privilège à chaque outil

Le moindre privilège consiste à donner uniquement les droits nécessaires à la tâche, pendant la durée utile. Appliquez-le aux fichiers, aux comptes applicatifs, aux accès réseau et aux opérations disponibles dans les outils.

Séparez consultation, préparation et exécution. Pour traiter des factures, l’agent peut consulter un ensemble limité de documents et produire des brouillons sans pouvoir modifier les coordonnées bancaires. Un outil métier ciblé permet de mieux encadrer cette tâche qu’un accès général à un terminal.

Les restrictions doivent être contrôlées du côté du service exécutant. Un paramètre proposé par le modèle, tel qu’un identifiant de client, ne prouve pas que l’utilisateur est autorisé à consulter ce client.

Usage	Lecture autorisée	Écriture autorisée	Validation à prévoir
Résumer des documents	Dossier sélectionné	Nouveau résumé dans un espace dédié	Avant diffusion externe
Préparer des relances	Factures et contacts concernés	Brouillons de messages	Avant envoi
Corriger du code	Copie du dépôt concerné	Branche de travail dédiée	Avant publication ou déploiement
Analyser un incident	Journaux nécessaires	Rapport d’analyse	Avant modification du service

Ce tableau propose une politique de départ, à adapter. Vérifiez aussi les chemins indirects : un outil de lecture capable d’appeler librement une adresse externe ouvre un canal de sortie. Un terminal peut contourner la séparation entre plusieurs outils spécialisés s’il possède leurs identifiants.

Enfin, retirez les anciennes connexions. Un outil abandonné pendant un essai ne doit pas rester disponible par défaut.

Séparer les identités et protéger les secrets

Prévoyez une identité dédiée à l’agent ou une délégation liée à l’utilisateur qui déclenche la tâche. Évitez de lui transmettre un compte personnel disposant d’accès administrateur. Vous devez pouvoir suspendre l’automatisation sans bloquer tous les usages humains.

Une clé API, un jeton d’accès, un cookie de session ou une clé privée constitue un secret. Ne les placez ni dans les instructions, ni dans les exemples, ni dans la mémoire de l’agent. Le service chargé d’exécuter l’outil devrait récupérer l’identifiant nécessaire sans en renvoyer la valeur au modèle.

La documentation OWASP sur la gestion des secrets détaille leur contrôle d’accès, leur rotation et leur révocation. Pour votre agent, associez chaque secret à un propriétaire, un usage, un périmètre et une procédure de remplacement.

Un fichier de configuration exclu du dépôt reste lisible par un processus qui possède les droits correspondants. Une variable d’environnement reste également accessible au programme auquel elle est transmise. Ces mécanismes de distribution ne créent pas une séparation avec un terminal exécuté sous la même identité.

Dans un scénario de préparation de relances, le service d’envoi peut conserver le secret de messagerie et n’accepter qu’une opération structurée après validation. Le processus chargé de lire les factures n’a alors aucune raison de posséder cet identifiant.

Si un secret apparaît dans une conversation ou une trace, supprimez les copies accessibles, mais révoquez aussi l’identifiant à sa source.

Choisir un bac à sable selon les accès nécessaires

Un bac à sable limite les ressources accessibles à un programme. Son efficacité dépend de sa configuration : dossiers partagés, privilèges, réseau, périphériques et services accessibles depuis l’environnement.

Préparez un espace de travail jetable contenant uniquement les fichiers utiles. Montez les sources en lecture seule lorsque la tâche le permet et réservez un dossier distinct aux résultats. Écartez les répertoires personnels, les identifiants de production et les sessions de navigateur habituelles.

Environnement	Séparation obtenue	Point à vérifier	Usage envisageable
Compte système dédié	Droits et fichiers distincts	Groupes et ressources partagés	Tâches locales encadrées
Conteneur restreint	Environnement de processus et fichiers délimité	Noyau partagé, montages et privilèges	Exécution reproductible
Machine virtuelle dédiée	Système invité séparé	Dossiers partagés et réseau	Code moins fiable ou besoins d’isolation renforcés

La documentation sur la sécurité des conteneurs explique les risques associés au démon, aux montages et aux capacités système. Un conteneur privilégié, ou capable de contrôler le moteur de conteneurs de l’hôte, élargit fortement les accès disponibles.

Vérifiez les limites depuis l’intérieur : tentative de lecture hors périmètre, écriture dans un dossier interdit et accès à un service non autorisé. Le test doit montrer un refus effectif.

L’article Faire tourner un agent IA dans un bac à sable développe l’angle pratique. Ici, le critère demeure la séparation obtenue, indépendamment du nom donné à l’environnement.

Contrôler les sorties réseau et les données transmises

Une interdiction d’écriture locale ne protège pas une donnée que l’agent peut envoyer ailleurs. Examinez les canaux disponibles : requêtes web, messagerie, téléversement, navigation, synchronisation et collecte de traces.

Pour chaque destination, définissez les données qu’elle peut recevoir. Une autorisation de joindre le fournisseur du modèle implique de déterminer quels extraits seront intégrés aux requêtes. Une autorisation de consulter un site ne devrait pas permettre d’y transmettre librement le contenu de documents internes.

Privilégiez une liste de destinations nécessaires, appliquée hors du processus contrôlé par l’agent. Si un outil accepte une adresse arbitraire, vérifiez aussi son comportement face aux redirections et aux adresses du réseau interne. Une adresse publique apparente ne suffit pas à définir la destination finale.

La présentation Microsoft des responsabilités de sécurité des agents souligne notamment les risques liés aux contenus non fiables et aux délégations trop larges. L’opérateur doit relier ces risques aux connexions qu’il autorise réellement.

Réduisez les données avant transmission : champs inutiles retirés, documents sélectionnés, pièces jointes limitées. Le masquage automatique peut aider, mais vérifiez son résultat sur vos formats réels.

Dans un exemple fictif de support client, transmettre le message concerné et la référence du dossier peut suffire. Donner l’historique complet du client augmente l’exposition sans nécessairement améliorer la résolution de la demande.

Traiter l’injection de prompt comme un risque d’action

Une injection de prompt cherche à faire suivre à l’agent des instructions placées dans le contenu qu’il traite. Le support peut être un courriel, un document, une page web, une description d’outil ou un résultat de recherche.

Le risque devient concret lorsque ces instructions déclenchent une action : transmettre un fichier, changer un destinataire ou exécuter une commande. La réussite d’une tâche ordinaire ne démontre donc pas que ses frontières résistent à un contenu hostile.

Le glossaire OWASP consacré à l’injection de prompt décrit les injections directes et indirectes ainsi que les limites des protections. Des instructions explicites et des filtres peuvent réduire le risque, sans garantir que le modèle ignorera toutes les tentatives.

Prévoyez plutôt plusieurs obstacles indépendants. Un document peut demander un envoi, mais l’outil d’envoi reste indisponible. Un résultat peut proposer un autre dossier, mais le service refuse les chemins hors périmètre. Une page peut annoncer une urgence, mais elle ne peut pas accorder de nouveaux droits.

Examinez également les résultats affichés. Un lien ou une ressource distante générée à partir de données sensibles peut devenir un canal de fuite selon le comportement de l’interface.

L’article Sécurité des agents IA : risques et protections propose une vue transversale. Pour l’exploitation quotidienne, rattachez chaque risque à un contrôle observable et à une personne capable d’intervenir.

Encadrer les serveurs MCP, les extensions et les dépendances

Brancher un connecteur ajoute du code, des dépendances et parfois un service distant au périmètre de confiance. Avant installation, vérifiez sa provenance, son mainteneur, ses fonctions et les permissions demandées.

Consignez ce qui a été approuvé : source du paquet, révision retenue, paramètres, outils exposés et destinations contactées. Une mise à jour doit permettre de revoir ces éléments. L’évolution du code peut modifier le périmètre même lorsque le nom du connecteur reste identique.

Pour un serveur local, examinez les droits du processus lancé. Pour un serveur distant, examinez aussi l’authentification, les données transmises et la séparation entre utilisateurs. Dans les deux cas, masquer un outil dans une interface ne remplace pas son contrôle d’accès.

Les bonnes pratiques de sécurité officielles de MCP abordent notamment la validation des jetons, leur destination et les risques de délégation. Un serveur ne doit pas accepter aveuglément un jeton destiné à un autre service. L’accès à une session ou à un état doit également rester lié à l’identité autorisée.

Le guide Choisir un serveur MCP complète ces critères, et l’annuaire des serveurs MCP facilite le repérage des projets. Une fiche ou une popularité élevée ne vaut pas audit.

Pour une extension destinée à lire des documents, demandez pourquoi elle réclame aussi un terminal ou un accès complet au compte. Si cette portée ne peut pas être réduite, choisissez une autre intégration.

Concevoir une validation humaine qui porte sur l’action exacte

Une validation utile montre ce qui va se produire : opération, cible, données concernées, destination et effet attendu. Une demande générale d’autoriser la poursuite de la tâche fournit trop peu d’informations pour décider.

Pour un message, affichez le contenu final, les destinataires et les pièces jointes. Pour une modification de fichiers, présentez les différences et les chemins concernés. Pour une opération métier, exposez les paramètres qui déterminent ses conséquences.

L’approbation doit être liée à cette proposition précise. Si l’agent modifie ensuite le destinataire, la pièce jointe ou l’opération, une nouvelle validation devient nécessaire. Le service exécutant doit vérifier cette correspondance.

La fiche OWASP sur la sécurité des agents recommande notamment de séparer décision et exécution pour les opérations irréversibles. Organisez cette séparation dans l’application, avec un refus par défaut lorsqu’une approbation requise manque ou expire.

Évitez aussi la fatigue de validation. Réservez les demandes aux transitions qui changent le risque : publication, envoi externe, suppression, modification des accès ou engagement financier. Les lectures ordinaires peuvent rester automatiques dans un périmètre déjà défini.

Prévoyez enfin un refus exploitable. L’agent doit pouvoir enregistrer un brouillon, expliquer le blocage ou demander une information manquante. Il ne devrait pas chercher un autre outil pour réaliser l’opération refusée.

Journaliser les opérations sans constituer une réserve de secrets

Les journaux doivent permettre de reconstruire les actions utiles à l’enquête : demande initiale, identité, outil sollicité, décision d’autorisation, approbation éventuelle, résultat et erreur. Distinguez une action proposée d’une action effectivement exécutée.

Utilisez un identifiant de tâche commun aux composants. Conservez les références des objets concernés et les paramètres nécessaires à la compréhension, en masquant les valeurs sensibles. Le texte produit par le modèle ne constitue pas, à lui seul, une preuve d’exécution.

La documentation OWASP sur la journalisation précise les informations à enregistrer, celles à exclure et les protections à appliquer. Évitez notamment les jetons d’accès et les mots de passe. Les documents complets et les données personnelles demandent également une justification avant conservation.

Protégez les traces contre la modification par l’agent. Définissez qui peut les consulter, leur durée de conservation et la manière de les supprimer. Testez aussi le comportement du système lorsque la collecte échoue : une action sensible doit suivre une politique explicite.

Créez des alertes sur des événements compréhensibles : refus répétés, nouvelle destination, changement de permissions ou activité poursuivie après un arrêt. Chaque alerte doit avoir un destinataire et une procédure de traitement.

Le guide Surveiller un agent IA en production approfondit l’organisation des traces et des alertes. La collecte n’apporte une protection que si quelqu’un peut l’exploiter.

Déployer progressivement et tester les refus

Avant le démarrage, disposez d’un environnement d’essai, de données fictives, d’un responsable et d’un moyen d’interrompre les tâches. Les essais doivent vérifier les limites autant que les résultats attendus.

Commencez en lecture seule. Vérifiez les objets consultés et les informations transmises aux services externes.
Autorisez la préparation. L’agent produit des brouillons ou des modifications dans un espace séparé.
Testez les blocages. Introduisez un document demandant une fuite, un chemin interdit et une destination non autorisée.
Ajoutez une exécution contrôlée. Vérifiez le refus sans approbation et le blocage lorsque les paramètres changent après validation.
Élargissez après examen. Accordez un accès supplémentaire pour un besoin identifié, puis répétez les essais concernés.

Testez également l’annulation pendant une tâche, la révocation d’un compte et l’isolation entre utilisateurs. Un agent ne doit pas retrouver les documents d’une autre session grâce à une mémoire partagée mal délimitée.

Pour les opérations susceptibles d’être répétées après une erreur, prévoyez une protection contre les doublons. Un délai dépassé ne prouve pas qu’un envoi ou une modification a échoué.

Conservez les résultats attendus de ces essais. Rejouez les scénarios concernés après un changement de modèle, d’instructions, de connecteur ou de permissions. Une configuration validée reste un état à maintenir, avec ses dépendances et ses limites connues.

Problèmes fréquents et préparation de l’incident

L’agent réclame toujours davantage de droits. Reprenezz le besoin métier et l’outil utilisé. Un refus peut révéler une permission manquante, mais aussi une tentative d’action hors périmètre. Élargissez uniquement l’accès identifié comme nécessaire.

Le bac à sable voit des fichiers personnels. Examinez les montages, les répertoires hérités et les identifiants disponibles. Recréez un environnement minimal, puis vérifiez l’absence d’accès depuis le processus de l’agent.

Les approbations deviennent illisibles. Réduisez la taille des opérations présentées et affichez leurs conséquences concrètes. Une longue chaîne d’actions devrait permettre de repérer les étapes sensibles avant de donner un accord.

Les traces contiennent des informations confidentielles. Corrigez la collecte à sa source et traitez les copies existantes. Un filtre ajouté à l’interface de consultation ne retire pas les données déjà stockées.

Prévoyez une procédure d’incident accessible hors de l’agent. Elle doit permettre de suspendre les tâches, couper les connexions, révoquer les accès et préserver les preuves utiles. Attribuez chaque opération à un responsable.

Après un incident, vérifiez les actions réellement exécutées et les données accessibles pendant la période concernée. Restaurez depuis une source connue, corrigez le contrôle défaillant et rejouez le scénario avant la reprise. Le résumé rédigé par l’agent peut aider à s’orienter, mais doit être confronté aux traces des services.

Avant la mise en service, vérifiez les points suivants :

Les droits effectifs correspondent au périmètre écrit.
Les secrets et les données inutiles sont absents du contexte.
Les restrictions de fichiers et de réseau ont été testées.
Les validations portent sur les paramètres effectivement exécutés.
Les journaux permettent une enquête sans exposer les identifiants.
L’arrêt, la révocation et la reprise ont un responsable désigné.

Pages liées

Questions fréquentes

Un agent IA qui fonctionne en local est-il sécurisé ?

Le fonctionnement local réduit certains transferts vers un hébergeur, mais ne définit pas les droits du programme. Un agent local peut encore lire vos documents, utiliser vos sessions ouvertes ou transmettre des données par ses outils. Vérifiez séparément l’hébergement du modèle, les connecteurs et les accès système.

Peut-on mettre une clé API dans les instructions d’un agent ?

Évitez cette pratique : les instructions deviennent une copie supplémentaire du secret, susceptible de circuler dans les historiques et les traces. Faites utiliser l’identifiant par le service qui exécute l’outil. Si une clé a été exposée, révoquez-la auprès du fournisseur.

Faut-il approuver chaque action d’un agent IA ?

Une validation systématique peut rendre la supervision difficile à maintenir. Définissez des opérations courantes autorisées dans un périmètre précis, puis imposez une approbation pour les changements sensibles. Une autorisation générale de terminer une tâche ne doit pas valoir accord pour toutes ses conséquences.

Un bac à sable empêche-t-il les fuites de données ?

Il peut limiter les fichiers et les processus accessibles, mais une fuite reste possible par un canal autorisé. Un environnement isolé qui contient des données privées et peut communiquer librement conserve un risque d’exfiltration. Le filtrage des sorties et la limitation des données restent nécessaires.

Que faire si un agent a envoyé des informations confidentielles ?

Suspendez son exécution et bloquez ses accès concernés avant de reprendre la tâche. Conservez les traces utiles, identifiez les informations transmises et révoquez les identifiants exposés. Faites ensuite examiner l’incident par les responsables compétents selon la nature des données.

Sécuriser un agent IA : permissions, secrets, bac à sable, validation humaine, journalisation