AI エージェント向け PII マスキング — フィールドレベル機密度分類
エージェント結果パスにおいて、FutrixData は機密の結果値を、行を MCP、Skill、CLI 呼び出し元に返す前に、シークレット派生のソルト付きハッシュ文字列に置き換えます。置換はシークレットバックの確定的ハッシュアルゴリズムで、キーは OS レベルのシークレットストレージに保管されたローカル鍵から派生します。確定性は要点です: エージェントは生の値を見ることなく、結合、グループ化、カウントを引き続き実行できます。
AI コンテキストでの PII マスキングの意味
従来のマスキングは、ストレージ前または UI に表示される前に値を書き換えます。AI エージェント向けの PII マスキングは、書き換えをデータが出ていく境界 — つまり LLM コンテキストのために行がデータベースから出る瞬間 — に移動させます。エージェントは依然として正しいデータフォーマット、正しい結合、安定した等価セマンティクスを持つ行を取得しますが、alice@example.com の代わりに masked:v1:8f3a1c9b72e04d11 を取得します。
これが重要なのは、データがエージェントのコンテキストに入った瞬間、外部モデル、プラグイン、ログシステム、デバッグキャプチャ、トークンリレーサービスへ流れる可能性があるためです。これらは企業ガバナンスが及ばない場所です。
5 段階の機密度分類 (拡張可能)
FutrixData には L1〜L5 機密度分類モデルが付属しています。レベルは設定可能で、デフォルトは以下のとおりです。
| レベル | 意味 | 例 |
|---|---|---|
| L1 公開 | 機密でないビジネスデータ | id、status、created_at |
| L2 内部 | 内部識別子とメタデータ | user_id、session_id、request_id |
| L3 機密 | 間接的な個人情報、行動、位置 | ip_address、user_agent、device_id |
| L4 センシティブ | 直接的な個人情報、財務、医療 | email、phone、salary、date_of_birth |
| L5 重要 | 認証情報、決済手段、高機密 PII | password、credit_card、api_secret、home_address |
デフォルトでは、エージェントは L1〜L3 を平文で受け取ります。L4 と L5 は、エージェントに到達する前に安定したハッシュに置き換えられます。エージェントのアクセス可能範囲は編集可能で、L1〜L2 のみをエージェントにアクセス許可するようにカスタマイズすることもできます。
FutrixData がエージェント結果パスでマスクする方法
マスキングは値ごとに確定的に計算されます:
- 生のフィールド値を文字列に変換します。
- OS レベルのシークレットストレージに保管されたローカルシークレットから、(データソース, フィールド) ごとに HMAC キーを派生させます。ローカルシークレットは初回起動時に生成され、ホストにとどまり、決して離れません。同じ生の値でも、データソースやフィールドが異なれば異なるハッシュになります。
- 派生したキーで生の値に対して HMAC-SHA256 を計算します。
- 最初の 16 桁の 16 進数文字を取得します。
masked:v1:を先頭に付け、マスク後のデータをエージェントに返します。
同じ入力はインストール内で同じ鍵を生成するため、エージェントは結合、グループ化、カウントディスティンクト、等価性についての推論を、生の値を見ることなく実行できます。マッピングはローカルシークレットなしでは一方向です。確定的マスキングは漏洩面を減らしますが、完全な匿名化ではありません。逆については マスキングの制限 をご覧ください。
2 つの分類経路
FutrixData は機密度レベルを割り当てる 2 つの方法をサポートしており、どちらも同じ分類ストアに書き込みます。
- 外部エージェント分類。Claude Code、Cursor、または任意の MCP/Skill クライアントがスキーマを読み取り、フィールドを分類し、ツール呼び出しでレポートを書き戻します。行データは送信されず、列名と型のみです。
- 組み込み AI スキャン分類。デスクトップアプリがスキーマを読み取り、列名 + 型 (行値ではない) を設定済みのカスタムモデルに送信し、人間による二次確認のために結果を提示します。手動修正と外部エージェント書き込みは、再スキャン全体で保持されます。
コンプライアンスの観点
GDPR 第 5 条 (1)(c) はデータ最小化 — 必要なものだけの処理 — を要求しています。欧州データ保護会議は、仮名化されたデータが追加情報を通じて引き続きリンクできる場合、個人データのままであることを明確にしています。PII マスキングは「コンプライアンスを消滅させる」ものではなく、漏洩面を減らし、データがデータベースから出ていく場面を監査・統制しやすくします。監査ログは各クエリでマスクされた列を記録するため、セキュリティチームに具体的に証明できる材料が提供されます。
サンプル
// Raw row from PostgreSQL
{ "id": 1042, "email": "alice@example.com", "phone": "+14155550123", "status": "active" }
// Row delivered to the agent (default L1–L3 access)
{ "id": 1042, "email": "masked:v1:8f3a1c9b72e04d11", "phone": "masked:v1:b219ac74e1d908f2", "status": "active" }{
"data_source": "prod-postgres",
"table": "users",
"fields": [
{ "name": "id", "type": "bigint" },
{ "name": "email", "type": "varchar(254)" },
{ "name": "phone", "type": "varchar(20)" },
{ "name": "status", "type": "varchar(16)" }
]
}よくある質問
デフォルトでどのフィールドがマスクされますか?
L4 (email、phone、salary、date_of_birth など) と L5 (password、credit_card、api_secret、home_address) はエージェントに到達する前にマスクされます。L1〜L3 は平文で返されます。アクセス可能範囲はエージェントごとに編集できます。
マスクされた値は元に戻せますか?
ローカル鍵なしでは戻せません。マスキングはシークレットバックの確定的 HMAC-SHA256 です。HMAC キーは OS レベルのシークレットストレージに保管されたローカルシークレットから (データソース, フィールド) ごとに派生し、ホストを離れません。同じ入力はインストール内で同じハッシュ値を生成しますが、ハッシュ値を逆算するにはローカル鍵が必要であり、加えて FutrixData はハッシュ値の先頭 16 桁のみを取るため、衝突確率も極めて低く、事実上逆算は不可能です。ただし重要な注意点があります: 低カーディナリティの入力空間 (ブール値、性別、年単位の年齢、小規模な列挙型) は依然として列挙攻撃に対して脆弱です — ゲートウェイを通じて既知の入力を投入できる者、あるいはローカルシークレットを保持する者は、そうしたフィールドのルックアップテーブルを構築できます。コンソール (権限のある人間) パスはデフォルトで生の行を返します。エージェント結果パスのみがマスクされます。limitations をご覧ください — 確定的マスキングは漏洩面を減らしますが、データセットを公開リリース用に匿名化するわけではありません。
マスキングは結合や集約を壊しますか?
いいえ。同じ入力は同じマスク済み出力を生成するため、結合、グループバイ、カウントディスティンクト、等価述語はマスクされた列で引き続き機能します。マスクされたフィールドでの順序付けや部分文字列操作は失われます — それらはエージェント内ではなくプロキシ内で実行する必要があります。
機密度レベルをカスタマイズできますか?
はい。レベル名、説明、例フィールド、エージェントアクセス可能範囲は編集可能です。ソース単位またはテーブル単位のオーバーライドも追加できます — たとえば、本番では orders.notes を L4 として、ステージングコピーでは L1 として分類できます。
GDPR の下で、ハッシュ化されたデータは依然として個人データですか?
一般的にはい。欧州データ保護会議は、仮名化されたデータが追加情報を通じてリンクし直せる場合、個人データとして扱います。マスキングは漏洩面の削減であり、魔法のコンプライアンススイッチではありません — しかし、GDPR 第 32 条の下では弁護可能な技術的措置です。
パフォーマンスのオーバーヘッドはどれくらいですか?
行ごとのマスキングは、機密フィールド 1 つあたり 1 回のシークレットバック HMAC で、典型的な行サイズではサブミリ秒です。ほとんどのクエリでの支配的なコストは、マスキングステップではなくデータベース自体と LLM ラウンドトリップです。
FutrixData は LLM プロバイダーにスキーマメタデータを送信しますか?
送信できます — AI チャット / スキーマ知識 / ER アシスタンスのパスで、これはクエリ結果行とは別のパスです。スキーマメタデータには、テーブル名、列名、型、インデックス、コメントが含まれる場合があります。結果のマスキングは、スキーマメタデータを自動的にカバーしません。スキーマは AI に理解してもらうべき構造そのものであり、データではないからです。デスクトップアプリは、データソースごとのスキーマから LLM への送信切り替えを公開し、各送信は監査できるよう記録されます。スキーマ自体がビジネス機密 (KYC テーブル、規制コード、内部製品名) をエンコードしている場合は、そのデータソースの切り替えを無効にしてください。完全なデータパスマップについては trust をご覧ください。
マスキングはデスクトップコンソールに適用されますか?
いいえ — 設計上そうです。コンソールは権限のある人間がクエリを実行するパスです。キーボードに座っているエンジニアが検査者です。マスキングはエージェント結果パス (MCP、Skill、エージェント CLI) で適用されます。特定のユーザーに生の値を見せたくない場合は、コンソール側ではなく、データソース自体でアクセスを制御してください。
FutrixData をご自身のデータベースで試す
macOS、Windows、Linux 向けの無料デスクトップアプリ。本番環境にはセルフホスト型 Enterprise Edition もご利用いただけます。