La plupart des agents autonomes en production aujourd'hui transmettent des PII brutes directement à des serveurs d'outils MCP tiers — noms, e-mails, numéros de sécurité sociale, données de paiement — sans aucune tokenisation ni aucun journal d'audit. La solution n'est pas une note de politique. C'est une couche d'interception qui se place entre l'agent et chaque outil externe, qui tokenise les données avant qu'elles ne quittent votre périmètre et qui enregistre chaque interaction dans un registre immuable. Voici comment VeriSwarm Guard gère cela.
La protection des PII pour les agents IA est la pratique consistant à empêcher les informations personnelles identifiables de fuiter le long du chemin de données que parcourt un agent — saisie du prompt, contexte du LLM, appels d'outils MCP, services tiers et réponses sortantes — tout en permettant aux outils d'effectuer un travail utile sur ces données. C'est un sur-ensemble de la rédaction des entrées du LLM : le point de fuite qui fait le plus de dégâts en production n'est pas le LLM, c'est l'appel d'outil une fois que le LLM a décidé de le passer.
Un flux de travail d'agent typique : un utilisateur fournit son nom, son e-mail, son téléphone et une carte de crédit. Le LLM les traite. L'agent appelle ensuite un outil — une API de calendrier, un CRM, un processeur de paiement — et transmet ces données en clair via MCP. La spécification MCP ne porte pas nativement de contexte utilisateur ; le serveur d'outil ne peut pas différencier les utilisateurs ni appliquer de contrôles par utilisateur. Chaque catégorie de données — PII, identifiants, données financières — peut être transmise en externe dans un seul flux de travail à la vitesse d'une machine, par défaut.
Pour la mécanique détaillée permettant de combler cette faille, voir comment prévenir une fuite de données d'un agent IA.
Les chiffres de 2026 ne sont pas flatteurs :
La prévention des pertes de données (DLP) a été conçue pour un monde où les humains copiaient des fichiers et envoyaient des e-mails. Les appels d'outils des agents brisent chaque hypothèse sur laquelle repose le DLP :
Un agent peut effectuer des centaines d'appels d'outils par minute. L'inspection DLP traditionnelle ne peut pas suivre le rythme sans devenir un goulot d'étranglement qui va à l'encontre de l'automatisation.
Les politiques DLP classent les données au repos ou en transit via des canaux connus. Les appels d'outils MCP sont dynamiques, programmatiques et transitent par des endpoints que l'équipe de sécurité ignore parfois.
La correspondance de motifs détecte les formats connus (numéros de carte, numéros de sécurité sociale) mais passe à côté des PII dépendant du contexte, comme les conditions médicales ou les identifiants répartis sur plusieurs tokens. C'est là que le NER sur données structurées devient nécessaire.
L'architecture qui fonctionne est une couche d'interception à l'exécution entre l'agent et ses outils. Guard Proxy se situe à cette position. Presidio (le moteur NER open source de Microsoft) détecte et tokenise les catégories de PII — noms, e-mails, numéros de téléphone, numéros de sécurité sociale, cartes de crédit, adresses IP, ainsi que les numéros d'identification financiers ou gouvernementaux (comptes bancaires, permis de conduire, passeports) — avant que l'appel d'outil ne quitte le périmètre. Le serveur d'outil voit [PERSON_1] au lieu de « Jane Smith ». Le LLM raisonne sur le token. La valeur d'origine n'est restaurée que dans la réponse finale à l'utilisateur autorisé. Ce n'est pas une analyse a posteriori ; c'est une transformation en ligne.
Le pipeline de transformateurs exécute quatre transformateurs intégrés dans un ordre fixe — d'abord la tokenisation des PII, puis l'injection de contexte, le masquage de champs et la validation de schéma. Le détail complet de ce que fait chacun, ce qui le déclenche et comment ajouter des transformateurs personnalisés se trouve dans Les quatre transformateurs de Guard Proxy : ce que chacun intercepte, dans l'ordre.
Trois modes de déploiement (hébergé dans le cloud, Docker on-prem, stdio local) couvrent toute la gamme, de « pointez votre agent vers une URL » jusqu'à « les données ne quittent jamais votre VPC ».
La tokenisation est de la pseudonymisation, pas de l'anonymisation. En vertu de l'article 4(5) du RGPD, les données pseudonymisées restent des données personnelles — le token combiné à la table de correspondance peut toujours réidentifier la personne, et plusieurs champs tokenisés peuvent être combinés pour révéler l'identité même sans la table de correspondance. Cela signifie qu'une charge utile tokenisée par Guard reste dans le champ d'application du RGPD ; cela ne fait que déplacer les contrôles requis.
En pratique, la tokenisation réduit le rayon d'impact d'une exposition et démontre les contrôles « à l'état de l'art » exigés par l'article 32 — mais elle n'élimine ni les droits des personnes concernées, ni les obligations de notification des violations, ni les exigences de registre des traitements. Un fournisseur qui affirme que la tokenisation fait que les PII « ne sont plus des données personnelles » se trompe ou vous vend quelque chose. Ce n'est pas notre cas.
Chaque interception de PII est enregistrée dans le registre chaîné par hash de Vault — ce qui a été envoyé, ce qui a été tokenisé, ce qui a été renvoyé, quand, par quelle identité d'agent, contre quel outil. Lorsqu'un auditeur demande « où sont allées les données de ce client ? », la réponse est une chronologie vérifiable de façon cryptographique, pas une capture d'écran d'un outil de surveillance. La vérification de chaîne détecte les altérations ; les exports correspondent directement aux exigences de registre des traitements de l'article 30 du RGPD.
La procédure pour le jour où la vérification de chaîne échoue — l'endpoint, la forme de la réponse, les étapes d'investigation — se trouve dans Vérifier une chaîne Vault : une procédure pour le jour où l'intégrité se brise.
Le secteur de la santé est le cas d'usage le plus exigeant pour la protection des PII à la frontière agent-outil. Le bilan des sanctions de l'OCR de 2025 montre que les constats d'analyse de risques dominent les règlements dans une proportion de 3:1, avec des amendes moyennes d'environ 291 000 $, plus des obligations de surveillance de 2 ans. La tokenisation de Guard, le registre de Vault et la boucle de scoring au niveau de l'agent se combinent en une posture qui résiste à cet audit — intégrée dans la surface verticale santé avec des paramètres par défaut alignés sur la HIPAA activés par défaut.
Des tokens. Guard Proxy tokenise les PII à la frontière d'interception — noms, e-mails, numéros de téléphone, numéros de sécurité sociale, cartes de crédit, adresses IP, numéros d'identification financiers et gouvernementaux (comptes bancaires, permis de conduire, passeports) — et le LLM raisonne sur le token. Les serveurs d'outils reçoivent le token. La valeur d'origine n'est restaurée que dans la réponse finale à l'utilisateur autorisé ; rien en aval ne voit le texte en clair.
La correspondance réside à l'intérieur du déploiement Guard Proxy du tenant et n'est jamais envoyée sur le réseau avec la charge utile tokenisée. En mode hébergé dans le cloud, elle est protégée par un chiffrement propre au tenant ; en mode Docker on-prem, elle ne quitte jamais votre réseau. Le format du token n'est réversible qu'avec cette clé, de sorte qu'un appel d'outil intercepté ne divulgue que le token, pas la valeur qu'il représente.
C'est l'un des contrôles. La tokenisation à la frontière de l'appel d'outil maintient les PHI hors du contexte du LLM, hors des serveurs d'outils MCP que vous ne contrôlez pas, et les fait entrer dans le registre chaîné par hash de Vault afin que le registre du flux de données survive à un audit. La posture HIPAA complète nécessite aussi des BAA avec les serveurs d'outils en aval, des manifestes signés sur les agents eux-mêmes (Passport), et des processus opérationnels autour de la réponse aux violations. La tokenisation à l'exécution comble la plus grande lacune technique ; le reste relève de la paperasse et des opérations.
La rédaction détruit la valeur (irréversible) — adaptée à la télémétrie et aux journaux, inutile quand l'outil a besoin de la donnée pour fonctionner. Le masquage obscurcit partiellement (4 derniers chiffres d'une carte) — bon pour les surfaces lisibles par des humains. Le blocage empêche complètement l'appel — adapté aux violations de politique majeures. La tokenisation préserve l'utilité tout en supprimant le secret — la seule des quatre où le serveur d'outil peut encore effectuer un travail utile sans voir la valeur d'origine. Guard prend en charge les quatre ; le choix se fait par catégorie de donnée et par politique.
Oui — c'est sa surface principale. Guard Proxy est une couche d'interception MCP transparente avec trois modes de déploiement (hébergé dans le cloud, Docker on-prem, stdio local). Le client MCP de votre agent pointe vers Guard Proxy au lieu du serveur d'outil directement ; Guard Proxy transmet l'appel sans les PII et renvoie la réponse. Aucun changement de code côté agent.
Oui — la même mécanique de tokenisation couvre les deux. Outre les données personnelles, le détecteur reconnaît les formats d'identifiants — tokens GitHub, clés OpenAI, clés AWS, tokens Slack, clés GCP, clés Stripe, JWT et blocs de clé privée — et les tokenise de la même manière qu'il tokenise un nom ou un numéro de sécurité sociale. Une clé API qui fuit en route vers un appel d'outil est interceptée avant de quitter votre périmètre, pas seulement un numéro de sécurité sociale qui fuit.
Les tokens expirent après un TTL configurable — une heure par défaut — et sont limités à un tenant et une session spécifiques, de sorte qu'un token créé pour une conversation ne peut pas être rejoué dans une autre. Les valeurs d'origine sont chiffrées au repos (chiffrement symétrique Fernet), et chaque réhydratation vers le texte en clair est journalisée pour l'audit. Un token qui fuit à lui seul est inutile sans à la fois la clé de chiffrement et une session active et limitée.
Elle parcourt toute la structure. Le tokeniseur de Guard parcourt récursivement chaque dict et chaque liste dans les arguments d'un appel d'outil — et dans le corps de la réponse — de sorte que les PII enfouies dans `data.customer.email` ou à l'intérieur d'une liste d'enregistrements sont tokenisées de la même manière qu'un champ de premier niveau. Une version antérieure n'inspectait que le premier niveau, ce qui laissait passer sans les rédiger les PII imbriquées dans les formes de charge utile MCP typiques ; cette faille a été corrigée comme un correctif critique.
Guard Proxy ne nécessite aucun changement dans le code de votre agent. Pointez votre client MCP vers Guard Proxy au lieu du serveur d'outil ; Guard Proxy transmet l'appel sans les PII et renvoie la réponse. Le niveau gratuit de Gate vous donne d'abord une visibilité sur l'inventaire et le flux d'événements — pour que vous puissiez voir le problème avant d'activer la solution.