Une entreprise demande à un agent IA de préparer une réponse à un client. Elle lui ouvre la messagerie et le dossier commercial. Pour gagner du temps, elle ajoute aussi la possibilité d’envoyer des courriels et de créer des liens de partage. Une demande de rédaction vient de s’accompagner d’un pouvoir de transmission.
Cette situation hypothétique ressemble à l’arrivée d’un assistant auquel on remettrait, le même matin, un badge, une délégation de signature et les clés des archives. Chacun de ces accès peut avoir une utilité. Leur réunion mérite une décision explicite. Lire un document, en transmettre le contenu et autoriser d’autres personnes à le consulter sont des pouvoirs distincts.
Deux publications récentes éclairent cette question. Le 27 août 2026, le NIST américain examine les mauvaises pratiques d’identité et d’autorisation qui accompagnent le déploiement des agents. Le 20 août, le NCSC britannique propose des conseils opérationnels provisoires sur leur encadrement. Leur point commun : organiser les accès, les limites et les moyens d’intervention autour du modèle. Analyse du NIST, recommandations du NCSC.
Une identité pour attribuer les actions
Lorsqu’un agent utilise les identifiants d’un salarié, les opérations peuvent apparaître sous le nom de ce salarié dans les applications concernées. Pour comprendre un incident, il faudra pourtant distinguer la demande humaine, l’action du logiciel et les autorisations dont celui-ci disposait.
Le NIST recommande de traiter les agents comme des entités identifiables, avec leurs propres moyens d’authentification et des droits rattachés à la personne ou au système qui les mandate. Il pointe aussi les clés statiques conservées trop longtemps et les accès trop larges. NIST, identité et autorisation des agents.
Dans notre exemple, le mandat pourrait se limiter au dossier du client concerné, pour la durée de la préparation. L’accès à l’ensemble des archives commerciales demanderait une justification supplémentaire. L’OWASP recommande précisément de réduire les fonctions disponibles et les permissions des systèmes auxquels les agents se connectent. Le contrôle doit aussi exister dans l’application qui détient les données. OWASP, Excessive Agency.
Un document peut tenter de prendre la parole
Un agent qui consulte un courriel, une page web ou une pièce jointe rencontre du texte fourni par des tiers. Ce contenu peut contenir une consigne destinée à détourner son travail. C’est le principe de l’injection indirecte de prompt : une instruction hostile se présente dans les données que le modèle doit traiter. Le NCSC souligne la difficulté de maintenir une séparation fiable entre ces données et les instructions légitimes. NCSC, analyse de l’injection de prompt.
Poursuivons le scénario hypothétique. Un courriel demande à l’assistant de joindre à sa réponse un document interne sans rapport avec la demande du client, sous prétexte de terminer une vérification. Pour provoquer une fuite, cette tentative doit encore tromper le modèle, atteindre le document et franchir les contrôles de transmission. La présence d’un texte malveillant ne démontre donc ni une action réussie ni une exfiltration.
La combinaison mérite cependant attention : accès à des informations privées, exposition à du contenu non fiable et possibilité de communiquer vers l’extérieur. Le blog officiel MCP insiste sur l’examen des outils réunis dans une même session. Un outil de consultation et un outil d’envoi peuvent former ensemble un chemin de divulgation. MCP, analyse des annotations et des combinaisons d’outils.
Le sujet ne se réduit pas à la qualité des consignes. Le projet de recherche CaMeL explore une séparation des flux de contrôle et de données autour du modèle, accompagnée de restrictions sur les échanges autorisés. D’autres travaux étudient plusieurs architectures et leurs compromis entre utilité et sécurité. Ces recherches étayent des mécanismes de défense dans des cadres définis ; elles ne certifient pas la sécurité de tous les agents disponibles. CaMeL, Design Patterns for Securing LLM Agents.
MCP relie les outils et pose plusieurs frontières
Le Model Context Protocol, ou MCP, permet à une application d’IA de découvrir et d’appeler des outils exposés par des serveurs : consulter une base, interroger un service ou effectuer une opération. La spécification prévoit notamment la validation des entrées et les contrôles d’accès côté serveur. Elle recommande aussi de présenter les paramètres des opérations sensibles à l’utilisateur. Leur mise en œuvre doit être vérifiée dans le logiciel choisi. Spécification MCP, outils.
Une annotation comme readOnlyHint décrit le comportement annoncé d’un outil. Elle ne retire aucun droit au programme qui l’exécute. Un serveur non fiable peut fournir une description trompeuse ; un outil qui lit des données peut aussi les rendre accessibles à d’autres composants de la session. L’indication aide à comprendre l’outil, tandis que les permissions effectives et les restrictions réseau déterminent ses possibilités. MCP, portée et limites des annotations.
La connexion à un serveur distant ajoute une autre frontière. Le cadre d’autorisation MCP examiné ici, dans sa version du 25 novembre 2025, concerne les transports HTTP lorsqu’une autorisation est mise en œuvre. Il exige de vérifier que le jeton présenté est destiné au serveur qui le reçoit. Il interdit de transmettre tel quel ce jeton à une API en aval ; l’accès à cette API relève d’une autorisation distincte. Ce cadre n’est pas celui des serveurs locaux communiquant par l’entrée et la sortie standard, dites stdio. MCP, autorisation.
Installer un serveur MCP local revient par ailleurs à exécuter un logiciel. Sa provenance, sa commande de lancement et ses accès aux fichiers ou au réseau comptent. Les recommandations MCP prévoient un consentement explicite à l’exécution et un environnement restreint. Cette dépendance logicielle s’examine aussi dans une revue du fournisseur et de ses accès. MCP, sécurité des serveurs locaux.
Un mandat précis, des permissions vérifiables
« Préparer une réponse client » décrit un résultat attendu. L’organisation peut le traduire en un ensemble limité d’opérations : lire les pièces sélectionnées, produire un brouillon, puis soumettre un envoi déterminé à validation. L’OWASP recommande des fonctions spécialisées et des autorisations minimales, afin de réduire les conséquences d’une action indésirable. Un outil général d’exécution de commandes exige un encadrement plus large qu’une fonction consacrée à une seule opération. OWASP, réduction des fonctions et des permissions.
Le schéma suivant propose une politique pour notre scénario. Il ne décrit ni une fonction automatique de MCP ni une règle universelle : chaque ligne suppose un contrôle effectivement appliqué par les applications et l’environnement d’exécution.
Une vérification utile consiste à essayer, dans un périmètre d’essai isolé, de lire un dossier hors périmètre, d’envoyer à un destinataire non approuvé et d’utiliser un accès retiré. Il faut observer où l’opération est bloquée. Un refus formulé dans la conversation renseigne sur le comportement du modèle ; le refus du service destinataire démontre une restriction sur l’action testée. Ces observations restent limitées à la configuration et aux essais réalisés.
La validation humaine doit porter sur une action lisible
Le NIST relève un risque de fatigue lorsque les demandes d’autorisation se multiplient. L’utilisateur peut finir par accepter machinalement pour laisser avancer le travail. NIST, limites des validations répétées.
Pour notre réponse client, une validation utile montrerait le destinataire, le texte final, les pièces jointes et la portée du partage. Elle devrait intervenir avant la transmission. La spécification MCP recommande d’afficher les entrées des outils avant leur invocation afin de prévenir les divulgations accidentelles ou malveillantes. MCP, considérations de sécurité des outils.
L’analyse des architectures de défense pose aussi la question de la place laissée au contrôle humain et des restrictions imposées au déroulement de la tâche. Le compromis dépend de l’usage. Une préparation autonome dans un dossier limité peut être acceptable, avec un contrôle distinct au moment de transmettre son résultat. C’est une décision d’organisation à traduire en mécanismes testables. Recherche sur les architectures de protection des agents.
Retirer les accès fait partie de la délégation
Le NCSC recommande de pouvoir interrompre rapidement l’activité d’un agent et ses communications. Cette capacité peut dépasser l’arrêt du seul processus visible : elle concerne aussi les connexions et les composants qui l’entourent. NCSC, arrêt d’urgence.
Pour les accès OAuth, la révocation possède ses propres modalités. La RFC 7009 prévoit l’invalidation des jetons et reconnaît de possibles délais de propagation entre serveurs. Elle distingue aussi le traitement des jetons d’accès et de renouvellement. La présence d’un bouton « déconnecter » ne permet donc pas, à elle seule, de conclure que toutes les possibilités d’accès ont disparu. IETF, OAuth 2.0 Token Revocation.
Dans notre scénario, l’essai de retrait consisterait à couper l’autorisation puis à vérifier que la consultation et l’envoi deviennent impossibles par les chemins concernés. Il faudrait également examiner les partages déjà créés. Une révocation bloque des accès futurs selon sa portée ; elle ne récupère pas un document déjà transmis. La reprise en main exige de distinguer l’arrêt de l’agent, la fermeture des accès et le traitement des actions accomplies.
Des traces pour comprendre, sans recopier tous les secrets
Une trace exploitable relie une action à une identité, une heure, une ressource, une décision d’autorisation et un résultat. L’OWASP recommande de conserver le contexte nécessaire à l’analyse des événements, tout en évitant l’enregistrement direct des mots de passe, jetons et informations sensibles. Il préconise également de protéger les journaux contre les modifications et de limiter leur consultation. OWASP, journalisation.
Pour l’envoi commercial, on chercherait à rapprocher la validation enregistrée et l’événement produit par la messagerie : destinataire, pièces transmises, succès ou échec. Le récit de l’agent constitue un élément à confronter aux traces des applications. Si elles sont incomplètes, la conclusion doit le rester. Notre analyse sur les fuites de données et les faits à établir développe cette distinction entre tentative, accès et sortie effective de données.
Une autonomie à dimensionner tâche par tâche
La question opérationnelle consiste à définir les actions autorisées, leurs conditions et les conséquences acceptables d’un échec. Le NCSC invite à proportionner l’autonomie à l’usage et à combiner surveillance, isolation et contrôles techniques. Ses conseils d’août 2026 restent présentés comme provisoires, dans un domaine en évolution. NCSC, gestion du risque agentique.
Pour la tâche commerciale décrite ici, la décision peut tenir dans un mandat court : un dossier délimité, un brouillon librement préparé, un envoi précisément validé, des accès retirables et des opérations retraçables. Cette proposition illustre une méthode ; son efficacité dépend de la réalité des contrôles et des tests.
Les sources consultées établissent des mécanismes de risque, des exigences de protocole et des pistes de protection. Elles ne permettent pas de chiffrer la probabilité d’un incident dans une entreprise donnée. Cette évaluation nécessite de connaître ses outils, ses données, ses permissions et ses pratiques. Déléguer une tâche à un agent suppose de pouvoir expliquer les pouvoirs qu’on lui confie, puis de vérifier qu’ils restent dans les limites décidées.