AIガバナンス実践 - 生成AIコネクタのデータ漏洩リスクと実務対策

AI社会実装勉強会第59回 (https://machine-learning-workshop.connpass.com/event/395133/) の発表資料です。

Transcript

1. AIガバナンス実践 生成AIコネクタのデータ漏洩リスクと実務対策 社内ルール × 独自MCPサーバ × 既存ベストプラクティス 西岡賢一郎 Data Informed CEO/D-stats CTO/NOBULL AI CTO 2026年5月30日 AI社会実装勉強会第59回
2. イ ン ト ロ ダ ク シ ョ ン 本日の流れ ＆ キーワード 本日の流れ 1 ある会社で実際に起きたこと 2 なぜ防げなかったのか 3 同じことが起きる「5つの構造」 4 解決の道筋 — 3層で守る 5 明日からのアクション 本日のキーワード Key Terminology ◆ Lethal Trifecta 致命的三要素 ★ 本日の核心 ◆ Indirect Prompt Injection 間接プロンプトインジェクション ◆ Identity Dilution アイデンティティの希釈 ★ 必修 ◆ Shadow AI シャドウAI ◆ MCP Model Context Protocol AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 2 / 24
3. 第 1 幕 : 問 題 の 発 見 ある会社で実際に起きたこと 2025年8月、Black Hat で実演された攻撃 "AgentFlayer" ① 社員Aが取引先からPDFを受け取り、ChatGPTで要約 ② 数秒後、AIがGoogle Driveを検索（社員は何もしていない） ③ AIがDrive内のAPIキー（クラウド認証情報）を発見、画像URLにこっそり埋め込んで送信 ④ 攻撃者のサーバにAPIキー到着 社員は1クリックもしていない ( Zero-Click Attack ) AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 3 / 24
4. 第 1 幕 : 問 題 の 発 見 なぜ防げなかったのか — Lethal Trifecta Simon Willison (2025年6月) "The Lethal Trifecta" — AIエージェントの致命的三要素 ① 機密データへのアクセス Access to Private Data ② 信頼できない入力 Untrusted Content ③ 外部送信能力 External Communication 3要素が同時に揃ったエージェントは、構造的に脆弱 — モデルの安全性強化では防げない AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 4 / 24
5. 第 1 幕 : 問 題 の 発 見 Lethal Trifecta — 実例と「あなたの会社は?」 AgentFlayer ① Google Drive 連携 = 機密データへのアクセス ② PDFに仕込まれた隠し命令 = 信頼できない入力 ③ ChatGPT の画像URL 生成機能 = 外部送信能力 EchoLeak ① OneDrive データアクセス = 機密データへのアクセス ② 攻撃者のメール本文の命令 = 信頼できない入力 ③ Copilot の画像レンダリング = 外部送信能力 あなたの会社の Claude / ChatGPT / Copilot は、 デフォルトでこの3要素を全部満たしていませんか? 「Drive つなぎました」「Slack つなぎました」「メール もつなぎました」 これが Lethal Trifecta そのもの。便利になるほど、自動的に揃ってしまう。 AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 5 / 24
6. 第 2 幕 : 構 造 の 理 解 5つの「あるある」パターン — 全体像 皆さんの組織にも、おそらく既に存在する5パターン ─ これから1枚ずつ深掘りします パターン A Shadow AI ( うっかり入力型 ) 社員が機密データをAIに入 力 → Slide 7 パターン B OAuth Over- Permissioning ( 過剰権限 ) コネクタ有効化で全Drive参 照可 → Slide 8 パターン C Drive Permission Sprawl ( 共有の連鎖 ) 過去の共有ミスをAIが顕在 化 → Slide 9 パターン D Indirect Prompt Injection ( 読んだら実行 ) メールやPDFの隠し命令で 漏洩 → Slide 10 パターン E MCP Supply Chain Attack ( 信頼の裏切り ) 悪意あるMCPサーバが流通 → Slide 11 AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 6 / 24
7. 第 2 幕 ・ パ タ ー ン A Shadow AI — 社員のうっかり入力 「現場の声」 "バグ解決のためにソースコード貼った" / "急いでたから議事録を要約させた" 代表事例: Samsung Semiconductor (2023年3月) ChatGPT 解禁から たった 20日 で 3件 の機密漏洩 1人目 半導体設備の測定DBに関するソースコードを貼 り付け デバッグ目的 2人目 不良検出・歩留まり最適化のコードを最適化さ せた 効率化目的 3人目 社内会議の音声をテキスト化して議事録要約 業務迅速化目的 3人とも悪意はない。仕事を早くしたかっただけ。 → Samsung は全社的に ChatGPT 利用を一旦停止 AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 7 / 24
8. 第 2 幕 ・ パ タ ー ン B OAuth Over-Permissioning — 過剰権限 「現場の声」 "Drive つないだら、自分の全ファイルがAIから見える状態だった" ユーザのアクション 「Drive コネクタを 有効にする」 → その瞬間に発生 編集権限を持つ 全Driveファイルが AIから読み取り可能 = Lethal Trifecta の ①「機密データへのアクセス」 が自動的に成立 ユーザは「このファイルを使ってください」と一度も指示していないのに AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 8 / 24
9. 第 2 幕 ・ パ タ ー ン C Drive Permission Sprawl — 共有の連鎖 「現場の声」 "5年前にうっかり共有したファイルが、AI検索でいきなりヒット" 5年前 プロジェクトで「ちょっとだけ共有」 4年前 プロジェクト終了、共有解除を忘れる 今日 AIに「四半期業績は?」と質問 次の瞬間 5年前のスプレッドシートが要約結果に登場 AI がやっているのは「共有」ではない。 「過去の共有設定ミスを、検索可能な形で可視化」しているだけ。 AI 導入で情報が漏れたのではない ─ AI 導入で、すでに露出していた情報が見えるようになった AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 9 / 24
10. 第 2 幕 ・ パ タ ー ン D Indirect Prompt Injection (IPI) — 読んだら実行 「現場の声」 "メールを開いただけで、情報が漏れた" AgentFlayer ChatGPT + Drive 2025年8月 EchoLeak Microsoft 365 Copilot 2025年 Slack AI IPI Slack AI 2024年 Slack AI のシナリオ: ① 攻撃者が、公開チャネルに人間には意味不明な隠し命令を投稿 ② 別社員がSlack AI に「最近のプロジェクトの状況」を質問 ③ AI が要約のために公開チャネルを取り込み、隠し命令が発動 ④ 別社員のプライベートチャネル情報が、攻撃者の元へ送信 攻撃者は、被害者のいるチャネルにすら入っていない。 Lethal Trifecta が直接発現する形。 AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 10 / 24
11. 第 2 幕 ・ パ タ ー ン E MCP Supply Chain Attack — 信頼の裏切り 「現場の声」 "便利だと思って入れたMCPが、後から悪意ある版に置換されていた" 代表事例: Postmark MCP 事件 (2025年9月) ① 本物の Postmark （メール送信サービス）に似せた偽のMCPサーバが npm に公開 ② OSS コミュニティで「便利」として導入が広がる ③ 表面上はメール送信機能を提供 — しかし裏で全送信メールを攻撃者にBCC ④ 何週間も誰も気づかず、機密メールが流出し続けた MITRE ATLAS に実例（ケース AML.CS0053）として登録された脅威 「便利そうだから入れる」が、もう許されない時代へ AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 11 / 24
12. 第 2 幕 ・ 構 造 の 理 解 隠れた敵 — Identity Dilution よくある対策 「危ないから、専用のBotアカウントを作って、 それ経由でAIを使わせよう」 ✓ OAuth scope を限定 ✓ 特定チャネルにだけ招待 「これで安全だよね？」 でも… → 落とし穴 全員が同じBotで操作 ↓ 監査ログ上、すべて「ABC Bot」がやったと記録 ↓ 田中さんが機密取得しても、鈴木さんと区別がつかない これが Identity Dilution アイデンティティの希釈 解決策: 独自MCP層で "originating_user_id" を必須化 = Identity Propagation (後の Slide 16 で再登場) AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 12 / 24
13. 第 2 幕 → 第 3 幕 へ の 橋 渡 し 解決策の全体像 — 3層で守る 単独施策ではなく、3つの層を組み合わせて初めて機能する 1 レイヤー1: 社内ルール 人 × 文化 × ポリシー "何をしてよいか" の合意 Slide 14 ▼ 2 レイヤー2: 独自MCPサーバ アーキテクチャ × ゲートウェイ "技術的に防御不可能にする" Slide 15-16, 18-20 ▼ 3 レイヤー3: 運用ツール 監視 × DLP × 監査 "起きたら検知・対応する" Slide 17 レイヤー2が本日の技術的核心 ─ Identity Propagation もここに実装される AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 13 / 24
14. 第 3 幕 ・ レ イ ヤ ー 1 社内ルールの作り方 NG 禁止だけのガイドラインは機能しない → OK "使ってよい範囲" を明示する 必須項目 8つ ✓ 適用範囲 ✓ 利用可能ツール（許可リスト） ✓ 入力禁止情報の具体例 ✓ コネクタ運用ルール ✓ 出力物の取り扱い ✓ インシデント窓口 ✓ 違反時の取り扱い ✓ 見直しサイクル（半年〜1年） 効果的にする 5つの工夫 ◆ "禁止" ではなく "OK事例" を示す ◆ 判断に迷う場合の判断基準を可視化 ◆ ハンズオン研修を組み込む ◆ ボトムアップで運用（現場の声を反映） ◆ JDLA・PPC等の公的指針を必ず参照 目標: 社員が「自分で判断できる」状態を作る (= 24時間サポートデスクではない) AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 14 / 24
15. 第 3 幕 ・ レ イ ヤ ー 2 独自MCPサーバ — Before / After 公式コネクタを "自社制御下のゲートウェイ" に置き換える Before — 直結 Claude → Drive / Gmail / Slack 問題点: ✗ 監査不能 ✗ OAuth 過剰権限 ✗ 検索結果が直接 LLM へ ✗ 誰の操作か追跡不能 → 置き換え After — 独自MCP経由 Claude ↓ 独自MCP Gateway ✓ PIIマスキング ✓ 監査ログ ✓ ポリシー判定 ✓ Identity Propagation ↓ Drive / Gmail / Slack AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 15 / 24
16. 第 3 幕 ・ レ イ ヤ ー 2 独自MCPサーバ — 実装の 8原則 業界標準は 7原則 — Identity Propagation を加えて 8原則にすべき 1 OBO 認証 On-Behalf-Of ユーザーの代理で動く認証パターン 2 短命トークン Short-lived Token 有効期限を短くし、漏洩時の被害を 最小化 3 ツール許可リスト Allowlist 許可された操作だけが通る 4 入力サニタイズ Sanitization SaaSから返るデータの隠し命令を検 査 5 全件監査ログ Full Audit Log すべての操作を記録 6 シークレット保護 Secrets Mgmt OAuthトークン等を安全に保管 7 サプライチェーン管理 Supply Chain MCPサーバの依存先を検証 8 Identity Propagation ★ 必須追加項目 ★ 呼び出し元ユーザーID必須化 OSS: Obot / Microsoft MCP Gateway / Pomerium / Docker MCP Gateway / Lunar.dev MCPX 商用: MintMCP (SOC 2 Type II) AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 16 / 24
17. 第 3 幕 ・ レ イ ヤ ー 3 既存ベストプラクティス + 支援サービス 車輪の再発明はしない — 既存ツールを組み合わせる 機能層 OSS (3ヶ月で組める) 商用 MCP スキャナー Snyk Agent Scan (旧mcp-scan) Cisco mcp-scanner Lasso Security Prompt Security MCP ゲートウェイ Obot / Microsoft MCP GW Pomerium / Docker MCP GW Lunar MCPX (Ent.) MintMCP (SOC 2) Lasso Security AI-DLP — Lakera Guard (Check Point傘下) Shadow AI 検知 — Wiz AI-SPM Varonis Atlas ポリシー層 — Stow, Composio ミニマム構成 (3ヶ月) : OSSだけで開始可能 ・ フル構成 (6-12ヶ月) : 商用と組み合わせ AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 17 / 24
18. 第 3 幕 ・ サ ー ビ ス 別 ( 1 / 3 ) Google Drive — drive.readonly → drive.file 現状 (Claude のデフォルト) ▲ drive.readonly + drive.file を同時要求 Google分類で「Restricted」、すなわち 全Driveファイル参照可能 ユーザー側では切り替え不可 — Anthropic側のOAuthクライアント設定に依存 ▼ 独自MCPで物理的に強制制約 推奨設計 ✓ drive.file のみに強制制約 → アプリが作成したファイル、または Picker で明示選択されたファイルのみAIアクセス さらに + Shared Drive + サービスアカウント運用 個人マイドライブの過剰共有問題から完全に切り離す AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 18 / 24
19. 第 3 幕 ・ サ ー ビ ス 別 ( 2 / 3 ) Gmail — 役割分割パターン 1つのエージェントに 3要素を揃えない設計 ─ Lethal Trifecta 成立の構造的阻止 通知送信専用 gmail.send 送信機能のみ、読み取り権限ナシ 例: Slack通知をメールで配信 ①機密データへのアクセス ナシ → Trifecta 不成立 トリアージ用 gmail.metadata ヘッダ・件名のみ、本文や添付は読めない 例: 重要メール抽出・分類 ①は限定的、③送信能力ナシ → Trifecta 不成立 下書き作成用 gmail.compose 下書きはAIが作成、送信は人間 例: 返信案の自動生成 ③送信は人間が押す → Trifecta 不成立 Slide 4 の伏線回収: 「3つすべて断つ必要はない、1つでも断てれば前提が崩れる」 新しい技術は不要 ─ 既存のOAuthスコープを賢く使うだけで実現できる AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 19 / 24
20. 第 3 幕 ・ サ ー ビ ス 別 ( 3 / 3 ) Slack — User Token → Bot Token + 招待制 現状 (Claude のデフォルト) ▲ User Token (xoxp-) を使う実装 そのユーザーが見られる「全範囲」にアクセス可能 全公開チャネル + 招待された全プライベートチャネル + 全DM ▼ Slack APIレベルでハードに制限 推奨設計 ✓ Bot Token (xoxb-) + /invite による招待制 → Bot は、招待された チャネルだけ しか読めない (Slack API レベルで強制) さらに + 独自MCPで Identity Propagation を実装 Slack 監査ログと独自MCP監査ログを、ユーザIDで突合できる状態に AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 20 / 24
21. 第 3 幕 ・ 法 務 個人情報保護法 (PPC) との整合 PPC 2023年6月 注意喚起と自然に整合する設計 ① PPC: 利用目的の範囲内 個人情報の利用は、収集時の目的の範囲内に限る → 本日の対策: (Slide 14) 社内ルール / 利用ツール許可リスト ② PPC: 学習に使われない確認 入力したデータがLLMの学習に転用されないこと → 本日の対策: Enterprise契約 / Anthropic DPA ③ PPC: 要配慮個人情報は同意必要 医療情報・センシティブデータは事前同意が必須 → 本日の対策: (Slide 15, 18) 専用Mailbox / PIIマスキング / Shared Drive分離 JDLA生成AIガイドラインも参照: PPC指針と組み合わせると、社外への説明責任が格段に楽になる AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 21 / 24
22. ク ロ ー ジ ン グ 明日からのアクション 3つの時間軸でアクションに落とし込む P0 明日から コストゼロ・即実行 社内 Claude / ChatGPT コネクタの棚卸し （誰が、何スコープで） Enterprise 契約への切替確認 snyk-agent-scan を 情シスPC配布 P1 来月から 1ヶ月以内に着手 最小限ガイドラインの公開（社内） Drive スコープを drive.file に変更 Slack を Bot Token ベースに切替 P2 来期から 3-12ヶ月の計画 OSS MCP Gateway の PoC 開始 AI-DLP / Shadow AI 検知ツール導入検討 監査ログ集約と SIEM 統合 このスライドは持ち帰り可能な形（A4チェックリスト）で配布します AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 22 / 24
23. コネクタを "禁止" するのではなく、 "統制された経路でしか接続できない状態" を作る。 Lethal Trifecta は、構造の話です。モデルの安全性強化では解決できません。 最小権限 × 分離 × 監査 —— セキュリティの古典3原則を、AI時代に再実装することが、ゴールです。
24. ク ロ ー ジ ン グ Q&A ＆ 参考資料 Q & A ご質問をどうぞ 参考資料 / References 日本国内 ガイドライン • PPC 注意喚起 (2023.6) • JDLA 生成AI利用ガイドライン • 東京都デジタルサービス局ガイドライン 国際 セキュリティ標準 • Simon Willison "The Lethal Trifecta" (2025.6) • OWASP Top 10 for LLM • OWASP MCP Top 10 / MAESTRO (CSA) • MITRE ATLAS (AML.T0109 / CS0053) 技術仕様 / 調査研究 • Anthropic MCP 仕様 • Google Drive / Gmail / Slack 各 API スコープ仕様 • IBM Cost of a Data Breach 2025 • Snyk Agent Scan / Invariant Labs 研究 AIガバナンス実践 — 生成AIコネクタのデータ漏洩リスクと実務対策 24 / 24