安全性と監視更新日 2026-08-22 · バージョン 1.0

最小権限ツール

エージェントにはタスクが実際に必要とする最も狭いツールのセットを、各ツールには最も狭いスコープを提供します。このパターンは、プロンプトインジェクションが成功することがあるという前提を受け入れ、乗っ取られたエージェントができることを制限します。モデルにパッチを当てることはできませんが、モデルがアクセスできる範囲を決定することはできます。

エビデンス: 本番環境確信度: ソース: 本番システムソース: 個人の経験ソース: 業界での観察

定義

最小権限ツールとは、エージェントのツールカタログと各ツールの基盤となる資格情報を、タスクが必要とする最小限に制限するプラクティスです。これにより、攻撃の成功やモデルのエラーによる影響は、モデルのコンプライアンスではなく、設計によって制限されます。

課題

広範なツールと広範な資格情報を与えられたエージェントは、インジェクション、ジェイルブレイク、またはハルシネーションの成功を、その背景にあるアカウントの全権限を伴う実際のアクションに変えてしまいます。

適用対象

APIの呼び出し、ファイルの書き込み、メッセージの送信、資金の移動など、エージェントがアクションを実行できるあらゆる場所で使用します。自律性が高く、人間によるレビューが少ないほど、プロンプトではなく権限レイヤーで影響範囲を設定する必要があります。

解決策

プラットフォームからではなく、タスクから始めてください。エージェントが実行する必要がある操作をリストアップし、それらのみを公開します。『APIが提供するもの』から組み立てられたカタログは、誰もレビューしていない権限付与になってしまいます。

読み取りと書き込みを分割します。ツールを分け、資格情報を分け、読み取りツールの引数からアクセスできる書き込みパスを排除します。データの変更も可能な『クエリ』エンドポイントは、最も一般的な、気付きにくい権限昇格の原因です。

ツールだけでなく、資格情報もスコープ制限します。管理者トークンに裏打ちされた読み取り専用ツールは、バグが1つあるだけで書き込みツールになり得ます。アップストリームシステムがサポートする最も狭いスコープで、ツールごとの資格情報を発行してください。

パラメータを制限します。ツールがアクセスできるパス、リポジトリ、テーブル、アカウント、または受信者をホワイトリストに登録し、乗っ取られたエージェントが正当なツールを不正なターゲットに向け直すことができないようにします。

権限付与に有効期限を設け、レビューを実施します。ツールは蓄積されていくため、呼び出されていないものは削除し、ツールの追加は権限の変更として扱ってください。

権限付与と呼び出しを個別にログに記録します。エージェントが実行できたことと、実際に実行したことは異なる監査対象であり、インシデント対応にはその両方が必要です。

コンポーネント

ツールごとに明示的かつ書面で定義されたスコープを持つツールカタログ。アップストリームシステムが提供する最も狭いスコープで発行された、ツールごとの資格情報。ツールがアクセスできるターゲットのパラメータホワイトリスト。モデルとは独立して各呼び出しを認可するポリシーレイヤー。権限付与と呼び出しの両方をカバーする監査ログ。呼び出されていないツールを削除する定期的なレビュー。

メリット

  • モデルが適切に動作することに依存せずに、インジェクション成功時の被害を制限します。
  • 『このエージェントは安全か?』という問いを、ツール、スコープ、所有者のリストというレビュー可能な成果物へと変換します。
  • 副次的な効果として、ツールの選択精度が向上します。ツールが少なく、役割が明確であるほど、モデルは選択しやすくなります。
  • インシデント発生前にアクセス可能な範囲が判明しているため、インシデントの調査が可能になります。

リスク

  • 利便性によるスコープの肥大化。デバッグ中に広範なトークンを貼り付け、その後スコープを狭めないまま放置すること。
  • 断片化。モデルが区別できないほど細分化された多数のツールが存在し、セキュリティ上のメリットと引き換えに信頼性が低下すること。
  • 誤った安心感。最小権限は影響を制限するだけであり、攻撃を防ぐものではなく、正当に付与された読み取りツールを介した情報漏洩については何も保証しません。
  • プロセスの停滞。スコープ制限された資格情報の発行が、広範な資格情報の再利用よりも困難な場合、プロセス自体が脆弱性になります。

非推奨のケース

  • 本番環境へのアクセスがない合成データ上のプロトタイプなど、手続きのコストが排除されるリスクを上回る場合。
  • アップストリームプラットフォームがスコープをまったく表現できない場合。この場合、制御は要件を満たしたと宣言するのではなく、その手前にあるプロキシに移動します。
  • エージェントの権限を狭めることで、それ自体が制限や監査の不十分な人間のプロセスに作業が押し付けられてしまう場合。

テクノロジー

Scoped API tokensPolicy engines (OPA / Cedar)MCP tool scopingPer-tool service accountsAudit logging

事例

  • 1つのリポジトリと1つのブランチプレフィックスにスコープが限定され、組織全体の読み取り権限を持たないリポジトリトークンを付与されたコーディングエージェント。依存関係のREADMEを介したインジェクションによってブランチが作成される可能性はありますが、他の40のリポジトリにアクセスすることはできません。
  • CRMツールが分割されているサポートエージェント:読み取り専用キーを持つ `read_customer` と、すでに会話内にあるチケットに制限された `update_ticket`。セッションが乗っ取られたとしても、1つのチケットに嫌がらせをすることはできますが、顧客ベース全体をエクスポートすることはできません。
  • カタログ全体がすでに公開されているコンテンツに対するゲッター(getter)のみで構成され、資格情報を一切持たないパブリックMCPサーバー。漏洩するものが何もないため、失効させるべきものもありません。

本番環境での実績

コンテキスト
インターネット上のあらゆるエージェントからアクセス可能な、このナレッジベースのパブリックMCPエンドポイント。
シナリオ
コーパスは公開されており読み取り専用であるため、カタログはすべてゲッター(getter)です。書き込みを行うツールや、サイトがすでに公開しているもの以外のデータベースにアクセスするツールはなく、どのツールからもアクセスできる資格情報はありません。
テクノロジー
Next.jsのルートハンドラー上でのHTTP経由のステートレスJSON-RPC、ハンドラー実行前のオリジン許可リストのチェック、Redisによる呼び出し元ごとのレート制限、呼び出しごとの構造化監査ログの記録。
負荷
ローンチ以来、継続している無人のエージェントトラフィックに加え、レジストリクローラーやディレクトリのヘルスチェック。
結果
プロンプトインジェクションによってこのサーバーのクライアントが乗っ取られたとしても、アクセス可能な範囲は公開されているコーパスと完全に一致しているため、公開サイトから取得できるもの以外の情報は取得できません。失効させるべき資格情報も、悪用される書き込みパスも存在しません。

KPI

エージェントあたりのツール数
カタログの規模。削除を伴わない増加は、権限がレビューされずに蓄積されている兆候です。
書き込み可能なツールの割合
カタログのうち、状態を変更できるものの割合。タスクが許容する最小限に向けて削減すべき数値です。
最も古い未使用ツールの経過日数
付与されたツールが最後に呼び出されてからの日数。長期間未使用の権限は、誰も必要としないにもかかわらず、攻撃者に引き継がれてしまうアクセス権となります。
スコープドキュメントのカバー率
文書化されたスコープと指名された所有者を持つツールの割合。ドキュメントのないツールは、制限のないツールと同義です。

観察された失敗パターン

  • 読み取り専用ツールの背後にある管理者トークン:スコープはツールレイヤーで宣言されているものの、資格情報レイヤーでは制限されていません。
  • パラメータの再指定:引数を制限するものが何もないため、ツール自体は正当であっても、ターゲットが不正になります。
  • 混乱した代理(Confused deputy):実行権限の主体を絞り込まずにツールだけを絞り込んでも、呼び出し元がエージェントのアクセス権を引き継ぐため、何も変わりません。
  • カタログのドリフト:実験のために追加されたツールがそのまま残り、レビューされた権限セットと実際にデプロイされている権限セットが乖離してしまいます。

得られた教訓

  • インシデントが発生した後ではなく、ツールを付与する前に影響範囲(ブラスト半径)を文書化してください。
  • ツールの名前はそのスコープではありません。サーバー側の資格情報のみがスコープを決定します。
  • 誰からも呼び出されないツールを削除することは、最も低コストで実施できるセキュリティ対策です。
  • 最小権限は2つのメリットをもたらします。攻撃を制限することと、エージェントによるツールの選択精度を向上させることです。

FAQ

最小権限はプロンプトインジェクションを防げますか?
いいえ、それを目的としたものではありません。インジェクションは時として成功することを前提とし、成功した場合に何ができるかを事前に制限します。予防と封じ込めは異なる役割であり、制御可能なのは封じ込めだけです。
どの程度まで絞り込むと狭すぎる(過剰な制限になる)のでしょうか?
モデルが2つのツールを区別できなくなったとき、または1回で安全に処理できる定型タスクに4回の呼び出しが必要になったときです。分割はセキュリティを向上させますが、ツールの誤選択を招くようになれば逆効果であり、誤った呼び出し自体が失敗の原因となります。
すべての処理に1つのサービスアカウントを使用しています。それはそんなに悪いことですか?
それは、すべてのエージェント(およびエージェントに到達したすべての攻撃者)が、実行される最も広範なタスクのアクセス権を持つことを意味します。1つのアカウントを使用することは、このパターンにおいて影響範囲(ブラスト半径)が『すべて』になることを意味します。

参考文献