脅威をモデリングしてMCPのセキュリティ対策を考えよう

1. 脅威をモデリングして
 MCPのセキュリティ対策を考えよう 2025/06/17 - MCP導入における脅威モデリングのすゝめ GMO Flatt Security株式会社 Norihide Saito / Azara
2. 自己紹介 講演・コミュニティ活動 名前 Norihide Saito / Azara 所属 国内 JPCERT/CC JSAC 2024 登壇・ベストスピーカー賞 国内 BSides Tokyo 2024 登壇 国内 SECCON 2022 Domestic 国内 ISOG-J ワーキングループ1での活動 国内 CloudSec JP Organizer その他 Cloud Security expert of GMO internet group 国際 国際 AWS Community Builder - Security 国外 BSides Las Vegas 2024 登壇
3. Our Mission エンジニアの背中を預かる より多くのエンジニアがものづくりに集中できる社会を、 セキュリティ面からつくる会社
4. 脆弱性診断・ペネトレーションテストを プロフェッショナル / SaaSで多角的に提供 手動・高度診断 コード・仕様の分析も行い、 専門家が脆弱性を網羅的に発見 自動・継続診断 クラウド・Webアプリをまるごと 継続的に診断するSaaS 提供サービス 提供サービス
5. MCPを対象にした診断(プロフェッショナルサービス)
6. 本発表について 弊社の を補足するお話をします 実質書き下ろしです。 MCPにおけるセキュリティ考慮事項と実装における観点
7. 本発表はこのような人を想定して作っています 生成AIを用いた ソフトウェアを作る人 生成AI関連の
 セキュリティを学ぶ人 AIを育てるすべての人たちへ 生成AIを用いた ソフトウェアを守る人
8. 本発表の目的 1 MCPやそれらを取り巻くセキュリティ課題を理解する 2 脅威がどこに存在するかを理解し、
 適切なセキュリティ施策をとれるようにする 3 MCPサーバーをプロダクトとして提供する際の
 セキュリティ施策や認可・権限について理解する 4 MCPとその周辺の脅威やリスクを理解する
9. 本発表の目的 まったくわからん... ↓ (周辺のセキュリティ対策を調べるとっかかりを得られた状態) すこしわかる
10. 目次 1 MCPにおけるセキュリティ 2 脅威のモデリングと開発現場へのセキュリティFB 3 自社プロダクトとして提供 4 まとめ + おまけ
11. 01 MCPにおけるセキュリティ
12. MCP周辺の全体像 MCP Spec Client Server Host LLM 外部リソース 内部リソース 内部のファイルやソフトウェア、コマンドの操作など
13. MCPと周辺におけるセキュリティ課題の大別 MCP Serverにおける リスク・脅威 利用における リスク・脅威 MCP Host + Clientにおける リスク・脅威 (生成AI Application)
14. MCP Host + Clientにおけるリスク・脅威 MCP Host + Clientにおける リスク・脅威 ※正確には生成AI Application全般におけるリスク・脅威 攻撃者の目的 攻撃者による 生成AIアプリの制御と ツールへのアクセス 情報の抜き取りや機能の悪用など
15. MCP Host + Clientにおけるリスク・脅威 MCP Host + Clientにおける リスク・脅威 ※正確には生成AI Application全般におけるリスク・脅威 1 意図しないプロンプトの注入 2 ツール利用における 混乱・意図しない実行 3 攻撃者による 生成AI Applicationの恒久的制御 手段の一例
16. MCP Host + Clientにおけるリスク・脅威 生成AIアプリケーション (MCP Host +MCP Client) 悪性のMCP Server MCP Server - A 攻撃の一例 1 3 4 5 2 ６ 悪意のあるプロンプトの注入 1 Init時に悪性のMCP Serverに接続 2 Init時に悪意のあるプロンプトを返却 3 悪意のあるプロンプトをLLMへ入力 ４ 本来アクセスをしたくない/させたくない MCP Serverのツールを実行を指示 ※図の場合は、MCP Server - Aへアクセス後にその結果を悪性のMCP Serverへ送るように指示 5 通常の処理 6 結果を悪性のMCP Serverに送信
17. MCP Serverにおけるリスク・脅威 攻撃者の目的 MCP Serverにおける リスク・脅威 攻撃者による ツールの悪用 + 付与された権限の悪用
 または、権限の付与された認証情報の取得
18. MCP Serverにおけるリスク・脅威 MCP Serverにおける リスク・脅威 1 認可制御の不備 2 権限の過剰付与と
 権限の取り扱いに関する設計不備 3 設定や実装の不備を悪用 →単純な設定ミスやOWASP Top 10などの脆弱性 手段の一例
19. MCP Serverにおけるリスク・脅威 MCP Server 攻撃の一例 認可制御の不備と不正な操作 1 リモートに公開されている MCP Serverへ未認証状態のアクセス 2 検証を行わず操作を行うことが可能 3 操作の結果 クラウドサービスなどを操作する 1 2 3
20. 利用や統合におけるリスク・脅威 攻撃者の目的 利用や統合における リスク・脅威 一つのシステムとしての 脆弱性を用いて
 攻撃者の制御下におく
21. 利用や統合におけるリスク・脅威 1 データの汚染による 間接プロンプトインジェクション 2 自動化を想定した際の Notificationの副作用 2 複数のMCP Serverが
 存在する場合の悪性相互作用 利用や統合における リスク・脅威 手段の一例
22. 利用や統合におけるリスク・脅威 1 データの更新されたことをMCP Serverに伝達 悪性のプロンプトが含まれる 2 Notificationを基にデータを取得 3 悪意のあるプロンプトをLLMへ入力 ４ 悪意のある制御やツールの悪用を指示 5 ツール実行などが”常に許可”であることによる 攻撃者による生成AIアプリの制御 データ汚染もとのアプリを起点に 生成AIアプリを攻撃者が完全な制御下に 生成AIアプリケーション (MCP Host +MCP Client) Backend API MCP Server 攻撃の一例 3 5 4 1 2 Notificationを用いた自動化と
 データ汚染による
 間接プロンプトインジェクション
23. このような課題を設計や実装で解決するためには？ 1 システム全体像の把握と資産の整理 → “誰(操作主体)”が”なに(資産)”を”どのように(操作)”するかを明確にする 2 自社の制御下に何があり、制御できないものの整理 → “制御できるもの”と”できないもの”を切り分け、個別に施策を練る 3 取り巻く脅威と考えられる侵入経路の把握 自身がMCPに関連する何かを提供する際に、顧客や情報を守るため に”設計”や”実装”レベルで対策できることはなんなのだろうか？
24. 設計や実装、ドキュメントで解決するためには？ 自社の制御下に存在する
 資産保護の対策・施策 MCPサーバーやAI Agentの機能レベルの
 設計や実装のセキュリティ対策・要件の定義 利用者の端末や 想定される利用用途におけるリスクの低m › 機能レベルの設計や実装より少し幅を広げてセキュリティに関する設計・実u › ドキュメンテーションや必要な権限セットの列挙などベストプラクティスの定義
25. 章まとめ 1 MCPのリスク・脅威としているが実状は
 Webアプリケーションと同様のリスク・脅威と近しい 2 単一では脅威度が低いものでも、
 利用の仕方によっては脅威となるものが存在する →自動化された生成AIアプリケーション + 汚染されたデータを基にしたプロンプ トインジェクションと攻撃者による制御のような例 3 実装で対応できるものと、そうでないものが存在する →「ツール実行時に確実に操作者の許可を求める」や「同時に利用するMCP Serverの制約」などの、現時点では「運用でカバー」のような対応になるものが 存在する
26. 02 脅威のモデリング -
 AIがアクセスできる情報源 / リソース
27. 脅威をモデリングする際の要点 1 脅威のモデリングにおいて大切なことと考え方 2 設計において権限と認可の所在を認識 3 意図しないリソース汚染の可能性の確認 4 機微情報の所在を認識 5 人間の介在を要するかの確認
28. MCPなどのシステムで脅威をモデリングする意義 利用者の要求 提供者として r MCP Serverであっても、
 Webをベースとしたプロダクトと同じ水準でのセキュリティを求めB r セキュア・バイ・デフォルトを求める時代 r セキュリティインシデントはどのようなものであっても、
 プロダクトや会社の信頼や信用を貶めてしまう恐れがある どこから始めるかを見極めるために”脅威をモデリング”が有効
29. 特に生成AIアプリ(MCPも含む)は重要 新しい技術 + 未知のセキュリティリスクを 発見しやすくする ※ここで言う「未知 」は「ベストプラクティスやリスクが整理され公にされていない状況」 攻撃者にも 柔軟で従順なLLMだからこそ脅威を把握したい
30. 脅威をモデリングする術を知る 手法は色々あるけど... 手段を知るより、
 根本的な価値観や考え方を大事に STRIDE PASTA VAST SQUARE
31. 何を大切にすればいいんだろうか？ 1 チェックシート 問題発見と修正する文化 よりも → 手段と目的を逆転させない 2 プロセス・
 方法論・ツール 話し合いや理解 よりも →対話をもとに妥協点や解決を探る 3 セキュリティやプライバシー について理解する旅である →自分事にとらえ咀嚼して理解する 4 脅威を理解可能なモデル を話すのではなく にする →誰もが理解できるものに落とし込む 脅威の詳細 5 ではなく を ♻️継続的に改良 →セキュリティや製品、状況の変化に柔軟に対応する 一度
32. 脅威をモデリングする意義を原則から改めて考える 1 最も効果的な活用方法は 早期かつ頻繁な分析を通したシステムのセキュリティ向上 2 開発組織のやり方に合わせてシステム変更のたびに
 変化に合わせて、扱いやすい対象範囲に絞って実施すべき 3 モデリングされた成果物は関係者がセキュリティにおいて 「役にたつ」と感じたときに意味をなす 4 関係者と共通認識をつくり、その認識を文章化する 結果として効果や進捗を測ることができる https://www.threatmodelingmanifesto.org/#principles
33. 脅威をモデリングする意義を原則から改めて考える 1 最も効果的な活用方法は 早期かつ頻繁な分析を通したシステムのセキュリティ向上 2 開発組織のやり方に合わせてシステム変更のたびに
 変化に合わせて、扱いやすい対象範囲に絞って実施すべき 3 モデリングされた成果物は関係者がセキュリティにおいて 「役にたつ」と感じたときに意味をなす 4 関係者と共通認識をつくり、その認識を文章化する 結果として効果や進捗を測ることができる https://www.threatmodelingmanifesto.org/#principles
34. Re: 脅威をモデリングする術を知る 共通の言語や理解のしやすさをするためのツール 根本的な価値観や考え方に基づいた ツールやフレームワークの選定 STRIDE PASTA VAST SQUARE
35. 今回はSTRIDEっぽくやってみる S Spoofing of user identity - 偽造 T Tampering - 改ざん R Repudiation - 否認 I Information disclosure - 情報漏洩 D Denial of service - サービス拒否 E Elevation of privilege - 権限昇格 STRIDEとは
36. 自社プロダクト(MCPも含む)のモデリング IdP Web Application MCP Server DB 1 2 4 5 6 7 8 9 10 11 N1 N2 N3 12 3 B3 B1 B2 B6 B4 B5 MCP利用フロー 通知フロー Web Appのフロー 1 AI Agentに入力 2 認証を行いAccess Tokenの取得(Init時のみ) 3 認証後Access Tokenの払い出し(Init時のみ) 4 LLMに入力 5 LLM が出力、Toolを使う許可を求める 6 Toolを利用する場合、MCP Serverへ 7 APIへリクエスト 8 DBへQuery実行 DBから情報取得 10 APIからレスポンス 11 MCP Serverからレスポンス 12 チャットの出力 N1 非同期処理や特定の処理の通知を送る N2 ユーザーにツール利用や処理の継続を促す その後は、1-12までMCP利用フローと同じ もの。 B1 認証を行いAccess Tokenの取得 B2 認証後Access Tokenを払出す B3 アプリケーションにリクエスト B4 DBへQuery実行 B5 DBから結果を取得 B6 アプリケーションからレスポンス ※分かりやすくするためにグラフィカルにしていますが
 もう少しシンプルで問題ありません。
37. MCPサーバー(プロダクト)を取り巻く脅威の想定 IdP Web Application MCP Server TA06 アプリに悪意のある入力をする 攻撃者 DB TA03 認可制御の回避を
 行う攻撃者 TA04 過剰な通信を行い サービス停止を試みる TA05 MCP Serverに付与される 認証情報の奪取 TA02 悪意のあるMCP Serverの
 設置を行う攻撃者 TA01: 悪意のある命令を含んだPDFの配布 ※TA = 脅威エージェント(Threat Agents)で
 資産の悪用や損害を与える攻撃者
38. 再掲 - 設計や実装で解決するためには？ 自社の制御下に存在する
 資産保護の対策・施策 MCPサーバーやAI Agentの機能レベルの
 設計や実装のセキュリティ対策・要件の定義 利用者の端末や 想定される利用用途におけるリスクの低j ˜ 機能レベルの設計や実装より少し幅を広げてセキュリティに関する設計・実r ˜ ドキュメンテーションや必要な権限セットの列挙などベストプラクティスの定義
39. MCPサーバー(プロダクト)を取り巻く脅威の想定 IdP Web Application MCP Server TA06 アプリに悪意のある入力をする 攻撃者 DB 自社の制御下に存在する資産と それらを取り巻く脅威 設計への反映や 悪用可能な実装不備がないか 調査や修正
40. TA03: 認可制御の回避を行う攻撃者 
 MCP Serverにおけるリスク・脅威の再掲 MCP Server 攻撃 認可制御の不備と不正な操作 1 リモートに公開されている MCP Serverへ未認証状態のアクセス 2 検証を行わず操作を行うことが可能 3 操作の結果 クラウドサービスなどを操作する 1 2 3
41. TA06: アプリに悪意のある入力をする攻撃者 利用や統合におけるリスク・脅威の再掲 1 データの更新されたことをMCP Serverに伝達 悪性のプロンプトが含まれる 2 Notificationを基にデータを取得 3 悪意のあるプロンプトをLLMへ入力 ４ 悪意のある制御やツールの悪用を指示 5 ツール実行などが”常に許可”であることによる 攻撃者による生成AIアプリの制御 データ汚染もとのアプリを起点に 生成AIアプリを攻撃者が完全な制御下に 生成AIアプリケーション (MCP Host +MCP Client) Backend API MCP Server 攻撃 3 5 4 1 2 Notificationを用いた自動化と
 データ汚染による
 間接プロンプトインジェクション
42. MCPサーバー(プロダクト)を取り巻く脅威の想定 TA02 悪意のあるMCP Serverの
 設置を行う攻撃者 TA01: 悪意のある命令を含んだPDFの配布 利用者の端末や想定される
 利用用途における脅威 ※自社の制御下に存在しない脅威 利用におけるベストプラクティスや 注意喚起などを行う
43. TA02: 悪意のあるMCP Serverの設置を行う攻撃者 MCP Host + Clientにおけるリスク・脅威の再掲 生成AIアプリケーション (MCP Host +MCP Client) 悪性のMCP Server MCP Server - A 攻撃の一例 1 3 4 5 2 ６ 悪意のあるプロンプトの注入 1 Init時に悪性のMCP Serverに接続 2 Init時に悪意のあるプロンプトを返却 3 悪意のあるプロンプトをLLMへ入力 ４ 本来アクセスをしたくない/させたくない MCP Serverのツールを実行を指示 ※図の場合は、MCP Server - Aへアクセス後にその結果を悪性のMCP Serverへ送るように指示 5 通常の処理 6 結果を悪性のMCP Serverに送信
44. 1 脅威のモデリングは職人芸や
 知識ベースのではない”関係者が全員でやる”ための手法 2 脅威が”なに(資産)”を”どのように(操作)”するかを 明確にしてリスクやその対策を文章化・モデル化でき 現場に落とし込むことができる 3 セキュリティにおける未知を洗い出し、
 開発におけるセキュリティの道標を作ることができる 章まとめ 脅威をモデリングする意義と開発へのフィードバック
45. 03 プロダクトとして
 開発・提供する際の勘所
46. MCPサーバー(プロダクト)を取り巻く脅威(再掲) IdP Web Application MCP Server TA06 アプリに悪意のある入力をする 攻撃者 DB TA03 認可制御の回避を
 行う攻撃者 TA04 過剰な通信を行い サービス停止を試みる TA05 MCP Serverに付与される 認証情報の奪取 TA02 悪意のあるMCP Serverの
 設置を行う攻撃者 TA01: 悪意のある命令を含んだPDFの配布 ※TA = 脅威エージェント(Threat Agents)で
 資産の悪用や損害を与える攻撃者
47. MCPサーバーそのものに限った範囲で見ていく IdP Web Application MCP Server DB TA03 認可制御の回避を
 行う攻撃者 TA04 過剰な通信を行い サービス停止を試みる TA05 MCP Serverに付与される 認証情報の奪取
48. プロダクトとして開発・提供する際の勘所 1 MCP Serverは誰が触れていいのか？ →MCP Serverにおける認可制御と権限設計 2 MCP Serverの先のものは誰が話されていいのか？ →MCP ServerとSaaSなどの認可委譲の設計 3 MCP Serverはどの程度接続可能なのか？ →Streamable HTTPだからこその課題への対策(継続的な接続の維持など)
49. 今回話すもの 1 MCP Serverは誰が触れていいのか？ →MCP Serverにおける認可制御と権限設計 2 MCP Serverの先のものは誰が話されていいのか？ →MCP ServerとSaaSなどの認可委譲の設計 3 MCP Serverはどの程度接続可能なのか？ →Streamable HTTPだからこその課題への対策(継続的な接続の維持など)
50. 今回話すもの 1 MCP Serverは誰が触れていいのか？ →MCP Serverにおける認可制御と権限設計 2 MCP Serverの先のものは誰が話されていいのか？ →MCP ServerとSaaSなどの認可委譲の設計 3 MCP Serverはどの程度接続可能なのか？ →Streamable HTTPだからこその課題への対策(継続的な接続の維持など)
51. リモートMCPサーバーのシステム設計 Record - A2 プロダクトとしてMCPサーバーを提供する場合の構成例 IdP MCP Server Object Storage Object Storage Backend API - B Backend API - A DB - Table B DB - Table A Record - A1 Record - B1 Record - B2 Object - 1 Object - 2 tool tool / resource tool
52. tool リモートMCPサーバーのシステム設計 Record - A2 プロダクトとし てのMCPサーバーとし て新規開発する箇所 tool tool / resource tool Record - A2 IdP MCP Server Object Storage Object Storage Backend API - B Backend API - A DB - Table B DB - Table A Record - A1 Record - B1 Record - B2 Object - 1 Object - 2 Webで公開されるプロダクトと共通のシステム 新規開発 tool / resource tool
53. リモートMCPサーバーの権限管理と認可制御 IdP MCP Server Object Storage Object Storage Backend API - B Backend API - A DB - Table B DB - Table A Record - A1 Record - B1 Record - B2 Record - A2 Q. プロダクトとして提供リモートMCPサーバーの認可制御は何に基づいて考えるべき? Object - 1 Object - 2 tool tool / resource tool
54. リモートMCPサーバーの権限管理と認可制御 IdP MCP Server Object Storage Object Storage Backend API - B Backend API - A DB - Table B DB - Table A Record - A1 Record - B1 Record - B2 Record - A2 A. 既存のプロダクトの権限を基に、IdPから払い出されたAccess Tokenを用いて判断する ※JWTでAccess Tokenを払い出している場合は、JWTの検証時にscopesなどを基に操作の可否を判断する。 Object - 1 Object - 2 tool tool / resource tool IdP側でユーザーの権限を管理し、 ユーザーの用いるAccess Tokenに Scopesとして付与するのが 望ましい
55. リモートMCPサーバーの権限管理と認可制御 IdP MCP Server Object Storage Object Storage Backend API - B Backend API - A DB - Table B DB - Table A Record - A1 Record - B1 Record - B2 Record - A2 A. 既存のプロダクトの権限を基に、IdPから払い出されたAccess Tokenを用いて判断する ※JWTでAccess Tokenを払い出している場合は、JWTの検証時にscopesなどを基に操作の可否を判断する。 Object - 1 Object - 2 tool tool / resource tool 権限の検証をMCP Serverで
 行う以外にBackend API側でも 実施していると、誤った操作が されにくくなる
56. リモートMCPサーバーの権限管理と認可制御 IdP MCP Server Object Storage Object Storage Backend API - B Backend API - A DB - Table B DB - Table A Record - A1 Record - B1 Record - B2 Record - A2 A. 既存のプロダクトの権限を基に、IdPから払い出されたAccess Tokenを用いて判断する ※JWTでAccess Tokenを払い出している場合は、JWTの検証時にscopesなどを基に操作の可否を判断する。 Object - 1 Object - 2 tool tool / resource tool Object Storageなどの リソースへ直接操作を行う場合 MCP Server側の検証とともに ABACを用いたアクセス制御を
 推奨します
57. 今回話すもの 1 MCP Serverは誰が触れていいのか？ →MCP Serverにおける認可制御と権限設計 2 MCP Serverの先のものは誰が話されていいのか？ →MCP ServerとSaaSなどの認可委譲の設計 3 MCP Serverはどの程度接続可能なのか？ →Streamable HTTPだからこその課題への対策(継続的な接続の維持など)
58. 資格情報の管理 リモートMCPサーバーからSaaSのAPIを操作するサービスの構成例 IdP MCP Server Backend API - 
 Slackの操作 Backend API - A DB - Table A Slack API Slack IdP tool tool
59. 資格情報の受け渡しにおける課題 Q. 資格情報の受け渡しや設定はどのようにすべきか？ IdP MCP Server Backend API - 
 Slackの操作 Backend API - A DB - Table A Slack API tool tool
60. 資格情報を固定化して利用する 実装例1. 固定の資格情報を用いてBackend API側で認可制御をする ※Slackの場合はアプリ用のAPI Keyを資格情報として用いる IdP MCP Server Backend API - 
 Slackの操作 Backend API - A DB - Table A Slack API tool tool アプリ用のAPI Keyは 与えられた権限の範囲であれば、 すべてのチャンネルやDMに対して 閲覧や操作ができるので、 場合によってはかなり危険
61. 認可委譲を用いてユーザー毎の資格情報を利用する 実装例2. OAuthを用いた認可委譲 ※Slackの場合はBot User用のAPI Keyを資格情報として用いて
 OAuthを用いて認可委譲を行う IdP MCP Server Backend API - 
 Slackの操作 Backend API - A DB - Table A 資格情報の保管 KVSなど Slack API Slack IdP tool tool 認可委譲の場合、サービスが求める権限を 個々のユーザーが許可することで、権限を アプリケーションに移譲することができる この場合、ユーザーのできることがアプリ ケーションのできることになるので、権限 の超越などは発生しにくい
62. 資格情報の扱い 実装例2. OAuthを用いた認可委譲 実装例1. 
 固定の資格情報を用いて Backend API側で認可制御をする どちらを採用するかはサービス特性次第だが、
 多くの場合ユーザーのできること = サーバーからできることにする方が、
 攻撃からのリスクを減らすことができます。 1 MCP Specで定義される 第三者サービス連携の手法 2 サーバーの操作できること = ユーザーの権限
 なのでシンプルでわかりやすい 1 連携対象となるサービスが固定で、
 操作範囲も明確な場合、管理のコストが低い 2 Backend APIが既存で存在する場合などは
 MCP Specに則るより安価に利用できる ※ただし、セキュリティ上の懸念が存在する場合がある
63. 章まとめ 1 認可制御は通常のWebアプリケーションの権限に準拠 2 MCP Serverへの権限の付与は用途に応じて行う 3 積極的な認可委譲を推奨
64. おまけ AI Agentの一機能として
 開発・提供する際の勘所
65. AI Agentの一機能として開発・提供する際の勘所 1 どこからプロンプトの材料を取得するのか？ → 間接プロンプトインジェクションの可能性を考える 2 過剰な権限や機能を利用できないか？ → 通信を扱うエージェントが機微情報にアクセスできないか 3 エージェントの思考は利用者が確認できるか？ → ログや思考を確認できる状態にする
 あわせて、攻撃者がコントロールしていた際に中断可能にする 4 分離単位は最適なのか？ → AI Agentのコンテキストの分離が適切な単位で分離されているか
66. AI Agentの一機能として開発・提供する際の勘所 RAG × セキュリティ 検索拡張生成を用いるLLMアプリ における実装ガイドライン AI時代の 認可制御入門 AI破産を防ぐために LLM API利用におけるEconomic DoSのリスクと対策 プロンプト インジェクション対策 様々な攻撃パターンから学ぶセキュリティのリスク Amazon Bedrock 活用の生成AIアプリケーション セキュリティリスクと対策 MCP・AIエージェント開発 LLMの 外部通信・連携 セキュリティ LLMガードレールの 活用法と役割を正しく理解する 前 編 セキュリティ考慮事項と 実装における観点 LLM / 生成AIアプリケーションの セキュリティリスクと対策 後 編 セキュリティ考慮事項と 実装における観点
67. 04 まとめ
68. まとめ 1 脅威をモデリングしてセキュリティリスクの可視化をする 2 MCP Serverを開発する際は ”権限”・”責任分解点”・”Web Appと同じ対策”を意識 3 LLMが何を触れて、何を触ってはいけないかを意識 4 人間の関与や強制的な中断を可能にする