Skip to content
VeriSwarm
会社概要
ドキュメント料金エージェントスキル
ログイン登録
  1. ホーム
  2. /Learn
  3. /Pii protection ai agents
VeriSwarm
  • English
  • Español
  • Deutsch
  • Français
  • Italiano
  • Português
  • ✓ 日本語
  • 한국어
  • 简体中文

プロダクト

  • 料金
  • ドキュメント
  • API
  • エージェントスキル
  • OATS仕様

信頼性

  • トラストセンター
  • セキュリティ
  • コンプライアンス
  • ステータス
  • 変更履歴

会社情報

  • 会社概要
  • ブログ
  • オープンソース
  • 投資家情報
  • プレス

法務

  • 利用規約
  • プライバシー
  • SLA
  • DPA
  • アクセシビリティ
技術ガイド

AIエージェントのためのPII保護

今日、本番環境で稼働する自律エージェントの大半は、氏名、メールアドレス、社会保障番号、決済データといった生のPIIを、トークン化も監査証跡もないまま、サードパーティのMCPツールサーバーに直接渡している。解決策はポリシー文書ではない。エージェントとあらゆる外部ツールの間に位置し、データが境界を離れる前にトークン化し、あらゆる接触を不変の台帳に記録するインターセプション層こそが解決策だ。これがVeriSwarm Guardの対処方法だ。

AIエージェントにおけるPII保護の意味

AIエージェントにおけるPII保護とは、エージェントが辿るデータパス——プロンプト入力、LLMコンテキスト、MCPツール呼び出し、サードパーティサービス、送出レスポンス——を通じて個人を識別できる情報が漏えいするのを防ぎつつ、ツールがそのデータで有用な作業を行えるようにする実践のことだ。これはLLM入力のリダクションの上位集合であり、本番環境で最も損害を与える漏えいポイントはLLMそのものではなく、LLMが呼び出しを決定した後のツール呼び出しにある。

漏えいベクトル——なぜデフォルトでは見えないのか

典型的なエージェントのワークフローはこうだ。ユーザーが氏名、メールアドレス、電話番号、クレジットカードを入力する。LLMがそれを処理する。エージェントはその後、カレンダーAPI、CRM、決済プロセッサーといったツールを呼び出し、そのデータをMCP経由で平文のまま転送する。MCP仕様にはユーザーコンテキストが本質的に含まれておらず、ツールサーバーはユーザーを区別することも、ユーザーごとの制御を適用することもできない。あらゆるデータカテゴリ——PII、認証情報、財務データ——が、デフォルトで単一のワークフロー内でマシン速度のまま外部に転送され得る。

このギャップを塞ぐための段階的な仕組みについては、AIエージェントのデータ漏えいを防ぐ方法を参照してほしい。

2026年の数字は褒められたものではない。

  • AIトラフィックをエンドツーエンドで監視している企業はわずか38%——プロンプト、ツール呼び出し、出力を含めて。残りの62%はエージェントのデータフローに死角を抱えている。
  • AIの出力を通じたPII漏えいは、2026年Kiteworks Forecastで組織の27%がトップリスクとして挙げた。
  • シャドーAIによる侵害は顧客PIIを65%の割合で危険にさらしている。従来型の侵害における世界平均53%に対してである。
  • 侵害された組織の63%はAIガバナンスポリシーを持たないか、まだ策定中である。ポリシーを持つ組織のうち、定期的な監査を実施しているのはわずか34%だ。
  • 侵害コストプレミアムは、シャドーAIインシデントの場合、平均で670,000ドル多く、従来型の侵害よりも検知までに平均247日を要する。

従来型DLPがこれをカバーできない理由

データ損失防止(DLP)は、人間がファイルをコピーしメールを送信していた世界のために構築された。エージェントのツール呼び出しは、DLPが前提とするあらゆる仮定を打ち破る。

速度と量

エージェントは1分間に数百回のツール呼び出しを行うことができる。従来型のDLP検査は、自動化の目的を台無しにするボトルネックにならない限り、この速度についていけない。

コンテキストの喪失

DLPポリシーは、既知のチャネルを通じた静止データまたは転送中のデータを分類する。MCPツール呼び出しは動的でプログラム的であり、セキュリティチームが存在すら把握していないエンドポイントを経由することがある。

正規表現だけでは不十分

パターンマッチングは既知の形式(カード番号、社会保障番号)を検出できるが、病歴のようなコンテキスト依存のPIIや、複数のトークンにまたがる識別子は見逃してしまう。構造化データに対するNERが必要になるのはこの点だ。

インターセプション層:Guard Proxy + Presidio NER

機能する唯一のアーキテクチャは、エージェントとそのツールの間に置かれるランタイムのインターセプション層である。Guard Proxyはまさにその位置に立つ。Presidio(Microsoftのオープンソースの NERエンジン)は、氏名、メールアドレス、電話番号、社会保障番号、クレジットカード、IPアドレス、金融・政府発行のID番号(銀行口座、運転免許証、パスポート)といったPIIカテゴリを、ツール呼び出しが境界を離れる前に検出しトークン化する。ツールサーバーが目にするのは[PERSON_1]であり、「Jane Smith」ではない。LLMはトークンをもとに推論する。元の値は、認可されたユーザーへの最終レスポンスでのみ復元される。これは事後的なスキャンではなく、インラインでの変換だ。

トランスフォーマー・パイプラインは、固定された順序で4つの組み込みトランスフォーマーを実行する——まずPIIトークン化、次にコンテキスト注入、フィールドマスキング、スキーマ検証の順だ。それぞれが何をするか、何がそれをトリガーするか、カスタムトランスフォーマーをどう追加するかの詳細な内訳は、Guard Proxyの4つのトランスフォーマー:それぞれが何を、どの順序でインターセプトするかにある。

3つのデプロイモード(クラウドホスト、オンプレミスDocker、ローカルstdio)が、「エージェントをURLに向けるだけ」から「データが自社のVPCを一切出ない」までの全範囲をカバーする。

GDPRに関する正直な注意点

トークン化は仮名化であって、匿名化ではない。GDPR第4条(5)のもとでは、仮名化されたデータは依然として個人データである——トークンと参照テーブルを組み合わせれば個人を再識別できる可能性があり、参照テーブルなしでも複数のトークン化済みフィールドを組み合わせることで身元が明らかになり得る。つまり、Guardによってトークン化されたペイロードも、依然としてGDPRの適用範囲内にあり、必要な統制が変わるだけである。

実務上、トークン化は露出時の被害範囲を縮小し、第32条が求める「最新技術水準」の統制を実証する——しかし、データ主体の権利、侵害通知義務、処理活動の記録要件をなくすわけではない。トークン化によってPIIが「もはや個人データではない」と主張するベンダーは、誤解しているか、何かを売り込んでいるかのどちらかだ。私たちは違う。

Vault:提出が必要になる監査証跡

あらゆるPIIインターセプションは、Vaultのハッシュチェーン台帳に記録される——何が送信され、何がトークン化され、何が返され、いつ、どのエージェントアイデンティティによって、どのツールに対して行われたかを含めて。監査人が「この顧客のデータはどこへ行ったのか」と尋ねたとき、答えは監視ツールのスクリーンショットではなく、暗号学的に検証可能なタイムラインである。チェーン検証は改ざんを検出し、エクスポートはGDPR第30条の処理活動記録要件に直接対応する。

チェーン検証が失敗した日のためのランブック——エンドポイント、レスポンスの形式、調査手順——は、Vaultチェーンの検証:整合性が壊れた日のためのランブックにある。

ヘルスケア特有の姿勢

ヘルスケアは、エージェントとツールの境界におけるPII保護が最も厳しく問われるユースケースである。2025年のOCR執行記録によれば、リスク分析に関する指摘が和解事案の3:1の比率で最多を占め、平均罰金額は約291,000ドル、さらに2年間の監視義務が課されている。Guardのトークン化、Vaultの台帳、そしてエージェントレベルのスコアリングループが組み合わさることで、その監査に耐える姿勢が生まれる——それはヘルスケア向け業種別サーフェスに組み込まれており、HIPAAに準拠したデフォルト設定が標準で有効になっている。

よくある質問

エージェントは実際の値を見るのか、それともトークンを見るのか?

トークンだ。Guard Proxyは、インターセプション境界でPIIをトークン化する——氏名、メールアドレス、電話番号、社会保障番号、クレジットカード、IPアドレス、金融・政府発行のID番号(銀行口座、運転免許証、パスポート)を含めて——そしてLLMはトークンをもとに推論する。ツールサーバーが受け取るのはトークンだ。元の値は、認可されたユーザーへの最終レスポンスでのみ復元され、それより下流では平文を目にすることはない。

トークンと値のマッピングはどのように保護されているのか?

このマップはテナントのGuard Proxyのデプロイ内に存在し、トークン化されたペイロードと一緒にネットワーク越しに送信されることは決してない。クラウドホスト型モードではテナント固有の暗号化の背後に置かれ、オンプレミスDockerモードでは自社ネットワークの外に一切出ない。トークン形式はそのキーによってのみ可逆であるため、インターセプトされたツール呼び出しが漏らすのはトークンであり、その背後にある値ではない。

これはHIPAAを満たすのか?

統制の一つである。ツール呼び出し境界でのトークン化は、PHIをLLMのコンテキストから、また自社が管理していないMCPツールサーバーから遠ざけ、Vaultのハッシュチェーン台帳に記録することで、データフローの記録が監査に耐えるようにする。完全なHIPAA対応には、下流のツールサーバーとのBAA、エージェント自体への署名済みマニフェスト(Passport)、そして侵害対応をめぐる運用プロセスも必要になる。ランタイムのトークン化は最大の技術的ギャップを埋めるものであり、残りは書類手続きと運用の話だ。

トークン化 対 削除 対 マスキング 対 遮断——それぞれどう使い分けるのか?

削除(リダクション)は値を破壊する(不可逆)——テレメトリやログには適しているが、ツールがその機能のためにデータを必要とする場合は使えない。マスキングは部分的に隠す(カードの下4桁など)——人間が読む画面には適している。遮断は呼び出しを完全にブロックする——重大なポリシー違反には正しい対応だ。トークン化は秘密を取り除きながら有用性を保持する——4つの中で唯一、ツールサーバーが元の値を見ずに有用な作業を続けられる方式である。Guardはこの4つすべてをサポートしており、選択はデータカテゴリとポリシーごとに行う。

Guard ProxyはMCPツール呼び出しに対応しているのか?

はい——それが主戦場だ。Guard Proxyは、3つのデプロイモード(クラウドホスト、オンプレミスDocker、ローカルstdio)を持つ透過的なMCPインターセプション層である。エージェントのMCPクライアントは、ツールサーバーに直接ではなくGuard Proxyに接続する。Guard ProxyはPIIを除いた呼び出しを転送し、レスポンスを返す。エージェント側のコード変更は不要だ。

GuardはPIIだけでなくシークレットやAPIキーもトークン化するのか?

はい——同じトークン化の仕組みが両方をカバーする。個人データに加えて、検出器はGitHubトークン、OpenAIキー、AWSキー、Slackトークン、GCPキー、Stripeキー、JWT、秘密鍵ブロックといった認証情報の形式を認識し、氏名や社会保障番号をトークン化するのと同じ方法でトークン化する。ツール呼び出しに向かう途中で漏えいしたAPIキーは、境界を出る前にインターセプトされる——漏えいした社会保障番号だけではない。

PIIトークンはどのくらいの期間有効で、誰が元に戻せるのか?

トークンは設定可能なTTL——デフォルトでは1時間——の後に失効し、特定のテナントとセッションに限定されるため、ある会話のために発行されたトークンを別の会話で再生することはできない。元の値は保存時に暗号化され(対称鍵のFernet暗号化)、平文への再水和のたびに監査用に記録される。トークン単体が漏えいしても、暗号化キーとアクティブでスコープが限定されたセッションの両方がなければ無意味だ。

トークン化は、ツール呼び出しのJSONペイロード内にネストされたPIIを検出できるのか、それともトップレベルのフィールドだけなのか?

構造全体を走査する。Guardのトークナイザーは、ツール呼び出しの引数——およびレスポンスボディ——にあるあらゆるdictとlistを再帰的に走査するため、`data.customer.email`のように埋め込まれたPIIや、レコードのリストの中にあるPIIも、トップレベルのフィールドと同様にトークン化される。以前のバージョンはトップレベルしか検査しておらず、典型的なMCPペイロードの形式にネストされたPIIが編集されないまま通過してしまっていた——このギャップは重大な修正として塞がれた。

ツール呼び出し境界での漏えいを止める

Guard Proxyはエージェントのコードを一切変更する必要がない。MCPクライアントをツールサーバーの代わりにGuard Proxyに向けるだけでよい。Guard ProxyはPIIを除いた呼び出しを転送し、レスポンスを返す。Gateの無料プランは、まずインベントリとイベントフローへの可視性を提供する——修正を有効化する前に問題を確認できるように。

デモを試す無料で始める