モデル Privacy Attack 評価／Membership 推論／Inversion／Extraction

学習済みAIモデルは、通常の推論APIとして提供されていても、学習データへの参加有無を推定するmembership inference、学習データの属性・代表情報を推定するmodel inversion/reconstruction、target modelの機能や知的財産を複製するmodel extraction/model theftの対象になり得る。これらは目的・必要アクセス・成功指標が異なるため、同じ「情報漏えい」として一括評価しない。NIST AI 100-2e2025は攻撃をlife-cycle stage、attacker goals/objectives、capabilities、knowledgeで区別し、predictive AIとgenerative AI双方のprivacy attackをtaxonomyへ含めている。OWASP Secure AI Model Opsもmembership inference、model inversion、model extraction/theftを別脅威として扱う。

評価開始前にthreat modelを固定する。black-box / gray-box / white-box、query budget、confidence/logit/probabilityの可視性、training distributionへの補助知識、shadow model利用可否、model/version、fine-tuning・ICL・RAG等の適応方式を記録する。同一モデルでも出力surfaceと攻撃者知識が変わればattack feasibilityは変わる。

Membership inferenceは「特定recordが学習集合に含まれたか」を推定する。accuracyだけでなくTPR/FPR、ROC/PR、低FPR領域、base rate、sample/cohort別riskを確認する。aggregate scoreだけでは希少recordや高リスクcohortを隠し得る。

Model inversion/reconstructionは「学習データについて何が回収できるか」を測る。もっともらしい生成物と実recordの復元を区別し、ground truthを持つ安全な評価datasetで一致度、sensitive attribute recovery、false reconstruction、第三者データとの混同を検証する。

Model extraction/theftはfunctional imitation、parameter/weight theft、artifact exfiltrationを分ける。task fidelity、agreement、transferability、query cost、対象機能範囲等を目的に応じて測り、単なる大量queryとweight窃取を同一成功条件にしない。

• training/fine-tuning dataを分類し、秘密・個人情報・契約制約を持つrecordの投入条件を別管理する。
• model/APIごとに公開する出力surfaceを最小化し、不要なlogit/probability、debug trace、embedding、内部stateを外部へ露出しない。
• authentication、authorization、per-principal quota、rate limit、burst/query-pattern monitoringをendpointへ適用する。
• release前と重大model/data変更後にprivacy red-teamを行い、membership / inversion-reconstruction / extractionを別test suiteとして保持する。
• artifactにはmodel hash/version、dataset version、attack implementation/version、threat model、query budget、random seed、metric definitionを保存する。
• sensitive cohortやoutlierについてsample-level riskを確認し、aggregate scoreだけでrelease判断しない。
• output filteringやconfidence suppressionだけを万能防御とみなさず、adaptive attackerで再評価する。
• model extraction対策ではaccess control、rate limiting、anomaly detection、contract/licensing control、model provenance/fingerprintingを組み合わせる。
• incident時にaffected model/data lineage、exposed endpoint、query logs、credential/principalを追跡できるようprovenanceとloggingを保持する。

Differential Privacy (DP) はprivacy lossを数学的に定義する枠組みだが、「DPを使用」とだけ記録して安全とみなさない。NIST SP 800-226は、実装されたDP保証を評価する際に複数要素とprivacy hazardsを確認する必要があると整理している。epsilon/delta、adjacency、privacy unit、accounting、sampling、composition、実装条件を保証の一部として保存する。DPはすべてのmodel theftや全種類のinversionを自動的に解決するものではないため、守るassetとattack objectiveを先に定義する。

評価でattackが失敗してもprivacy safeとは断定しない。attack implementationが弱い、query budgetが小さい、attacker knowledgeを過小評価した、特定cohortのriskを平均で隠した可能性がある。逆に研究上の強いattack成功率を、そのまま自社modelの実被害確率として扱わない。

black-box red-teamは実運用に近いが、内部アクセスを得た攻撃者やsupply-chain compromiseを代表しない。white-box testは強い上限評価に使えるが、現実のattacker capabilityを過大評価する場合がある。両者をthreat model別に保存する。

privacy defenseにはprivacy-utility trade-offがあり得る。confidence suppression、regularization、DP training等を採用する場合も、privacy metricとutility/safety metricを同時に測る。

「このモデルはmembership inferenceに耐性がある」と一般化せず、「指定したmodel/version、dataset、attack suite、attacker knowledge、query budget、output surfaceでは、測定したriskが所定threshold内だった」と記述する。「DPを使っているため情報漏えいしない」「rate limitがあるためmodel extractionできない」「一つのattack benchmarkに失敗したためprivacy保証がある」とは記述しない。保証範囲、仮定、未評価attack、残余riskを併記する。

• 対象model/versionで、record rarityやsensitive cohortごとのmembership riskがどの程度異なるか。
• fine-tuning、ICL、RAG、agent memoryごとにtraining-context leakageの境界をどう切るか。
• 実運用APIのrate limitとmonitoringがadaptive extraction attackerの経済性をどこまで変えるか。
• output filtering/confidence suppressionが別attackへriskを移すか。
• DPを採用する場合のprivacy unit、epsilon/delta、composition budget、utility threshold。
• model fingerprint/watermarkが改変・distillation・quantization後もどの程度帰属証拠として残るか。
• provider-hosted closed modelで、顧客側が検証可能なprivacy evidenceの最小集合。