Sécurité des données des agents d'IA : que se passe-t-il lorsque les agents se connectent aux systèmes ?

L'IA passe de la génération de réponses à l'exécution d'actions dans des systèmes réels. Ce changement modifie la question centrale de la sécurité. Il ne suffit plus de se demander si le modèle est précis ou digne de confiance. Il faut aussi se demander comment le système environnant réagit lorsque le modèle interprète mal une instruction, reçoit des entrées malveillantes ou se voit conférer plus d'autorité que la tâche ne l'exige. Des protocoles tels que MCP facilitent la création de connexions entre agents et systèmes ; ils rendent aussi la conception de ces connexions impossible à ignorer.

La connexion d'un agent d'IA à un système métier peut exposer différentes catégories de données à plusieurs composants, notamment l'hôte d'IA, le serveur d'outils, le fournisseur d'identité et l'application en aval. MCP définit la façon dont les éléments de cette connexion communiquent, mais ne détermine pas quelles données chaque implémentation stocke, expose ou conserve.

Des réponses aux conséquences

La connexion d'un agent ne crée pas un seul périmètre de confiance. Elle crée une chaîne de périmètres : l'hôte d'IA interprète la requête, un client de protocole sélectionne une capacité, un serveur d'outils valide et traduit l'appel, un fournisseur d'identité établit qui agit, et le système en aval applique les autorisations et enregistre le résultat. MCP standardise une partie de cette communication, mais ne sécurise pas à lui seul l'ensemble de la chaîne. La sécurité dépend des décisions prises à chaque couche.

La première génération d'IA générative largement utilisée produisait surtout des éléments destinés à être examinés par des humains : texte, images, résumés et code. De plus en plus, les agents pilotent des outils à la place. Ils envoient des messages, modifient des enregistrements, déclenchent des flux de travail, déplacent de l'argent et contrôlent des processus physiques. Une réponse plausible mais incorrecte est un désagrément ; une action plausible mais incorrecte peut avoir une conséquence immédiate.

Des standards comme MCP rendent les outils découvrables et appelables via des interfaces structurées. C'est une amélioration importante par rapport au screen scraping ou aux intégrations improvisées, mais la structure seule ne constitue pas une stratégie de sécurité. Le concepteur de l'outil décide toujours quelles actions existent, quelles entrées elles acceptent, quelle identité elles utilisent et quelles preuves elles renvoient.

Nous avons rencontré cette distinction en développant le serveur MCP d'ezeep. L'impression rend le problème tangible, car la décision d'un agent peut se traduire par un résultat physique en quelques secondes. La leçon, toutefois, s'applique à tout système opérationnel.

Où vont réellement les données

« Le modèle ne voit jamais votre mot de passe » est une formule utile, mais elle ne décrit pas complètement le flux de données. Une connexion d'agent typique implique plusieurs catégories d'informations : des identifiants gérés par une couche d'authentification, les arguments de l'outil construits à partir de la requête de l'utilisateur, les résultats opérationnels renvoyés au modèle, les charges utiles métier transférées au service en aval, et les journaux conservés par un ou plusieurs composants. Le modèle reçoit en général la conversation, les descriptions des outils disponibles, les arguments nécessaires pour appeler l'outil sélectionné et le résultat renvoyé par cet outil.

Ces catégories ne suivent pas nécessairement le même chemin. OAuth peut garder un mot de passe et un jeton Bearer en dehors du contexte du modèle, tandis que le résultat de l'outil expose toujours des noms de clients, des emplacements d'appareils, des valeurs financières ou des métadonnées internes du système. Un document peut transiter directement entre des services alors que son nom de fichier, sa destination et son statut apparaissent dans la conversation. L'hôte d'IA, le serveur d'outils, le fournisseur d'identité et le système cible peuvent également avoir des stratégies de journalisation et de conservation des données différentes.

Il n'existe donc aucune affirmation générale et responsable du type « l'IA ne voit pas les données ». Les bonnes questions sont : quelles données chaque couche reçoit, pourquoi elle en a besoin, combien de temps elle les conserve et si l'utilisateur comprend cette limite. Notre propre implémentation de MCP nous fournit des exemples concrets de ces distinctions, mais le problème de conception concerne tous les systèmes connectés à un agent.

L'identité détermine le rayon d'impact

Un agent ne devrait pas disposer d'une autorité indépendante. Un agent peut agir via une identité de service partagée ou au nom d'un utilisateur individuel. Aucun des deux modèles n'est universellement correct. Une identité partagée convient aux flux de travail non supervisés, mais chaque action hérite de l'étendue de ce compte. L'autorisation par utilisateur offre un accès plus restreint et une attribution plus claire, mais exige que chaque utilisateur s'authentifie et que l'application gère correctement les sessions individuelles. L'interprétation d'une requête par l'agent ne doit jamais remplacer l'autorisation appliquée par le système cible.

La décision d'ingénierie importante n'est pas de savoir quel modèle paraît le plus sécurisé en théorie. Il s'agit de vérifier si l'identité correspond au flux de travail et si ses autorisations sont plus restreintes que les conséquences d'une erreur. Dans notre travail sur ezeep MCP, nous prenons en charge les deux modèles, car un service d'entrepôt automatisé et un employé qui imprime de manière interactive ont des exigences d'identité réellement différentes.

Qui est responsable lorsqu'un agent IA effectue une action ?

Il s'agit d'un problème de conception de système, pas seulement d'un problème de confiance dans le modèle. Une architecture plus sûre combine plusieurs contrôles : des identités à privilèges minimaux, des capacités limitées et typées, une validation dans le système en aval, une confirmation pour les actions lourdes de conséquences, une séparation entre les instructions de confiance et le contenu non fiable, et une piste d'audit montrant ce qui s'est réellement passé. Le cadrage limite les dommages potentiels ; l'observabilité et l'attribution établissent la responsabilité après qu'une action a eu lieu.

Concevoir pour la réversibilité

Un test utile pour toute capacité d'agent n'est pas seulement de savoir si l'action est autorisée, mais aussi ce qui se passe lorsqu'elle est erronée. Les opérations de lecture, les modifications récupérables, les engagements financiers, les communications externes et l'administration destructive exigent des contrôles différents. Certaines actions devraient nécessiter une confirmation. Certaines devraient prévoir un retour en arrière. D'autres ne devraient pas du tout être exposées à l'agent.

Lors du développement du serveur MCP d'ezeep, nous avons choisi de ne pas exposer la suppression d'utilisateurs, de groupes ou d'imprimantes, même si des API REST connexes existent. Cela ne rend pas les outils restants inoffensifs — l'impression crée un résultat physique et les outils d'administration peuvent modifier les accès — mais cela élimine une catégorie d'erreurs irréversibles. Le principe dépasse le cadre de l'impression : la conception des capacités doit refléter les conséquences, pas seulement la disponibilité technique.

L'injection de prompt peut-elle pousser un agent IA à effectuer la mauvaise action ?

Oui. Un agent peut rencontrer des instructions dissimulées dans des documents, des pages web, des e-mails, des tickets de support ou les résultats d'un outil. C'est ce qu'on appelle couramment l'injection de prompt indirecte : du contenu qui aurait dû être traité comme des données tente d'influencer la prochaine action de l'agent.

Ce risque ne se résout pas en demandant au modèle de « faire attention ». Le contenu non fiable ne doit pas pouvoir accorder des autorisations, modifier l'objectif de l'utilisateur, sélectionner une identité plus privilégiée ou contourner une confirmation. Les entrées d'outils nécessitent une validation déterministe, les actions lourdes de conséquences nécessitent des contrôles de stratégie d'impression en dehors du modèle, et les flux de travail sensibles doivent clairement séparer les instructions de confiance du contenu non fiable.

La chaîne d'approvisionnement des outils compte aussi. Les descriptions des outils influencent le comportement du modèle, donc connecter un nouveau serveur est en soi une décision de sécurité — pas seulement un réglage de commodité.

La sécurité se décide à chaque niveau

Connecter un agent à un système réel est une décision de conception prise à chaque niveau : quelles actions existent, quelle identité elles utilisent, quelles données chaque composant voit, ce qui peut être annulé et ce qui est journalisé. MCP standardise une partie de cette conversation. Le reste dépend des personnes qui construisent la connexion. Dans le serveur MCP d'ezeep, cela signifiait prendre en charge à la fois les identités de service et les identités par utilisateur, et ne pas exposer la suppression d'utilisateurs, de groupes ou d'imprimantes. Chaque agent finira par commettre une erreur, la connexion doit donc être conçue pour ce moment, et c'est ainsi que nous avons construit le serveur MCP d'ezeep.

Souhaitez-vous utiliser ezeep MCP ?

Connectez notre MCP à vos agents dès aujourd'hui.

Essayer gratuitement