MCP Elicitationでは、機密をどう扱うべきですか？
追加質問も権限境界の一部です。機密を自然言語で尋ねず、入力の種類と経路を実装で分けます。
MCP Elicitationは、serverがclientを通じて利用者へ追加情報を求める仕組みです[1]。便利ですが、問い方を誤ると機密が流れます。
serverが自然言語でAPI keyやpasswordを尋ねる場合を考えます。個人番号も同様です。会話履歴、client log、model contextへ機密が流れます。
何を聞けるかをtool説明に任せません。入力の種類と取得経路を、protocolと実装で分離します。
Elicitationの安全設計は、どんな手順で進めますか？
form modeの限定、URL modeでの資格情報取得、URLの検証、同意と監査の記録の順に進めます。
対象workspaceと期間は通常の入力欄へ、APIキーは外部の認証画面へ分ける設計例です。追加質問にacceptしても、送信や削除を承認したことにはしません。個人番号など資格情報以外の機微情報は、取得の必要性と利用目的から別に審査します。
- form modeを通常の構造化入力に限定します。form modeは、JSON Schemaに基づくfieldを提示します。利用者は、accept、decline、cancelを選べます[1]。用途名、期間、対象の作業領域など、サーバーの処理に必要な通常項目に限ります。自由記述欄に何でも入れられる設計を避け、文字数、形式、選べる値を指定します。未入力でも安全に終了できるようにします。
- 資格情報はURL modeへ逃がします。MCPの2025-11-25 releaseは、URL modeを追加しました[2]。clientへは通しません。browser上の外部認証flowで、serverが直接受け取る仕組みです。対象はAPI keyやpasswordです。clientには認証URLを表示させ、callbackのstate、redirect、sessionを検証します。credentialは、elicitation responseやpromptへ返しません。secret storeへ保存します。短期tokenと最小scopeを使います。
- URL自体も信頼しすぎません。外部URLは、phishingとopen redirectの入口になります。clientはdomainと目的を明示し、serverは許可済みoriginだけを発行します。OAuth security best current practiceは、4つを示しています[3]。redirect URIの厳密照合、PKCE、mix-up対策、token leakage防止です。認証後は、MCP server向けのaudienceとscopeを検証します。第三者tokenのpassthroughは拒否します[4]。
- 同意と監査を別々に残します。formのaccept、外部認証の完了、tool実行の承認は、それぞれ別の出来事です。request ID、server、field分類、同意結果を記録します。実行されたtool、対象resource、結果も記録します。値そのもの、token、passwordはlogへ残しません。高riskな送信、削除、支払いは、資格情報の取得後も直前確認を要求します。
- 公開前に脅威testを行います。失敗を試験して、clientとserverの両方で拒否点を定義します。試す例は次のとおりです。
- malicious serverがpasswordを通常fieldとして要求する
- 正規serverが第三者tokenをpromptへ貼るよう指示する
- 外部URLが似たdomainへredirectする
- callbackのstateが別sessionと入れ替わる
- 利用者がcancelした後もtoolが実行される
form responseには、HTMLやscript、極端に長い文字列、別workspace IDも入れて試します。schema validation後もauthorizationが働くかを確認します。入力を表示するUIではescapeし、logとerror messageへ値を出しません。
URL modeでは、HTTPS、allowlisted origin、単回state、短い有効期限を使います。完了後にcredentialをclientへ戻さないことも確認します。
同意画面には、server名、取得目的、field名、外部遷移先、cancel方法を表示します。acceptが既定になったdark patternは避けます。後から接続を解除できる導線も用意します。
service tokenのように人の同意がないcredentialは、別のinventoryで管理します。管理する項目は、owner、scope、rotation、失効です。
監査logを使ったincident drill（事故対応の訓練）も必要です。怪しいURLを開いた場合は、次を確認します。
- 発行tokenを失効できる
- 該当server接続を止められる
- 同じrequest IDのtool実行と外部送信を追える
秘密値を調査資料へ転記しません。rotation完了までの責任者を決めます。
Elicitationの設計がうまくいかない例には、どんなものがありますか？
URL modeを万能と考える、schema検証を権限確認と混同する、未対応のclientで取得を続ける、の3つです。
- URL modeを万能と考える。URL modeは、credential漏えいの経路を減らします。ただし、悪意あるserver、同意画面の誤認、過剰scopeは自動では防ぎません。
- schema検証を権限確認と混同する。schema validationは入力妥当性の確認です。access権限の確認は、server側で別に行います。
- 未対応のclientで機密取得を続ける。MCP仕様versionとclient実装の差を確認します。unsupported clientでは、機密取得flowを無理にfallbackさせず、停止します。
- stdioやlocal secretを同じ前提で扱う。stdio transportやlocal secret取得は、別の脅威modelです。
form modeとURL modeは、何がどう違いますか？
form modeは通常の構造化入力、URL modeは資格情報の取得に使い、経路と守るべき点が異なります。
| 項目 | form mode | URL mode |
|---|---|---|
| 用途 | 用途名、期間、対象workspaceなどの通常項目 | API keyやpasswordなどの資格情報 |
| 入力の経路 | clientを通じて利用者へ提示 | browser上の外部認証flowでserverが直接受け取る |
| 守る点 | 長さ、format、enumの指定と、server側の権限確認 | redirect、state、audience、scopeの検証 |
| 残る限界 | schema検証は権限確認の代わりにならない | 悪意あるserverや同意画面の誤認は自動では防げない |
よくある質問
form modeでは尋ねません。serverが自然言語や通常のfieldで資格情報を尋ねると、機密が流れます。流れ先は、会話履歴、client log、model contextです。API keyやpasswordはURL modeを使います。browser上の外部認証flowで、serverが直接受け取ります。
用途名、期間、対象workspaceなど、server処理に必要な通常の項目に限ります。free textを万能欄にせず、長さ、format、enumを指定します。schema検証は入力の妥当性の確認です。access権限の確認は、server側で別に行います。
安全とまではいえません。URL modeは資格情報の漏えい経路を減らします。ただし、悪意あるserver、同意画面の誤認、過剰なscopeは自動では防ぎません。redirect URIの厳密照合やPKCE、audienceとscopeの検証、直前確認を重ねます。
次の一歩は何から始めればよいですか？
いまのserverが尋ねている項目を洗い出し、資格情報をURL modeへ移すことから始めます。
- serverがElicitationで尋ねている項目を洗い出します。
- 資格情報をform modeから外し、対応clientではURL modeの認証経路へ移します。個人番号などは取得の必要性を別に審査します。
- 公開前の脅威testで、拒否点とログの項目を確認します。
出典（一次情報と確認範囲）
確認日：2026年9月21日。海外の制度・製品仕様・研究結果は日本へそのまま適用せず、国内法・契約・対象条件を別途確認してください。