人のログイン流用ではエージェントの権限を統制できない

仮想ケースとして、購買担当者のブラウザのログイン状態をAIエージェントが再利用し、発注候補を送信する場面を考えます。実在企業の事例ではありません。同じログイン情報なら業務システムから見える主体は担当者のままで、AIエージェントだけの操作範囲、期限、停止を別々に表せません。

NIST/NCCoEの2026年文書は、人とソフトウェア／AIエージェントのID、利用者からの権限委任、AIエージェント固有の付与権限、行為帰属、IDの作成・更新・停止を連動させることを検討課題に置きます。[1] ただし構想段階の草案で、標準でも効果研究でもありません。

問題は人に由来する権限ではありません。OpenID Foundationの白書が焦点を当てるのは、権限を委ねる人とAIの実行主体を区別できず、誰の操作か見分けられない代理実行です。[4] 元のログイン状態、パスワード、または持っているだけで使え、利用者ごとの差が分からない広範な接続用資格情報を、AI固有の識別子や利用アプリとのひも付けなしで渡すと、認証済みという事実がAIの行為範囲へ膨張します。

OAuthの権限委任は権限を持つ人、利用アプリ、認可サーバー、接続先システムを分け、利用者の同意または組織の方針に基づいて、制約付きの接続用資格情報（アクセストークン）を発行できます。RFC 9700は利用先、対象、操作への制限を要求ごとに確認するよう勧告します。[5] 人の代理という理由だけで委任を拒む必要はありません。

受け入れるのはログイン状態そのものではなく、接続先を限定し、権限を必要範囲に絞り、有効期間が短く、利用アプリまたは送信元に結び付いた委任です。AIの実行主体を識別し、AIエージェントだけを更新・失効できれば、人から委ねられた権限でも元の資格情報の使い回しとは異なります。[4][5]

本稿では、端末内の読み取り専用ツールをほかと分けたOSアカウントからSTDIO（標準入出力による端末内の接続）で呼び、外部データを変えない場合、OAuthの権限委任の記録を必須とはしません。MCPの基本仕様の認可は任意で、主にHTTP接続が対象です。[2] ただし読取範囲と停止責任者は別の境界で定めます。

認証は誰またはどの自動処理かを確かめ、認可はその主体が対象へ操作を実行できる条件を決めます。MCP 2026-07-28の基本仕様は、HTTP要求ごとに、資格情報が自分宛てに発行されたこと（利用先）と有効で期限内であることをMCPサーバーが検証するよう義務付け、権限不足時の応答（推奨）と追加認可の手順を定めます。[2]

Enterprise-Managed Authorization（EMA）拡張仕様は、組織のID管理基盤（IdP）が発行した本人確認情報を、接続先側の認可サーバー宛てのID-JAG（IdPが発行する委任用の署名付き証明）へ交換し、MCPサーバー用のアクセストークンを得ます。例は利用者ID、利用アプリ、利用先、対象、権限範囲、発行時刻、有効期限を保持します。[3] ただしEMAは独立拡張仕様で、ID-JAGとIDの連鎖は策定中のIETF文書です。

本稿は権限を委ねる人、AI／自動処理の実行主体、利用アプリとのひも付け、対象、操作／権限範囲、利用先、条件、発行時刻／有効期限、承認、失効用識別子を一つの権限委任の記録へ束ねることを提案します。単一規格の要求ではなく、Catalysphereの統合です。[2][3][4][5]

委任記録があっても実行先が見なければ統制になりません。RFC 9700は利用先、対象、操作を要求ごとに検証し、MCPの基本仕様も接続先が異なる、無効、または期限切れの接続用の資格情報を拒否します。[2][5] 発行時の承認は実行時判断の代わりではありません。

実際に使える権限は、委任記録に書いた上限、実行時方針、接続先システムが実際に強制できる能力の交差です。たとえば委任に「下書き作成のみ」と書いても、業務システム側が読み取り／書き込みを一つの大まかな権限区分でしか分けられなければ、文言だけでは送信を防げません。その差は隠さず、中継機能で操作を制限する、人の操作内容を特定した承認を残す、または自動化を拒否します。

MCPの追加認可の手順は、それまでに要求した権限範囲と今回不足した権限範囲の和集合を要求するよう定めており、要求する権限範囲は既定で積み上がります（実際に付与する範囲は認可サーバーが決めます）。[2] 本稿はこの既定動作から意図的に外れ、追加した権限を常設の権限に含めず、対象操作と短い有効期限に限った別の資格情報として扱い、次の操作で再評価することを勧めます。

• 実行時確認：接続先または信頼できる中継機能で要求ごとに制約を検証する
• 機能差の扱い：接続先が強制できない条件を実装済みとして承認しない
• 追加認可：追加権限を対象操作と短い期限へ結び、常設権限へ変えない

高影響操作の前に「実行しますか」と聞くだけでは、何を承認したかが曖昧です。Catalysphereは、承認を実行待ちの操作の対象、操作、主要条件値、影響上限、期限、AIの識別子、方針の版へ結び付けることを提案します。承認後に条件値または対象が変わったら、同じ承認を再利用せず、再評価します。

仮想ケースの発注なら、「購買業務システムの利用を許可」では広すぎます。下書きだけか送信までか、取引先、金額上限、数量、重複防止キー、有効時間を固定し、送信直前の状態と一致したときだけ実行します。これは効果が実証された方式ではなく、承認の意味と実行内容がずれる誤承認を減らすための運用設計です。

一方、低リスクで読み取り専用、可逆、回数制限付きな反復操作に毎回確認画面を出すと、承認疲れを増やし、自動化の便益を失います。範囲を限定した常設権限を認めるかは、状態変更、可逆性、影響上限、検証可能性で決めます。例外には責任者、理由、代わりとなる安全策、期限、再確認のきっかけを必須にし、恒久的な権限範囲拡張にしません。

• 承認の決め方：承認をAIエージェント、対象、操作、主要条件値、上限、期限へ結び付ける
• 変更時の扱い：対象または条件値が変われば承認を失効させて再評価する
• 例外の決め方：例外に責任者、代わりとなる安全策、期限、再確認のきっかけを持たせる

有効期間の短い接続用資格情報は露出時間を狭めても方針変更を即時反映しません。EMA安定版は期限付きID-JAGと利用先を限定したアクセストークンを定めますが、すでに発行したアクセストークンの即時無効化の仕組みやすべての接続先へ反映される期限は定めません。[3] 解説文書にある「即時」という説明は規格上の保証ではありません。

OIDF白書もオフラインまたは複数段階の委任経路の迅速な失効は十分に解決していないと認めます。[4] 資格情報の失効、更新停止、IDの廃止、残存付与権限削除は別々に管理する処理です。ID削除だけで既発行接続用の資格情報が止まったと推定できません。

本稿では、更新を有効期限延長ではなく、権限を委ねる人、AIの版、用途、対象、権限範囲、条件、例外を再評価する新しい決定として扱います。失効が届かない場合は短い有効期間、有効性照会、接続口での拒否、同じ系統の資格情報の一括停止等を組み合わせ、残る時間差を本番判断に明記します。[1][4][5]

権限委任の記録は認可判断の入力で、安全性の実績値ではありません。本番責任者が記録を持ち、ID・権限管理／対象システムの責任者は実行主体と対象、業務統制の責任者は操作条件、セキュリティ責任者は接続用の資格情報と利用アプリのひも付けと失効経路を承認します。内部監査は通常の共同設計者にはならず、後から独立して検証します。

受入では拒否、期限切れ、条件変更、再利用、失効を先に試します。人の通常の利用を止めずにAIだけを停止できること、承認後の条件値変更が拒否されること、失効後の更新と接続先への要求が失敗することを確認し、即時失効を保証できない操作は残存時間を許容できる範囲へ戻します。

取消不能な発注、通知、振込は接続用の資格情報を失効しても元には戻りません。取消・相殺の責任者と期限を定めます。本稿が扱うのは委任、制約、更新、有効期限、失効までで、ログ内容、保持、アクセス、削除は別の監査ログの契約へ渡します。

• 受入条件：拒否、期限切れ、条件変更、再利用、失効の全試験が通るまで本番権限を与えない
• 責任分担：本番、ID・権限管理／対象システム、業務統制、セキュリティの責任を記録上で分ける
• 取消・復旧：不可逆な効果には取消・相殺の責任者、手順、期限を置く