ツール実行では依頼した人と実行に使う権限を分けて追う
アプリが接続できることと、その利用者が操作してよいことは別。依頼者・顧客・接続先・許可範囲を実行側で結び付け、モデルに秘密のトークンを渡して権限を判断させない。
用語
- 委任
- ある主体が許可した範囲の操作を、別の主体が行うこと。
- サービスアカウント
- アプリや処理自体のための実行主体。個々の利用者と同じ権限とは限らない。
- audience
- トークンが利用されることを想定した宛先サービス。
図と例
依頼者と顧客を検証 → 用途に合う実行主体を選択 → 対象・委任範囲を認可 → 現在の権限で実行し監査
仮定の例：購買担当者は自部署の発注だけを許されるが、接続用アカウントは全社の発注を変更できる。モデルが他部署の注文IDを指定しても、実行側が担当者の部署と許可範囲を照合して拒否する。広い接続権限をそのまま全利用者へ与えない。
実際のサービス・製品では
Model Context Protocol
MCPの2025-11-25版に対応するセキュリティ資料は、サーバー宛てでないトークンを受け入れて下流へ渡すtoken passthroughを禁止し、宛先の検証や監査の境界を説明する。顧客業務の認可は追加で設計する。
資料を読む
解説
顧客の管理者権限で接続したデモのまま本番へ進めない。一般利用者、別顧客、接続解除、権限変更のケースで、実際の実行主体と拒否される範囲を確認する。
委任はある主体の許可した範囲で別の主体が操作する仕組み。利用者の代理権限と、アプリ自身のサービスアカウントの権限は同じではない。接続先が対応する委任方式を使うか、用途を限定したアプリ権限と利用者の業務認可を組み合わせる。顧客と接続資格情報の対応はサーバーで管理し、接続先アカウントをモデルの引数で自由に選ばせない。MCPを使う場合も、サーバー宛てのトークンを検証せずに下流APIへ通す設計は避ける。audienceはトークンの想定宛先で、トークンの有効性に加えて宛先や許可範囲を検証する。依頼者・実行主体・対象・結果を監査に結び付け、権限剥奪後やバックグラウンド再開時にも現在の許可を確認する。
トレードオフ
- 接続先が提供する利用者の委任方式を使う
- 得るもの：利用者単位の許可に沿って実行しやすい
- 払うもの：接続先の対応、同意、更新と失効の管理が必要
- 用途を限定したアプリ権限と業務認可を組み合わせる
- 得るもの：利用者単位の委任がない連携にも対応できる
- 払うもの：利用者・顧客・対象を実行側で制限し、広い権限の露出を防ぐ必要がある
さらに学ぶ
チェック
接続アカウントは全社の発注を変更できるが、依頼者は自部署のみ許可されている。他部署の注文IDをモデルが指定したら？
- 接続に成功したので実行する
- モデルに許可されると思うかを聞いて決める
- 実行側で依頼者の許可範囲を照合し、対象外なので拒否する
解答と解説
実行側で依頼者の許可範囲を照合し、対象外なので拒否する
接続アカウントの能力は依頼者の権限を証明しない。検証した主体と業務条件で対象を認可する。モデルの自己判断も認可の代わりにならない。