エージェントがデータを漏えいさせる経路は3つある。ツール呼び出しで転送する引数を通じて、会話メモリに書き込む内容を通じて、そしてレスポンスとして返す内容を通じてだ。ポリシー文書ではこの3つのいずれも止められない——どれもエージェントが単に仕事をこなしているように見えるからだ。これらを止めるのは、この3つの地点それぞれでテキストをインターセプトし、境界を越える前にPIIを除去するランタイムのトークン化層である。これがその層の仕組みだ。
LLMプロンプトに入る内容をレダクションするのは最低限の対策に過ぎず、ギャップを埋めることはできない。エージェントのデータパスには、生の値が境界の外に出る可能性がある地点が3つあり、そのいずれもプロンプトを経由しない。
エージェントはツール——カレンダーAPI、CRM、決済プロセッサなど——を呼び出すことを決定し、そのとき推論に使っているデータを呼び出し引数として転送する。MCPはフィールド単位の機密性メタデータを持たないため、ツールサーバーはデフォルトでは、エージェントが送信した内容をそのまま平文で受け取る。
会話履歴はターンをまたいで保持され、エージェントに文脈を与える。その履歴に追記されるテキストは——会話の途中で現れる顧客の社会保障番号や医療上の詳細を含め——追記の前に何かがトークン化しない限り、セッションが続く間ずっと平文のままそこに存在する。
呼び出し元に返される最終的なレスポンスは、エージェントが取得し推論に用いたコンテキストから構築される。トークン化が入力時にしか行われない場合、トークンとして入ってきた値が、送信されるレスポンスの中で未トークン化のまま再び表面化することがある。
ツール呼び出し——プロンプトではなく——こそが実際に本番環境での漏えいの大半が発生する場所である理由について、より詳しい論拠は あなたのAIエージェントはツール呼び出しを通じてPIIを漏えいさせている。その証拠にある。
VeriSwarm Guardは同一の基盤となる呼び出し——POST /v1/suite/guard/pii/tokenize——を、各ベクトルがそのままでは漏えいしてしまう地点に適用することで、3つすべてを塞ぐ。テキストはPresidioベースのNER検出エンジン（Presidio + spaCy NER に加え、Presidioが標準では対応しない識別子向けのカスタム正規表現認識器）を通過し、すべてのPII範囲が型付きトークン——[VS:EMAIL:a1b2c3]、[VS:SSN:f9e2d1] など——に置き換えられて返ってくる。エージェント、ツールサーバー、そしてその間でログに記録される全てのものが目にするのはトークンだけだ。元の値は、本当に必要になった場合にのみ、トークンを作成したセッションに限定された別の呼び出しPOST /v1/suite/guard/pii/rehydrateを通じて復元される。
Guard Proxyは透過的なMCPインターセプション層である。エージェントのMCPクライアントを、ツールサーバーに直接ではなくプロキシに向けると、送信するツール呼び出しリクエストと受信するツール呼び出しレスポンスの両方でPIIをトークン化する——エージェント側のコード変更は一切不要だ。3つのデプロイモード：クラウドホスト、オンプレミスDocker、ローカルstdio。
VeriSwarm自身のエージェントランタイムは、エージェントの応答が会話履歴に追記される前に、そして呼び出し元に返される前に、その応答に対してトークン化エンドポイントを呼び出す。メモリに書き込まれる値と、応答として返される値はどちらも同じトークン化済みテキストであり——同期がずれかねない2つの別個の制御ではない。
PII保護の柱では、プロンプト入力のレダクションに対してトークン化を選ぶべきより広い論拠——DLPがエージェントのトラフィックをカバーしない理由、GDPRの仮名化に関する留保事項、Vaultの監査証跡、ヘルスケア業界における立ち位置——を扱っている。このページはより狭く、より実務的だ。エージェントのデータパスの中で実際に漏えいが発生する3つの具体的な地点と、それぞれを塞ぐメカニズムを示す地図である。全体のアーキテクチャとコンプライアンス上の論拠については柱のページを、修正をどこに向けるべきか具体的に知りたい場合はこのページを読んでほしい。
トークン化は上記3つのベクトルにおけるPIIの露出面を減らし、Vaultが有効な場合はすべてのインターセプションの監査証跡を提供する——しかしデータが決して漏えいしないことを保証するものではない。Guard Proxyを迂回するツール呼び出しや、データを転送する前にトークン化エンドポイントを呼び出さないカスタム統合は、このレイヤーが決して目にすることのない漏えい経路である。Guardは自らが組み込まれたベクトルを塞ぐ。まだカバーされていない漏えい経路を新たに作った場合、そこに組み込むのはあなた自身の責任だ。インジェクションは関連はするが別個のリスクである——正規のツールの引数に含まれるPIIではなく、どのツールが呼び出されるかを操作する細工された入力であり——詳しくは AIエージェントのためのプロンプトインジェクション検知を参照。
ツール呼び出しの引数を通じて——エージェントが生のPIIを平文のままMCPツールサーバー（カレンダーAPI、CRM、決済プロセッサなど）に転送する。メモリに書き込む内容を通じて——顧客の社会保障番号や医療上の詳細が会話履歴に追記され、セッションが続く間そこに残り続ける。レスポンスとして返す内容を通じて——トークン化されたコンテキストから構築されたレスポンスでも、出力時にトークン化のステップが省略されれば元の値が表面化しうる。この3つに共通する性質が1つある。どれもポリシー違反には見えないということだ。エージェントが単に仕事をこなしているように見える。
いいえ——それは最も害の少ない漏えいポイントを止めているに過ぎない。LLMがPIIを一切目にしないことは良い実践だが、LLMがその後に決定するツール呼び出しこそが、実際にデータが境界を離れる場所だ。エージェントはプロンプトに何を入れるかについて細心の注意を払っていても、MCP仕様がフィールド単位のデータ機密性メタデータを本質的に持たないため、サードパーティのMCPツールサーバーに顧客の電話番号をそのまま転送してしまうことがある。カバレッジはツール呼び出しにまで及ぶ必要があり、モデルの境界で止まってはならない。
テキストはPOST /v1/suite/guard/pii/tokenizeに渡され、Presidioベースの NER検出エンジン（Presidio + spaCy NER に加え、Presidioがカバーしない識別子向けのカスタム正規表現認識器）を通過したのち、すべてのPII範囲が型付きトークン——[VS:EMAIL:a1b2c3]、[VS:SSN:f9e2d1] など——に置き換えられたテキストとして返される。トークンと値の対応マップはテナントごとにスコープされ、トークン化されたペイロードと一緒に送られることは決してない。トークンは、それを作成したセッションに限定された別のエンドポイント POST /v1/suite/guard/pii/rehydrate を通じてのみ、下流のシステムが実際の値を必要とする特定のケース——例えばCRMレコードへの書き込み——において復元可能である。
ツール呼び出しベクトルについては不要だ。Guard Proxyは透過的なMCPインターセプション層である——エージェントのMCPクライアントは、ツールサーバーに直接ではなくプロキシのURLに接続し、送信するツール呼び出しと受信するレスポンスの両方について、それぞれが境界を越える前にPIIをトークン化する。3つのデプロイモードが、クラウドホスト、オンプレミスDocker、ローカルstdioをカバーする。メモリとエコーのベクトルについては、VeriSwarm自身のエージェントランタイムがすでに、レスポンスを会話履歴に追記する前、あるいは呼び出し元に返す前にトークン化エンドポイントを呼び出している——この配線はプラットフォームの一部として提供され、あなたが構築するものではない。
Guard——PIIトークン化、Guard Proxy、そしてそれと並行して動作するインジェクションスキャン——はMaxプランの機能である。VeriSwarmの無料プランのトラストスコアリングであるGateは、トークン化層が必要になる前の段階で、エージェントの挙動とイベントフローへの可視性を提供する。強制を有効にするのはGuardの役割だ。
いいえ、そうではない。そう主張するベンダーがいれば懐疑的に見るべきだ。トークン化は、ここで扱った3つのベクトルそれぞれにおいてPIIの露出面を減らし、Vaultが有効な場合はすべてのインターセプションの監査証跡を提供する。だが、その3つの外にある漏えい経路まではカバーしない——Guard Proxyを迂回する誤設定の統合や、トークン化のステップを経由しないカスタムのツール呼び出し経路は、依然として意図的に組み込む必要がある。
GuardのPIIトークン化はMaxプランの機能である。Gateの無料プランは、修正を有効にする前に、エージェントのデータが実際にどこへ向かうのかを確認できるよう、トラストスコアリングとイベントの可視性を提供する。