{
  "format": "agent-article-v0",
  "article_id": "EA-1205",
  "canonical_url": "/tools/ea-1205-model-privacy-attack-evaluation-membership-inference-inversion-e",
  "page_type": "reference",
  "claim_ids": [],
  "evidence_ids": [
    "EA-1205-CURRENT-APPROVAL",
    "EA-1205-CURRENT-BODY-READBACK"
  ],
  "unknown_ids": [
    "EA-1205-UNKNOWN-01"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "CURRENT",
  "observation_status": "SPEC_ONLY",
  "freshness": "CURRENT",
  "last_verified": "2026-10-19",
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "EA1205-CANDIDATE-20261019-2314JST-C2",
    "BODY-SHA256:08f937b6546c36708c542e24d86485391d27a2999ea1ecd1cf99a83c1529323c"
  ],
  "article_sources": [
    {
      "id": "EA-1205-CURRENT-APPROVAL",
      "evidence_class": "RESEARCH",
      "title": "現行本文の監査・revision対応",
      "supports": [
        "現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。"
      ],
      "limit": "監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "EA1205-CANDIDATE-20261019-2314JST-C2"
      ],
      "supporting_locators": [
        "1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ/EA_REVISION_LEDGER#ea_id=EA-1205&revision_id=EA-1205-FIRST-20261019-C2&candidate_id=EA1205-CANDIDATE-20261019-2314JST-C2",
        "EA-1205-FIRST-20261019-C2"
      ],
      "provenance_status": "CURRENT_CANONICAL_APPROVAL_READBACK"
    },
    {
      "id": "EA-1205-CURRENT-BODY-READBACK",
      "evidence_class": "IMPL",
      "title": "現行本文の収録照合",
      "supports": [
        "公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。"
      ],
      "limit": "本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。",
      "checked_at": "2026-10-19",
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "BODY-SHA256:08f937b6546c36708c542e24d86485391d27a2999ea1ecd1cf99a83c1529323c"
      ],
      "supporting_locators": [
        "content/staging/EA-1205.md",
        "08f937b6546c36708c542e24d86485391d27a2999ea1ecd1cf99a83c1529323c",
        "EA-1205-FIRST-20261019-C2"
      ],
      "provenance_status": "CURRENT_APPROVED_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "PUBLIC_CLAIM",
      "text": "学習済み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を別脅威として扱う。"
    },
    {
      "heading": "評価境界",
      "text": "評価開始前に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は変わる。\n\nMembership inferenceは「特定recordが学習集合に含まれたか」を推定する。accuracyだけでなくTPR/FPR、ROC/PR、低FPR領域、base rate、sample/cohort別riskを確認する。aggregate scoreだけでは希少recordや高リスクcohortを隠し得る。\n\nModel inversion/reconstructionは「学習データについて何が回収できるか」を測る。もっともらしい生成物と実recordの復元を区別し、ground truthを持つ安全な評価datasetで一致度、sensitive attribute recovery、false reconstruction、第三者データとの混同を検証する。\n\nModel extraction/theftはfunctional imitation、parameter/weight theft、artifact exfiltrationを分ける。task fidelity、agreement、transferability、query cost、対象機能範囲等を目的に応じて測り、単なる大量queryとweight窃取を同一成功条件にしない。"
    },
    {
      "heading": "IMPLEMENTATION_CONTROLS",
      "text": "- training/fine-tuning dataを分類し、秘密・個人情報・契約制約を持つrecordの投入条件を別管理する。\n- model/APIごとに公開する出力surfaceを最小化し、不要なlogit/probability、debug trace、embedding、内部stateを外部へ露出しない。\n- authentication、authorization、per-principal quota、rate limit、burst/query-pattern monitoringをendpointへ適用する。\n- release前と重大model/data変更後にprivacy red-teamを行い、membership / inversion-reconstruction / extractionを別test suiteとして保持する。\n- artifactにはmodel hash/version、dataset version、attack implementation/version、threat model、query budget、random seed、metric definitionを保存する。\n- sensitive cohortやoutlierについてsample-level riskを確認し、aggregate scoreだけでrelease判断しない。\n- output filteringやconfidence suppressionだけを万能防御とみなさず、adaptive attackerで再評価する。\n- model extraction対策ではaccess control、rate limiting、anomaly detection、contract/licensing control、model provenance/fingerprintingを組み合わせる。\n- incident時にaffected model/data lineage、exposed endpoint、query logs、credential/principalを追跡できるようprovenanceとloggingを保持する。"
    },
    {
      "heading": "Differential Privacyの位置づけ",
      "text": "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を先に定義する。"
    },
    {
      "heading": "FAILURE_ENVELOPE",
      "text": "評価でattackが失敗してもprivacy safeとは断定しない。attack implementationが弱い、query budgetが小さい、attacker knowledgeを過小評価した、特定cohortのriskを平均で隠した可能性がある。逆に研究上の強いattack成功率を、そのまま自社modelの実被害確率として扱わない。\n\nblack-box red-teamは実運用に近いが、内部アクセスを得た攻撃者やsupply-chain compromiseを代表しない。white-box testは強い上限評価に使えるが、現実のattacker capabilityを過大評価する場合がある。両者をthreat model別に保存する。\n\nprivacy defenseにはprivacy-utility trade-offがあり得る。confidence suppression、regularization、DP training等を採用する場合も、privacy metricとutility/safety metricを同時に測る。"
    },
    {
      "heading": "SAFE_WORDING",
      "text": "「このモデルは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を併記する。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- 対象model/versionで、record rarityやsensitive cohortごとのmembership riskがどの程度異なるか。\n- fine-tuning、ICL、RAG、agent memoryごとにtraining-context leakageの境界をどう切るか。\n- 実運用APIのrate limitとmonitoringがadaptive extraction attackerの経済性をどこまで変えるか。\n- output filtering/confidence suppressionが別attackへriskを移すか。\n- DPを採用する場合のprivacy unit、epsilon/delta、composition budget、utility threshold。\n- model fingerprint/watermarkが改変・distillation・quantization後もどの程度帰属証拠として残るか。\n- provider-hosted closed modelで、顧客側が検証可能なprivacy evidenceの最小集合。"
    }
  ],
  "human_url": "/tools/ea-1205-model-privacy-attack-evaluation-membership-inference-inversion-e",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-1205-model-privacy-attack-evaluation-membership-inference-inversion-e",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-1205-model-privacy-attack-evaluation-membership-inference-inversion-e"
}