セキュリティ視点からみる
 生成AIアプリケーションとMCP ~ 脅威とリスク、認可・権限 ~ 2025/06/20 - OpenID TechNight vol.22 ~ AI時代のID管理「AIdentity」勉強会 GMO Flatt Security株式会社 Norihide Saito / Azara 

自己紹介 名前 Norihide Saito / Azara 所属 講演・コミュニティ活動 国内 JPCERT/CC JSAC 2024 登壇・ベストスピーカー賞 国際 BSides Las Vegas 2024 登壇 国内 BSides Tokyo 2024 登壇 国際 AWS Community Builder - Security 国内 SECCON 2022 Domestic 国内 ISOG-J ワーキングループ1での活動 国内 CloudSec JP Organizer 国内 Cloud Security expert of GMO internet group 

Our Mission エンジニアの背中を預かる より多くのエンジニアがものづくりに集中できる社会を、 セキュリティ面からつくる会社 

脆弱性診断・ペネトレーションテストを プロフェッショナル / SaaSで多角的に提供 手動・高度診断 コード・仕様の分析も行い、 専門家が脆弱性を網羅的に発見 自動・継続診断 クラウド・Webアプリをまるごと 継続的に診断するSaaS 提供サービス 提供サービス 

MCPを対象にした診断(プロフェッショナルサービス) 

最近AI関連の諸々の発信が盛んです RAG × セキュリティ 検索拡張生成を用いるLLMアプリ における実装ガイドライン AI時代の 認可制御入門 AI破産を防ぐために LLM API利用におけるEconomic DoSのリスクと対策 プロンプト インジェクション対策 様々な攻撃パターンから学ぶセキュリティのリスク Amazon Bedrock 活用の生成AIアプリケーション セキュリティリスクと対策 MCP・AIエージェント開発 LLMの 外部通信・連携 セキュリティ LLMガードレールの 活用法と役割を正しく理解する 前 編 セキュリティ考慮事項と 実装における観点 LLM / 生成AIアプリケーションの セキュリティリスクと対策 後 編 セキュリティ考慮事項と 実装における観点 

OpenID Foundation - JPとのご縁 2025/4 - 都内某所 - 某人材育成事業のクラス別講師顔合わせにて 

OpenID Foundation - JPとのご縁 2025/4 - 某人材育成事業のクラス別講師顔合わせの翌日 OKです！! 

本発表はこのような人を想定して作っています 生成AIを用いた ソフトウェアを作る人 生成AI関連の
 セキュリティを学ぶ人 AIを育てるすべての人たちへ 生成AIを用いた ソフトウェアを守る人 特にIDや権限など 

本発表について 弊社の などを再編して実例や最新の動向を追加したものです。 実質書き下ろしです。 MCPにおけるセキュリティ考慮事項と実装における観点 

今日話すこと 1 生成AI application における MCP の活用例 ２ 実装や利用で 注意 すべき脅威やリスク 3 MCP の 認可 権限 管理における課題 4 MCP 導入や実装にあたって検討すべきこと (まとめ) MCPの実装やシステム構成におけるセキュリティ課題と、生成AIアプリ ケーションにおける認証・認可・権限の管理を重点に話します。 

本発表の目的 MCPを
 正しく怖がりながら 守るにはどうするの を理解する 

01 生成AI Applicationにおける MCPの活用事例 

前説: 生成AIアプリケーションにおけるMCPとは？ カンガエマス 生成AIアプリケーション LLM 操作方法教えて コンナカンジデ
 ソウサシテ アプリケーション 生成AIアプリケーション LLM OK MCP登場前 1. 命令を生成AIアプリケーション 経由でLLMに伝える –“ 人間が操作をする 

前説: 生成AIアプリケーションにおけるMCPとは？ カンガエマス 生成AIアプリケーション LLM 操作方法教えて アプリケーション コンナカンジデ
 ソウサシテOK? 生成AIアプリケーション LLM OK 一部ソフトウェア - 
 独自のTool Calling 1. 命令を生成AIアプリケーション 経由でLLMに伝える ˆ~ 人間が操作を許可して
 生成AIアプリケーションが
 操作を代替する
 (ファイルの読み書きやShell commandの実行など) 

前説: 生成AIアプリケーションにおけるMCPとは？ 独自のTool Callingではなく、 共通化したインターフェースを設けて、接続性をよくしよう！ 

前説: MCPが歩んできた仕様 MCPの仕様はこれまで初版を含めると3つのバージョンが存在する。 1 2024-11-05 p 初版でStdioとSSE(!?)を用いたClient Server Modelのプロトコルを提j p 俗にいうRPC的なもので、従来のTool callingのインターフェースを共通化した 2 2025-03-26 p SSEからStreamable HTTPへ、Remote化が促‹ p OAuth2.1 Draftを用いた認可に関する項目の追加 3 2025-06-18 p セキュリティに関する更新多¼ p 一方で認可委譲などの細かな実装への言及削除 

現時点での活用例 1 Localでの活用 2 Remote MCP Serverの利用 3 プロダクトとしてRemote MCP Serverを提供 4 社内システムとしての利用 5 MCP GatewayのようなSaaSとのProxyとして利用 6 AI Agentの手足として利用 

Localでの活用 MCP Serverを介して、特定のファイルやコマンドや ソフトウェアの操作などを行う 

Remote MCP Serverの利用 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 アプリケーションからレスポンス 

GitHubの公式Remote MCP Server https://github.com/github/github-mcp-server/tree/main https://github.blog/changelog/2025-06-12-remote-github-mcp-server-is-now-available-in-public-preview/ 

プロダクトとしてRemote MCP Serverを提供 プロダクトとしてMCP Serverを提供するさいの想定図 IdP MCP Server Object Storage Backend API DB - Table A Record - A1 4 6 5 3 R2 R1 1 2 Object - 1 Object - 2 tool / resource Record - A2 MCP Serverの流れ 1 IdPで認証を行いプロダクトで用いるAccess Tokenを払い出す ２ Access Tokenを付与し、MCP Serverと通信を行う 3 Access Tokenの検証を行い、リソースサービスとしての MCP Server(もしくはtoolなど)を利用可能かの確認を行う 4 Access TokenのScopeを用いた認可制御が問題がない場合、 Backend APIへのリクエストを実施する 5 Access Tokenを検証し、権限上対象のデータにアクセス可能 かの検証を行う。 6 DBかから情報を取得 R1 Access TokenのScopeを用いた認可制御が問題がない場合、 Object Storageへのリクエストを実施する R2 Prefixなどを用いて特定の属性の値を含んでいる場合のみ アクセス可能にする(実質的なABAC) 補足1. IdPが発行するTokenに付与されるScopeは、開発組織によって運 用が変わると考えるが、基本的には特定のコンテキストに則った範囲で分 割をする。 例: G oogle APIsのScope h ttps: //developers.google.com/identity /protocols/oauth 2/scopes 補足2. 5で実施したBackend APIの認可制御は、各種 APIにおけ る認可制 御に依存 すべき で、MCP Server側 で行うべき ではない。ま た各種細 かな 権限管理 は、開発組織の思 想に依存 する。 

効率化(自社事例) AI利用許諾済みの顧客のみ 脆弱性診断等の
 プロフェッショナルサービスにおける
 生成AIアプリケーションと
 ソースコード検査などのMCP活用 実質秘書 

MCP GatewayのようなSaaSとのProxyとして利用 MCP Gateway SaaSと生成AIアプリケーションを繋ぐ Proxyのような役割 

AI Agentの手足として利用 広義の意味のRAGやブラウザでの検索、 各種操作をさせる MCP Server MCP Server knowledge DB 

02 実装で注意すべき MCPを用いたシステム構成や運用 

前説: MCPが歩んできた仕様 これら仕様における”セキュリティ”について 1 2024-11-05 € 境界線的なセキュリティモデルを採E € 認証情報はenvや接続時にパラメーターとして渡すような実装が多数存在 2 2025-03-26 € OAuth2.1 Draftを用いたIDベースのセキュリティモデルを推| € 認可委譲への言及 3 2025-06-18 € ベストプラクティスの再整理と細かな実装への言及削‘ € 認可周りの語の再整理 

MCPと周辺におけるセキュリティ課題の大別 MCP Serverにおける リスク・脅威 利用における リスク・脅威 MCP Host + Clientにおける リスク・脅威 (生成AI Application) 

MCP Host + Clientにおけるリスク・脅威 MCP Host + Clientにおける リスク・脅威 ※正確には生成AI Application全般におけるリスク・脅威 攻撃者の目的 攻撃者による 生成AIアプリの制御と ツールへのアクセス 情報の抜き取りや機能の悪用など 

MCP Host + Clientにおけるリスク・脅威 MCP Host + Clientにおける リスク・脅威 ※正確には生成AI Application全般におけるリスク・脅威 1 意図しないプロンプトの注入 2 ツール利用における 混乱・意図しない実行 3 攻撃者による 生成AI Applicationの恒久的制御 手段の一例 

MCP Host + Clientにおけるリスク・脅威 生成AIアプリケーション (MCP Host +MCP Client) 悪性のMCP Server MCP Server - A 攻撃の一例 1 3 4 5 2 ６ 悪意のあるプロンプトの注入 1 悪性のMCP Serverに接続 2 悪意のあるプロンプトを返却 3 返された悪意のあるプロンプトに入力 ４ 本来アクセスをしたくない/させたくない MCP Serverのツールを実行を指示 ※図の場合は、MCP Server - Aへアクセス後にその結果を悪性のMCP Serverへ送るように指示 5 通常の処理 6 結果を悪性のMCP Serverに送信 

MCP Host + Clientにおけるリスク・脅威 生成AIアプリケーション (MCP Host +MCP Client) 悪性のMCP Server MCP Server - A 不備のある実装の一例 1 3 4 5 2 ６ 悪意のあるプロンプトの注入 作る人の観点 

MCP Host + Clientにおけるリスク・脅威 生成AIアプリケーション (MCP Host +MCP Client) 悪性のMCP Server MCP Server - A 対策の例 1 3 4 6 7 5 2 8 悪意のあるプロンプトの注入 CursorのAgentにおいて
 Tool実行における許可を求める実装 7 5 使う人の観点 

MCP Host + Clientにおけるリスク・脅威 MCP Host + MCP Clientで 許可を求める実装を作る場合 作る人の観点 

MCP Serverにおけるリスク・脅威 攻撃者の目的 MCP Serverにおける リスク・脅威 攻撃者による ツールの悪用 + 付与された権限の悪用
 または、権限の付与された認証情報の取得 

MCP Serverにおけるリスク・脅威 MCP Serverにおける リスク・脅威 1 認可制御の不備 2 権限の過剰付与と
 権限の取り扱いに関する設計不備 3 設定や実装の不備を悪用 →単純な設定ミスやOWASP Top 10などの脆弱性 手段の一例 

MCP Serverにおけるリスク・脅威 MCP Server 攻撃の一例 認可制御の不備と不正な操作 1 リモートに公開されている MCP Serverへ未認証状態のアクセス 2 検証を行わず操作を行うことが可能 3 操作の結果 クラウドサービスなどを操作する 1 2 3 

MCP Serverにおけるリスク・脅威 MCP Server 対策の一例 認可制御の不備と不正な操作 作る人の観点 1 その操作が本当に許可されたものか
 検証をする 2 SaaSやクラウドへの接続は
 固定の資格情報ではなく、
 認可委譲による個々のユーザーの
 資格情報を引き受ける実装にする 1 

Remote MCP Serverにおける懸念のある実装指針 指針の不備 プロダクトの
 Remote MCP Serverにおける 懸念のある実装指針 独自のロジックを
 MCP ServerのToolに
 実装をする 可能な限り避けるべきだが、 

プロダクトとしてのRemote MCP Serverの実装 望ましい実装 IdP MCP Server Object Storage Backend API DB - Table A Record - A1 4 6 5 3 R2 R1 1 2 Object - 1 Object - 2 tool / resource Record - A2 MCP Serverの流れ 1 IdPで認証を行いプロダクトで用いるAccess Tokenを払い出す ２ Access Tokenを付与し、MCP Serverと通信を行う 3 Access Tokenの検証を行い、リソースサービスとしての MCP Server(もしくはtoolなど)を利用可能かの確認を行う 4 Access TokenのScopeを用いた認可制御が問題がない場合、 Backend APIへのリクエストを実施する 5 Access Tokenを検証し、権限上対象のデータにアクセス可能 かの検証を行う。 6 DBかから情報を取得 R1 Access TokenのScopeを用いた認可制御が問題がない場合、 Object Storageへのリクエストを実施する R2 Prefixなどを用いて特定の属性の値を含んでいる場合のみ アクセス可能にする(実質的なABAC) 補足1. IdPが発行するTokenに付与されるScopeは、開発組織によって運 用が変わると考えるが、基本的には特定のコンテキストに則った範囲で分 割をする。 例: Google APIsのScope https://developers.google.com/identity/protocols/oauth2/scopes 補足2. 5で実施したBackend APIの認可制御は、各種APIにおける認可制 御に依存すべきで、MCP Server側で行うべきではない。また各種細かな 権限管理は、開発組織の思想に依存する。 作る人の観点 

プロダクトとしてのRemote MCP Serverの実装 好ましくない実装 ( はMCP Server内の実装) 赤枠 IdP Object Storage Tool Function (内部実装) Tool Function (内部実装) DB - Table A Record - A1 4 6 5 3 R2 R1 MCP Server 1 2 Object - 1 Object - 2 tool / resource Record - A2 MCP Serverの流れ 1 IdPで認証を行いプロダクトで用いるAccess Tokenを払い出す ２ Access Tokenを付与し、MCP Serverと通信を行う 3 Access Tokenの検証を行い、リソースサービスとしての MCP Server(もしくはtoolなど)を利用可能かの確認を行う 4 Access TokenのScopeを用いた認可制御が問題がない場合、 Backend APIへのリクエストを実施する 5 Access Tokenを検証し、権限上対象のデータにアクセス可能 かの検証を行う。 6 DBかから情報を取得 R1 Access TokenのScopeを用いた認可制御が問題がない場合、 Object Storageへのリクエストを実施する R2 Prefixなどを用いて特定の属性の値を含んでいる場合のみ アクセス可能にする(実質的なABAC) 補足1. IdPが発行するTokenに付与されるScopeは、開発組織によって運 用が変わると考えるが、基本的には特定のコンテキストに則った範囲で分 割をする。 例: G oogle APIsのScope h ttps: //developers.google.com/identity /protocols/oauth 2/scopes 補足2. 5で実施したBackend APIの認可制御は、各種 APIにおけ る認可制 御に依存 すべき で、MCP Server側 で行うべき ではない。また各種細 かな 権限管理 は、開発組織の思想 に依存 する。 作 る人 の観点 

Remote MCP Serverにおける懸念のある実装指針 1 既存プロダクトとの認可制御の
 実装差分が発生する可能性
 →OWASP Top 10などの脆弱性やロジックの不備が起こる可能性 2 内部実装に脆弱性を埋め込む可能性 →OWASP Top 10などの脆弱性やロジックの不備が起こる可能性 3 設定や実装の不備を悪用 →単純な設定ミスや なぜ懸念がある？(気にすべき点) プロダクトの
 Remote MCP Serverにおける 懸念のある実装指針 作る人の観点 

利用や統合におけるリスク・脅威 攻撃者の目的 利用や統合における リスク・脅威 一つのシステムとしての 脆弱性を用いて
 攻撃者の制御下におく 

利用や統合におけるリスク・脅威 1 データの汚染による 間接プロンプトインジェクション 2 自動化を想定した際の Notificationの副作用 2 複数のMCP Serverが
 存在する場合の悪性相互作用 利用や統合における リスク・脅威 手段の一例 

利用や統合におけるリスク・脅威 1 データの更新されたことをMCP Serverに伝達 悪性のプロンプトが含まれる 2 Notificationを基にデータを取得 3 悪意のあるプロンプトをLLMへ入力 ４ 悪意のある制御やツールの悪用を指示 5 ツール実行などが”常に許可”であることによる 攻撃者による生成AIアプリの制御 データ汚染もとのアプリを起点に 生成AIアプリを攻撃者が完全な制御下に 生成AIアプリケーション (MCP Host +MCP Client) Backend API MCP Server 攻撃の一例(1) 3 5 4 1 2 Notificationを用いた自動化と
 データ汚染による
 間接プロンプトインジェクション https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks 

利用や統合におけるリスク・脅威 生成AIアプリケーション (MCP Host +MCP Client) Backend API MCP Server 研究 3 5 4 1 2 Notificationを用いた自動化と
 データ汚染による
 間接プロンプトインジェクション https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks 

利用や統合におけるリスク・脅威 1 生成AIアプリケーションが認証情報をつけて
 悪性のMCP Server(Proxy)に接続 2 ProxyはSaaSへの接続をする 3 攻撃者は通信に付与された認証情報や
 認可委譲で悪性のMCP Serverに渡された 資格情報を取得し悪用する 攻撃の一例(2) 悪性のMCP Proxyを用いた
 SaaSなどへのアクセス 生成AI アプリケーション 悪性のMCP Server (ServiceのProxy) SaaSなどの クラウドサービス 1 ３ ２ 

利用や統合におけるリスク・脅威 攻撃の一例(2) 悪性のMCP Proxyを用いた
 SaaSなどへのアクセス 生成AI アプリケーション 悪性のMCP Server (ServiceのProxy) SaaSなどの クラウドサービス https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices 

利用や統合におけるリスク・脅威 1 第三者の提供する
 MCP Proxyのようなものを極力使わない 2 自社で運用する場合は、そのMCP Proxyが サプライチェーン的に
 安全であるかを検証する 3 もしくは自社で作る OR 公式の提供する MCP Serverを用いる (そもそもProxyを使わずになせる可能性があるかを検討する) 対策 悪性のMCP Proxyを用いた
 SaaSなどへのアクセス 生成AI アプリケーション 自社のMCP Server (ServiceのProxy) SaaSなどの クラウドサービス 1 ２ 

脅威やリスクを設計・実装・統制で解決するには？ 1 組織やシステムの全体像の把握と資産の整理 → “誰(操作主体)”が”なに(資産)”を”どのように(操作)”するかを明確にする 2 機械的に制御可能なものは何で、
 制御できないものは何かの整理 → “制御できるもの”と”できないもの”を切り分け、個別に施策を練る 3 取り巻く脅威と考えられる侵入経路の把握 顧客や情報資産、IT資産を守るために”設計”や”実装”レベルで対策でき ることはなんなのだろうか？ 統制で解決すべきことは？ 

設計や実装、ドキュメントで解決するためには？ MCPに関係するソフトウェアの 設計や実装に関する指‚ U MCPサーバーやAI Agentの機能レベルの
 設計や実装のセキュリティ対策・要件の定0 U 権限や認可、アクセス制御に関する設計 など MCPに関係するソフトウェアの
 利用に関する指‚ U 利用者端末の保z U 生成AI・MCP利用時のガイドライン作¬ U 利用可能なMCP Serverやソフトウェアの安全性
 プライバシー保護に関する観点の確認 など 

章まとめ 1 MCPのリスク・脅威としているが実状は
 Webアプリケーションと同様のリスク・脅威と近しい 2 単一では脅威度が低いものでも、
 利用の仕方によっては脅威となるものが存在する →自動化された生成AIアプリケーション + 汚染されたデータを基にしたプロンプ トインジェクションと攻撃者による制御のような例 3 実装で対応できるものと、そうでないものが存在する →「ツール実行時に確実に操作者の許可を求める」や「同時に利用するMCP Serverの制約」などの、現時点では「運用でカバー」のような対応になるものが 存在する 

03 MCPの 「　 　 ・認可・権限」管理における課題 

AIにおける認可・権限の課題 1 過剰な権限の付与 2 過剰な機能の付与 3 動的な権限の付与 クラウドサービスや
 アクセス可能な情報 MCP Serverなどの 設定 MCP Serverの権限と ユーザーの権限の差異 

AIにおける認可・権限の課題 https://blog.flatt.tech/entry/ai_authz 

AIにおける認可・権限の課題 1 過剰な権限の付与 2 3 動的な権限の付与 クラウドサービスや
 アクセス可能な情報 MCP Serverなどの 設定 MCP Serverの権限と ユーザーの権限の差異 

MCPを含めた認可・権限の課題 1 Resource ServerとしてのMCP ServerのScope指定と権限管理 2 資格情報の管理が不十分な可能性(固定化された資格情報) 3 不適切な属性を用いたABAC 

MCPを含めた認可・権限の課題 1 Resource ServerとしてのMCP ServerのScope指定と権限管理 2 資格情報の管理が不十分な可能性(固定化された資格情報) 3 不適切な属性を用いたABAC 

Resource ServerとしてのMCP Server
 Scope指定と権限管理 IdP MCP Server Object Storage Backend API DB - Table A Record - A1 4 6 5 3 R2 R1 1 2 Object - 1 Object - 2 tool / resource Record - A2 MCP Serverの流れ 1 IdPで認証を行いプロダクトで用いるAccess Tokenを払い出す ２ Access Tokenを付与し、MCP Serverと通信を行う 3 Access Tokenの検証を行い、リソースサービスとしての MCP Server(もしくはtoolなど)を利用可能かの確認を行う 4 Access TokenのScopeを用いた認可制御が問題がない場合、 Backend APIへのリクエストを実施する 5 Access Tokenを検証し、権限上対象のデータにアクセス可能 かの検証を行う。 6 DBかから情報を取得 R1 Access TokenのScopeを用いた認可制御が問題がない場合、 Object Storageへのリクエストを実施する R2 Prefixなどを用いて特定の属性の値を含んでいる場合のみ アクセス可能にする(実質的なABAC) 補足1. IdPが発行するTokenに付与されるScopeは、開発組織によって運 用が変わると考えるが、基本的には特定のコンテキストに則った範囲で分 割をする。 例: Google APIsのScope https://developers.google.com/identity/protocols/oauth2/scopes 補足2. 5で実施したBackend APIの認可制御は、各種APIにおける認可制 御に依存すべきで、MCP Server側で行うべきではない。また各種細かな 権限管理は、開発組織の思想に依存する。 

MCPを含めた認可・権限の課題 1 Resource ServerとしてのMCP ServerのScope指定と権限管理 2 資格情報の管理が不十分な可能性(固定化された資格情報) 3 不適切な属性を用いたABAC 

資格情報の管理 リモートMCPサーバーからSaaSのAPIを操作するサービスの構成例 IdP MCP Server Backend API - 
 Slackの操作 Backend API - A DB - Table A Slack API Slack IdP tool tool 

資格情報の受け渡しにおける課題 Q. 資格情報の受け渡しや設定はどのようにすべきか？ IdP MCP Server Backend API - 
 Slackの操作 Backend API - A DB - Table A Slack API tool tool 

資格情報を固定化して利用する 実装例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に対して 閲覧や操作ができるので、 場合によってはかなり危険 

認可委譲を用いてユーザー毎の資格情報を利用する 実装例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 認可委譲の場合、サービスが求める権限を 個々のユーザーが許可することで、権限を アプリケーションに移譲することができる この場合、ユーザーのできることがアプリ ケーションのできることになるので、権限 の超越などは発生しにくい 

資格情報の扱い 実装例2. OAuthを用いた認可委譲 実装例1. 
 固定の資格情報を用いて Backend API側で認可制御をする どちらを採用するかはサービス特性次第だが、
 多くの場合ユーザーのできること = サーバーからできることにする方が、
 攻撃からのリスクを減らすことができます。 1 MCP Specで定義される 第三者サービス連携の手法 2 サーバーの操作できること = ユーザーの権限
 なのでシンプルでわかりやすい 1 連携対象となるサービスが固定で、
 操作範囲も明確な場合、管理のコストが低い 2 Backend APIが既存で存在する場合などは
 MCP Specに則るより安価に利用できる ※ただし、セキュリティ上の懸念が存在する場合がある 

MCPを含めた認可・権限の課題 1 Resource ServerとしてのMCP ServerのScope指定と権限管理 2 資格情報の管理が不十分な可能性(固定化された資格情報) 3 不適切な属性を用いたABAC 

不適切な属性を用いたABAC IdP MCP Server Object Storage Backend API DB - Table A Record - A1 4 6 5 3 R2 R1 1 2 Object - 1 Object - 2 tool / resource Record - A2 MCP Serverの流れ 1 IdPで認証を行いプロダクトで用いるAccess Tokenを払い出す ２ Access Tokenを付与し、MCP Serverと通信を行う 3 Access Tokenの検証を行い、リソースサービスとしての MCP Server(もしくはtoolなど)を利用可能かの確認を行う 4 Access TokenのScopeを用いた認可制御が問題がない場合、 Backend APIへのリクエストを実施する 5 Access Tokenを検証し、権限上対象のデータにアクセス可能 かの検証を行う。 6 DBかから情報を取得 R1 Access TokenのScopeを用いた認可制御が問題がない場合、 Object Storageへのリクエストを実施する R2 Prefixなどを用いて特定の属性の値を含んでいる場合のみ アクセス可能にする(実質的なABAC) 補足1. IdPが発行するTokenに付与されるScopeは、開発組織によって運 用が変わると考えるが、基本的には特定のコンテキストに則った範囲で分 割をする。 例: Google APIsのScope https://developers.google.com/identity/protocols/oauth2/scopes 補足2. 5で実施したBackend APIの認可制御は、各種APIにおける認可制 御に依存すべきで、MCP Server側で行うべきではない。また各種細かな 権限管理は、開発組織の思想に依存する。 

不適切な属性を用いたABAC AWS(クラウド)関連のサービスをユーザーに紐づけてAIに触らせる(現時点でのBest) Amazon Cognito User Pool Amazon Cognito Identity Pool Amazon S3 人間が扱う場合 AIが扱う場合 1 2 3 Amazon Cognito User Pool Amazon Cognito Identity Pool Amazon S3 1 3 4 5 7 6 2 MCP Server 生成AIアプリケーション (MCP Host +MCP Client) 

不適切な属性を用いたABAC PolicyでのABAC 

不適切な属性を用いたABAC Amazon Cognito User Poolを用いてS3のアクセスをABACで制御する際の不適切な例 /DUMMY_APP_NAME/${cognito-identity.amazonaws.com:name}/* 

不適切な属性を用いたABAC Amazon Cognito User Poolを用いてS3のアクセスをABACで制御する際の不適切な例 Amazon Cognito User Pool Amazon Cognito Identity Pool Amazon S3 1 3 4 5 7 6 2 MCP Server 生成AIアプリケーション (MCP Host +MCP Client) 1 2 3 攻撃者のフロー 1 ABACが行われているリソースで用いられるAttributeが IdP側で変更可能な場合、変更を行う
 (第三者のものと同じものにするなど) 2 MCP ServerからIAM Roleに紐づいた資格情報を取得する際に 意図しないAttributeが用いられるため、意図したABACが適用 されない状態で、発行される 3 MCP Serverは意図したABACが適用されない状態の資格情報を
 用いて第三者の情報にアクセスすることができる 

04 まとめ 

まとめ 1 脅威をモデリングしてセキュリティリスクの可視化をする 2 MCP Serverを開発する際は ”権限”・”責任分解点”・”Web Appと同じ対策”を意識 3 LLMが何を触れて、何を触ってはいけないかを意識 4 人間とAIの権限の間もそうだが、IdPなどの設定に依存 したアクセスコントロールをする場合もシステムに脆 弱性が埋め込まれることがある 

Passkey認証診断はじめました 技術ブログも 来週公開予定です！