AI Agent の最小権限実践：能力タグによる認可モデル · Insights

「まず動かす」が残す負債

Agent 導入の典型的な流れはこうです。使えるトークンを渡し、業務フローを通し、価値を確認し、運用に乗せる。

この流れ自体は誤りではありません。価値の検証を先に行うのは妥当な工学的判断です。問題は次の段階にあります。権限を後から絞り直したチームがほとんど存在しないという点です。デバッグの都合で渡した組織全体に通用するトークンが、そのまま Agent とともに本番へ入っていきます。

その帰結は理論上の話ではありません。Agent の振る舞いはコードで固定されるのではなく、モデルによって動的に決まります。つまり「今できること」と「これから行うこと」の間に確定的な対応関係がありません。タスクに必要な範囲を超えた権限を持たせているとき、実質的にはモデルの判断力を安全境界として使っていることになります。そしてそのモデルの判断力こそ、プロンプトインジェクションが狙う対象です。

従来の IAM では足りない理由

企業には成熟した ID・アクセス管理の仕組みがありますが、そのまま Agent に当てはめると 3 つのずれが生じます。

主体が安定しません。 IAM は主体（利用者、サービス）の行動様式が比較的固定であることを前提とします。Agent の振る舞いはタスク、文脈、モデルのバージョンによって変わり、静的なロールで記述すること自体に無理があります。

権限の粒度が合いません。 IAM は通常、リソースと操作の単位で認可します（「S3 バケット X を読める」）。一方 Agent のリスク単位は能力です（「任意のローカルファイルを読める」「外部へ通信できる」）。同じ能力が複数のツールとリソースにまたがることもあれば、一つのツールが複数の能力を同時に持つこともあります。

認可のタイミングが違います。 従来の認可は導入時の一度きりの判断です。Agent の生態系ではツールが随時追加・削除され、MCP Server は静かに更新されます。権限面が動き続けるため、必要なのは一度の承認ではなく継続的な評価です。

能力タグ：「何ができるか」を標準化する

現実的な方法は、ツールと権限の間に抽象化の層を挟むことです。それが能力タグです。

「この MCP Server の名前は何か」ではなく、「有効化されたとき Agent はどの能力を得るのか」を問い、その答えを一組のタグとして標準化します。典型的な能力領域には次のようなものがあります。

ファイルシステム：任意パスの読み取り / 指定ディレクトリの読み取り / 書き込み / 削除
プロセス実行：シェルコマンド / 子プロセス生成
ネットワーク：外部への要求 / ポート待ち受け / 内部ネットワークへのアクセス
認証情報：環境変数の読み取り / 秘密情報ストアへのアクセス / 既存セッションの利用
データ操作：永続データの読み取り / 変更 / 削除
対外通信：メール送信 / コンテンツ公開 / 支払いの実行

この語彙の価値は、比較可能で方針化できる点にあります。「シェル実行タグを持つツールはすべて人による承認を要する」と定めれば、ツールごとに議論する必要がありません。ツール更新後にタグを付け直し、タグの変化を再評価の起点にすることもできます。宣言された能力が変わったなら、リスク面が変わったということです。

認可の 3 原則

1. ツール単位ではなく、タスク単位で認可します。

Agent が完了すべきタスクにどの能力が必要かを先に定義し、それに基づいてツールと認証情報を選びます。この順序が重要です。逆——先にツールを選び、次にそれが求める権限を見る——では、ほぼ確実に過剰な認可に至ります。ツールの作者は、より多くの場面を覆うためにより広い権限を求める傾向があるからです。

2. 能力の組み合わせに注意します。

単独では無害な能力も、組み合わせるとそうではなくなります。「ローカルファイルの読み取り」と「外部への要求」を合わせればデータ持ち出しの能力になり、「環境変数の読み取り」と「シェル実行」を合わせれば認証情報の窃取と横展開になります。認可の審査は能力集合の相互作用を見る必要があり、項目ごとにチェックを入れる作業では足りません。

実際の事故の多くはここから生まれます。個々のツールはどれも妥当に見え、組み合わさったときに完全な攻撃経路が開くのです。

3. 不可逆な操作は個別に関門を設けます。

削除、支払い、対外送信、本番設定の変更。これらに共通するのは、誤りを取り消せないことです。通常の権限から切り離し、Agent がどれほど信頼されていても、明示的な確認か独立した承認を要求すべきです。

実装：3 つの段階

導入時：各ツール／MCP Server に能力監査を行い、タグ集合を作り、宣言と実装を突き合わせます（カレンダーを読むだけと称するツールの実装にファイル書き込み能力がある——この不一致自体がリスクの兆候です）。ここから block / need_review / pass の判定を出します。

実行時：認証情報を Agent ごと、タスクごとに分離し、範囲を最小化し、個別に失効できるようにします。ネットワーク出口の許可リストを最後の受け皿として置きます。ツールが汚染されても、データは外に出られません。

継続的に：Agent の実際のツール呼び出しを記録し、認可範囲と突き合わせます。長期間使われていない能力は回収すべきです。最も見落とされやすく、しかも最も低コストな引き締め手段です。ツールのバージョンが変われば再評価を起動します。

「使えるかどうか」から「何ができるか」へ

Agent セキュリティの中心的な問いは、「このツールは悪意あるものか」から「このツールが有効化されたとき、Agent は承認を要するどの能力を得るのか」へ移りつつあります。前者は悪性検知の問題であり、後者は能力監査の問題です。そして企業の導入判断が必要とするのは、後者の答えです。

これが SkillSec の方法論的な土台です。Agent 生態系の部品（Skills、MCP Server）を能力領域ごとに分解し、等級付けされた証拠で判定を支えることで、権限の判断を「悪そうに見えるかどうか」ではなく「何ができるのか」の上に置きます。

最小権限は新しい概念ではありません。Agent の文脈でより難しく、より重要になっただけです。今回は、権限を与えられた主体が自分で何をするかを決めるからです。

---