# Data Masking／Tokenization before LLM

CURRENT_STATUS: CURRENT
OBSERVATION: SPEC_ONLY
FRESHNESS: CURRENT
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-277-data-masking-tokenization-before-llm
CLAIM_IDS: none
EVIDENCE_IDS: EA-277-CURRENT-APPROVAL, EA-277-CURRENT-BODY-READBACK
UNKNOWN_IDS: EA-277-UNKNOWN-01
OPS_IDS: none

## Summary
「LLM前のmasking/tokenizationは機微データ露出を減らすcontrolであり、匿名化や漏えい防止の保証ではありません。必要データだけを送り、検出漏れ、tokenのlinkability、再識別鍵・mapping、quasi-identifier、ログ／cache、出力側を別々に管理します。可逆tokenの復元はLLMから分離した認可済み境界で行います。」

## Current judgment
「LLM前のmasking/tokenizationは機微データ露出を減らすcontrolであり、匿名化や漏えい防止の保証ではありません。必要データだけを送り、検出漏れ、tokenのlinkability、再識別鍵・mapping、quasi-identifier、ログ／cache、出力側を別々に管理します。可逆tokenの復元はLLMから分離した認可済み境界で行います。」

## Scope
deterministic tokenはjoinや会話内coreferenceを維持できますが、同一tokenが広いdataset/session/tenantで再利用されるほどlinkabilityが増えます。必要な相関範囲にtoken scopeを限定し、tenant・purpose・dataset・session等のcontextを設計します。Google Cloudのcontext tweakは同じ入力のtoken相関範囲を変える実装例です。

## Confirmed

## UNKNOWN
- EA-277-UNKNOWN-01: 組織のdata classification、対象法域・purpose、provider data handling、entity taxonomy、detector/version/threshold、custom recognizer、token scope、reversibility要件、KMS/key rotation、token-map retention、re-identification approver、trace/cache policy、quasi-identifier risk、tenant realized behaviorは未確認です。

## Evidence
- EA-277-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応
- EA-277-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合

## Failure / limits
detector false negativeでPII/secretがそのまま送信される。
## Failure / limits
detector false positiveで業務意味を破壊する。
## Failure / limits
deterministic tokenの広域再利用でcross-session/cross-tenant linkabilityが生じる。
## Failure / limits
reversible tokenとkey/mapが同じtrust boundaryへ漏れる。
## Failure / limits
token形式・placeholderから元entity typeや関係が推測される。
## Failure / limits
FPEで形式を保つことを匿名性と誤認する。
## Failure / limits
plain hashを低entropy identifierへ使いdictionary/brute-force再識別される。
## Failure / limits
masking後のquasi-identifiersの組合せで再識別される。
## Failure / limits
output側でmodelが入力外のsensitive informationを生成・再露出する。
## Failure / limits
logging/trace/cacheにpre-mask plaintextが残る。
## Failure / limits
token mapのretention/deletionと原データのlifecycleがずれる。
## 公開claim
LLMへ送信する前のmasking/tokenizationは、機微データ露出を減らすための一つのcontrolです。ただし「token化したから匿名」「PII detectorを通したから漏えいしない」とは扱いません。検出、変換、token scope、鍵、再識別権限、LLM送信、出力後の復元を別境界として管理します。

## 変換方式を区別する
- Redaction: 値を削除する。復元不要だがutilityを失い得ます。
- Masking/replacement: `***` や型付きplaceholderへ置換する。元値の復元情報を別途持つ方式と持たない方式を区別します。
- Pseudonymization/tokenization: 元値をtokenへ置換します。方式によってreversible/irreversible、deterministic/non-deterministic、referential integrityの性質が異なります。
- Encryption-based token: 鍵と必要metadataがあれば再識別可能です。token自体を匿名データとみなしません。
- Hash-based token: one-wayでも、入力空間が小さい・推測可能・salt/key設計が弱い場合は再識別リスクが残ります。

Google Cloud Sensitive Data ProtectionはAES-SIV deterministic encryption、format-preserving encryption、HMAC-SHA-256等を区別し、reversibilityとreferential integrityの性質が異なります。FPEは形式互換性に有用ですが、同資料はAES-SIV等よりsecurity guaranteeが少ない点も明示しています。

## Pre-LLM pipeline
1. data classificationとpurposeを確定する。
2. LLMに不要なfield/segmentを送らない。
3. detectorで対象entityを抽出する。
4. entity/classごとにredact/mask/tokenize/encryptを選択する。
5. 変換後payloadを再scanし、未変換・secret・quasi-identifierを検査する。
6. LLM/providerへは変換後payloadだけを送る。
7. 応答側もsensitive outputを検査する。
8. re-identificationが必要な場合はLLMとは分離したtrusted boundaryで、認可・purpose・auditを確認して限定復元する。

## Detectorは完全ではない
PII検出は確率的・rule-based detector、辞書、regex、NER等に依存し、false negative/false positiveがあります。Presidioの文書も自動検出が全機微情報を見つける保証はないとしています。したがってdetector PASSを「機微情報なし」の証明にしません。domain-specific identifier、free text、secret、組合せで個人を識別できるquasi-identifierを別途扱います。

## Token scope
deterministic tokenはjoinや会話内coreferenceを維持できますが、同一tokenが広いdataset/session/tenantで再利用されるほどlinkabilityが増えます。必要な相関範囲にtoken scopeを限定し、tenant・purpose・dataset・session等のcontextを設計します。Google Cloudのcontext tweakは同じ入力のtoken相関範囲を変える実装例です。

## Re-identification boundary
可逆tokenのkey/token map/deanonymization metadataはLLM context、prompt、tool output、traceへ入れません。復元serviceはleast privilege、purpose check、actor、対象field、request/result locatorを監査します。LLMが任意tokenを指定して復元できるtoolを無制限に与えません。

## Failure envelope
- detector false negativeでPII/secretがそのまま送信される。
- detector false positiveで業務意味を破壊する。
- deterministic tokenの広域再利用でcross-session/cross-tenant linkabilityが生じる。
- reversible tokenとkey/mapが同じtrust boundaryへ漏れる。
- token形式・placeholderから元entity typeや関係が推測される。
- FPEで形式を保つことを匿名性と誤認する。
- plain hashを低entropy identifierへ使いdictionary/brute-force再識別される。
- masking後のquasi-identifiersの組合せで再識別される。
- output側でmodelが入力外のsensitive informationを生成・再露出する。
- logging/trace/cacheにpre-mask plaintextが残る。
- token mapのretention/deletionと原データのlifecycleがずれる。

## SAFE_WORDING
「LLM前のmasking/tokenizationは機微データ露出を減らすcontrolであり、匿名化や漏えい防止の保証ではありません。必要データだけを送り、検出漏れ、tokenのlinkability、再識別鍵・mapping、quasi-identifier、ログ／cache、出力側を別々に管理します。可逆tokenの復元はLLMから分離した認可済み境界で行います。」

## OPEN_UNKNOWN
組織のdata classification、対象法域・purpose、provider data handling、entity taxonomy、detector/version/threshold、custom recognizer、token scope、reversibility要件、KMS/key rotation、token-map retention、re-identification approver、trace/cache policy、quasi-identifier risk、tenant realized behaviorは未確認です。

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.