Les agents divulguent des données de trois manières : par les arguments qu'ils transmettent dans un appel d'outil, par ce qu'ils écrivent dans la mémoire de conversation, et par ce qu'ils répètent dans une réponse. Une note de politique n'arrête aucune des trois — toutes les trois ressemblent à l'agent en train de faire son travail. Ce qui les arrête, c'est une couche de tokenisation à l'exécution qui intercepte le texte à chacun de ces trois points et supprime les PII avant qu'elles ne franchissent votre frontière. Voici comment cette couche fonctionne.
Le fait de rédiger ce qui entre dans le prompt du LLM est le strict minimum et ne comble pas la brèche. Le chemin de données d'un agent comporte trois endroits où une valeur brute peut quitter le périmètre, et aucun d'eux ne passe par le prompt.
L'agent décide d'appeler un outil — une API de calendrier, un CRM, un processeur de paiement — et transmet les données sur lesquelles il raisonne comme argument d'appel. MCP ne transporte pas de métadonnées de sensibilité par champ, de sorte que le serveur d'outil reçoit par défaut tout ce que l'agent envoie, en clair.
L'historique de conversation persiste d'un tour à l'autre afin que l'agent dispose de contexte. Tout texte ajouté à cet historique — y compris le numéro de sécurité sociale d'un client ou un détail médical apparu en cours de conversation — y reste en clair pendant toute la durée de la session, à moins que quelque chose ne le tokenise avant que l'ajout ne se produise.
La réponse finale renvoyée à l'appelant est construite à partir du contexte que l'agent a récupéré et sur lequel il a raisonné. Si la tokenisation ne s'exécute qu'à l'entrée, une valeur entrée sous forme de token peut réapparaître non tokenisée dans la réponse sortante.
L'argument plus profond expliquant pourquoi l'appel d'outil — et non le prompt — est l'endroit où se produisent réellement la plupart des fuites en production se trouve dans Votre agent IA divulgue des PII via des appels d'outils. Voici la preuve.
VeriSwarm Guard ferme les trois vecteurs avec le même appel sous-jacent — POST /v1/suite/guard/pii/tokenize — appliqué au point précis où chaque vecteur fuirait sinon. Le texte passe par un moteur de détection NER basé sur Presidio (Presidio + spaCy NER, plus des reconnaisseurs regex personnalisés pour les identifiants que Presidio ne couvre pas d'origine) et revient avec chaque portion de PII remplacée par un token typé — [VS:EMAIL:a1b2c3], [VS:SSN:f9e2d1], et ainsi de suite. L'agent, le serveur d'outil et tout ce qui est journalisé entre les deux voient le token. La valeur d'origine est restaurée, quand elle est réellement nécessaire, via un appel distinct à POST /v1/suite/guard/pii/rehydrate, limité à la session qui a créé les tokens.
Guard Proxy est une couche d'interception MCP transparente. Pointez le client MCP de votre agent vers le proxy plutôt que directement vers le serveur d'outil, et il tokenise les PII à la fois dans la requête d'appel d'outil sortante et dans la réponse entrante — sans aucun changement de code côté agent. Trois modes de déploiement : hébergé dans le cloud, Docker on-prem, stdio local.
Le runtime d'agent propre à VeriSwarm appelle le point de terminaison de tokenisation sur la réponse de l'agent avant que cette réponse ne soit ajoutée à l'historique de conversation et avant que la réponse ne soit renvoyée à l'appelant. La valeur écrite en mémoire et la valeur répétée dans la réponse sont le même texte tokenisé — pas deux contrôles distincts susceptibles de diverger.
Le pilier de protection des PII couvre le cas plus large de la tokenisation par rapport à la rédaction des entrées de prompt — pourquoi le DLP ne couvre pas le trafic des agents, la réserve de pseudonymisation du RGPD, la piste d'audit Vault, la posture pour le secteur de la santé. Cette page est plus étroite et plus opérationnelle : c'est une cartographie des trois points spécifiques du chemin de données d'un agent où une fuite se produit réellement, et du mécanisme qui ferme chacun d'eux. Lisez le pilier pour l'architecture complète et le raisonnement de conformité ; lisez cette page pour savoir, précisément, où cibler le correctif.
La tokenisation réduit la surface de PII sur les trois vecteurs ci-dessus et vous fournit une piste d'audit de chaque interception lorsque Vault est activé — elle ne garantit pas qu'aucune donnée ne fuira jamais. Un appel d'outil contournant Guard Proxy, ou une intégration personnalisée qui n'appelle pas le point de terminaison de tokenisation avant de transmettre des données, est un chemin de fuite que cette couche ne voit jamais. Guard ferme les vecteurs dans lesquels il est câblé ; en câbler un nouveau vous incombe la première fois que vous créez un chemin de fuite qu'il ne couvre pas encore. L'injection est un risque connexe mais distinct — une entrée conçue qui manipule quel outil est appelé, plutôt que des PII dans les arguments d'un appel légitime — couverte séparément dans Détection d'injection de prompt pour les agents IA.
Par les arguments d'appel d'outil — un agent transmet des PII brutes en clair à un serveur d'outil MCP (une API de calendrier, un CRM, un processeur de paiement). Par ce qu'il écrit en mémoire — le numéro de sécurité sociale d'un client ou un détail médical est ajouté à l'historique de conversation et y persiste pendant toute la session. Par ce qu'il répète dans sa réponse — une réponse construite à partir d'un contexte tokenisé peut malgré tout faire réapparaître la valeur d'origine si l'étape de tokenisation est omise à la sortie. Les trois partagent une propriété : aucune ne ressemble à une violation de politique. Elles ressemblent à l'agent en train de faire son travail.
Non — cela n'arrête que le point de fuite qui fait le moins de mal. Le fait que le LLM ne voie jamais de PII est une bonne pratique, mais l'appel d'outil que le LLM décide ensuite de faire est l'endroit où les données quittent réellement votre périmètre. Un agent peut être scrupuleusement prudent quant à ce qu'il met dans un prompt et transmettre malgré tout le numéro de téléphone d'un client textuellement à un serveur d'outil MCP tiers, car la spécification MCP ne transporte pas intrinsèquement de métadonnées de sensibilité des données par champ. La couverture doit s'étendre jusqu'à l'appel d'outil, et ne pas s'arrêter à la frontière du modèle.
Le texte est transmis à POST /v1/suite/guard/pii/tokenize, qui le fait passer par un moteur de détection NER basé sur Presidio (Presidio + spaCy NER, plus des reconnaisseurs regex personnalisés pour les identifiants que Presidio ne couvre pas) et renvoie le texte avec chaque portion de PII remplacée par un token typé — [VS:EMAIL:a1b2c3], [VS:SSN:f9e2d1], et ainsi de suite. La correspondance token-valeur est propre à chaque tenant et ne voyage jamais avec la charge utile tokenisée. Les tokens ne sont réversibles que via POST /v1/suite/guard/pii/rehydrate, limité à la session qui les a créés, pour le cas précis où un système en aval a besoin de la valeur réelle pour faire son travail — écrire dans un enregistrement CRM, par exemple.
Pour le vecteur de l'appel d'outil, non. Guard Proxy est une couche d'interception MCP transparente — le client MCP de votre agent pointe vers l'URL du proxy au lieu du serveur d'outil directement, et il tokenise les PII à la fois dans l'appel d'outil sortant et dans la réponse entrante avant que l'un ou l'autre ne franchisse la frontière. Trois modes de déploiement couvrent l'hébergement dans le cloud, Docker on-prem et le stdio local. Pour les vecteurs de mémoire et d'écho, le runtime d'agent propre à VeriSwarm appelle déjà le point de terminaison de tokenisation avant d'ajouter une réponse à l'historique de conversation ou de la renvoyer à l'appelant — cette plomberie est fournie avec la plateforme, ce n'est pas quelque chose que vous construisez.
Guard — la tokenisation des PII, Guard Proxy et le scan d'injection qui s'exécute à ses côtés — est une fonctionnalité de l'offre Max. Gate, le scoring de confiance de l'offre gratuite de VeriSwarm, vous donne de la visibilité sur le comportement de l'agent et le flux d'événements avant que vous n'ayez besoin de la couche de tokenisation ; c'est avec Guard que vous activez l'application des règles.
Non, et il faut se méfier de tout fournisseur qui prétend le contraire. La tokenisation réduit la surface de PII sur chacun des trois vecteurs couverts ici et vous fournit une piste d'audit de chaque interception lorsque Vault est activé. Elle ne couvre pas les chemins de fuite en dehors de ces trois-là — une intégration mal configurée qui contourne Guard Proxy, ou un chemin d'appel d'outil personnalisé qui ne passe pas par l'étape de tokenisation, doit toujours être câblé délibérément.
La tokenisation des PII de Guard est une fonctionnalité de l'offre Max ; l'offre gratuite de Gate vous donne le scoring de confiance et la visibilité des événements pour voir où vont réellement les données d'un agent avant d'activer le correctif.