{
  "schemaVersion": "1.0",
  "language": "ja",
  "canonicalUrl": "https://catalysphere.co.jp/articles/ai-agent-delegated-authorization/",
  "machineReadableUrl": "https://catalysphere.co.jp/articles/ai-agent-delegated-authorization/index.json",
  "publisher": {
    "name": "Catalysphere",
    "url": "https://catalysphere.co.jp/",
    "description": "AIとビッグデータを研究し、実務へつなぐリサーチ＆コンサルティングスタジオ。"
  },
  "article": {
    "slug": "ai-agent-delegated-authorization",
    "title": "人のログイン流用ではエージェントの権限を統制できない",
    "titlePhrases": [
      "人のログイン流用では",
      "エージェントの権限を",
      "統制できない"
    ],
    "summary": "人のログイン状態を流用するのではなく、権限を委ねる人とAIエージェントを分け、対象・操作・相手先・期限を束ねた委任を実行時に検証する受入設計を示します。",
    "takeaways": [
      "人のログイン状態や、誰が使っても通る広範な資格情報をそのまま渡すと、AIエージェントだけの行為の帰属、権限の絞り込み、失効を人と切り離して扱えません。[1][4]",
      "認証に成功しても、それとは別に、権限を委ねた人、AIの実行主体、対象、操作、利用先、条件、期限をまとめて実行時に確認します。[2][3][5]",
      "本番投入前に、拒否・期限切れ・条件変更・古い要求の再利用・失効を試し、AIエージェントだけを停止できない設計は自動実行範囲を縮小します。"
    ],
    "publishedAt": "2026-08-27",
    "updatedAt": "2026-10-01",
    "readingMinutes": 11,
    "topics": [
      "AIエージェント",
      "AIセキュリティ",
      "アクセス制御",
      "AIガバナンス"
    ],
    "domains": [
      "generative-ai",
      "governance-risk",
      "organization-adoption"
    ],
    "evidenceKind": "research-review",
    "status": "published",
    "lead": "AIエージェントを業務システムへ接続するとき、ログインした人の権限をそのまま使わせれば設定は早く終わります。しかし同じ資格情報では、人の操作とAIエージェントの代理実行を分けて狭め、期限切れにし、停止できません。必要なのは認証を増やすことではなく、人から独立して評価・更新・失効できる委任です。本稿は一次資料の研究レビューで、効果実績や製品保証ではありません。",
    "sections": [
      {
        "heading": "同じログイン情報の中では、人とAIエージェントを止め分けられない",
        "paragraphs": [
          "仮想ケースとして、購買担当者のブラウザのログイン状態をAIエージェントが再利用し、発注候補を送信する場面を考えます。実在企業の事例ではありません。同じログイン情報なら業務システムから見える主体は担当者のままで、AIエージェントだけの操作範囲、期限、停止を別々に表せません。",
          "NIST/NCCoEの2026年文書は、人とソフトウェア／AIエージェントのID、利用者からの権限委任、AIエージェント固有の付与権限、行為帰属、IDの作成・更新・停止を連動させることを検討課題に置きます。[1] ただし構想段階の草案で、標準でも効果研究でもありません。",
          "問題は人に由来する権限ではありません。OpenID Foundationの白書が焦点を当てるのは、権限を委ねる人とAIの実行主体を区別できず、誰の操作か見分けられない代理実行です。[4] 元のログイン状態、パスワード、または持っているだけで使え、利用者ごとの差が分からない広範な接続用資格情報を、AI固有の識別子や利用アプリとのひも付けなしで渡すと、認証済みという事実がAIの行為範囲へ膨張します。"
        ]
      },
      {
        "heading": "正規のOAuthによる権限委任まで否定すると、自動化を誤って止める",
        "paragraphs": [
          "OAuthの権限委任は権限を持つ人、利用アプリ、認可サーバー、接続先システムを分け、利用者の同意または組織の方針に基づいて、制約付きの接続用資格情報（アクセストークン）を発行できます。RFC 9700は利用先、対象、操作への制限を要求ごとに確認するよう勧告します。[5] 人の代理という理由だけで委任を拒む必要はありません。",
          "受け入れるのはログイン状態そのものではなく、接続先を限定し、権限を必要範囲に絞り、有効期間が短く、利用アプリまたは送信元に結び付いた委任です。AIの実行主体を識別し、AIエージェントだけを更新・失効できれば、人から委ねられた権限でも元の資格情報の使い回しとは異なります。[4][5]",
          "本稿では、端末内の読み取り専用ツールをほかと分けたOSアカウントからSTDIO（標準入出力による端末内の接続）で呼び、外部データを変えない場合、OAuthの権限委任の記録を必須とはしません。MCPの基本仕様の認可は任意で、主にHTTP接続が対象です。[2] ただし読取範囲と停止責任者は別の境界で定めます。"
        ]
      },
      {
        "heading": "認証結果を、権限委任の記録へ変換する",
        "paragraphs": [
          "認証は誰またはどの自動処理かを確かめ、認可はその主体が対象へ操作を実行できる条件を決めます。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]"
        ],
        "visual": {
          "kind": "measurement",
          "eyebrow": "権限委任の記録／本稿のモデル",
          "title": "本稿の本番受入では、委任記録の全要素を結ぶ",
          "caption": "Catalysphereが複数の認可仕様を統合した論理モデルです。規格所定の共通様式や検証済み効果ではありません。記号「＋」は全条件を同時に満たすことを表し、複数段階の委任における即時失効が解決済みであるとは示しません。",
          "provenance": "catalysphere-authored",
          "equations": [
            {
              "label": "委任記録",
              "expression": "委任した人 ＋ AIの実行主体 ＋ 対象 ＋ 操作範囲 ＋ 利用先 ＋ 条件 ＋ 有効期限",
              "detail": "人の認証結果を流用するのではなく、誰が、どの実行主体へ、何を、どの相手先・条件・期限で委ねたかを一つの委任記録の版へ結びます。"
            },
            {
              "label": "実行時の許可",
              "expression": "許可 ＝ 実行主体を確認済み ＋ 委任が要求へ一致 ＋ 実行境界の方針が許可",
              "detail": "認証成功だけでは許可しません。接続先またはツールの実行境界が、要求ごとに実行主体、対象、操作、利用先、期限と条件を評価します。"
            },
            {
              "label": "本番受入",
              "expression": "本番受入 ＝ 実行主体のつながりをあとからたどれる ＋ AIの資格情報の更新・期限切れ・失効・古い要求の再利用試験が合格",
              "detail": "これはCatalysphereの受入基準です。失効とID廃止を分け、失効が下流へ届かない経路は未解決として残します。"
            }
          ],
          "items": [
            {
              "label": "権限を委ねる人",
              "value": "誰が委任したか",
              "detail": "正式なIDと承認記録へたどれる、権限を委ねた人を残し、AIの実行主体と同一視しません。"
            },
            {
              "label": "AI／自動処理",
              "value": "誰が実行するか",
              "detail": "利用アプリ・自動処理・資格情報のひも付けを人とは別に識別し、AIエージェントだけを停止できる単位にします。"
            },
            {
              "label": "対象と操作",
              "value": "対象・操作・利用先",
              "detail": "対象サービス、操作または権限範囲、接続用資格情報の利用先を実際の要求と照合します。"
            },
            {
              "label": "条件と有効期間",
              "value": "条件・期限・委任記録の版",
              "detail": "時間、取引、環境等の条件と期限を固定し、追加認可後の権限累積や古い委任の再利用を別途検査します。"
            },
            {
              "label": "承認と監査",
              "value": "何を承認し、何が起きたか",
              "detail": "操作内容のハッシュ値、認可判断、ツール実行と結果を結び、一般的な同意を個別操作の承認へ置き換えません。"
            },
            {
              "label": "独立した更新と停止",
              "value": "更新・期限切れ・失効・停止・廃止",
              "detail": "人のログイン状態を壊さずAIの権限だけを変更できるか試し、失効と恒久的ID廃止を区別します。"
            }
          ]
        }
      },
      {
        "heading": "権限の制約は、発行時だけでなく実行要求ごとに検証する",
        "paragraphs": [
          "委任記録があっても実行先が見なければ統制になりません。RFC 9700は利用先、対象、操作を要求ごとに検証し、MCPの基本仕様も接続先が異なる、無効、または期限切れの接続用の資格情報を拒否します。[2][5] 発行時の承認は実行時判断の代わりではありません。",
          "実際に使える権限は、委任記録に書いた上限、実行時方針、接続先システムが実際に強制できる能力の交差です。たとえば委任に「下書き作成のみ」と書いても、業務システム側が読み取り／書き込みを一つの大まかな権限区分でしか分けられなければ、文言だけでは送信を防げません。その差は隠さず、中継機能で操作を制限する、人の操作内容を特定した承認を残す、または自動化を拒否します。",
          "MCPの追加認可の手順は、それまでに要求した権限範囲と今回不足した権限範囲の和集合を要求するよう定めており、要求する権限範囲は既定で積み上がります（実際に付与する範囲は認可サーバーが決めます）。[2] 本稿はこの既定動作から意図的に外れ、追加した権限を常設の権限に含めず、対象操作と短い有効期限に限った別の資格情報として扱い、次の操作で再評価することを勧めます。"
        ],
        "bullets": [
          "実行時確認：接続先または信頼できる中継機能で要求ごとに制約を検証する",
          "機能差の扱い：接続先が強制できない条件を実装済みとして承認しない",
          "追加認可：追加権限を対象操作と短い期限へ結び、常設権限へ変えない"
        ]
      },
      {
        "heading": "確認画面は、実行待ちの操作と結び付いて初めて承認になる",
        "paragraphs": [
          "高影響操作の前に「実行しますか」と聞くだけでは、何を承認したかが曖昧です。Catalysphereは、承認を実行待ちの操作の対象、操作、主要条件値、影響上限、期限、AIの識別子、方針の版へ結び付けることを提案します。承認後に条件値または対象が変わったら、同じ承認を再利用せず、再評価します。",
          "仮想ケースの発注なら、「購買業務システムの利用を許可」では広すぎます。下書きだけか送信までか、取引先、金額上限、数量、重複防止キー、有効時間を固定し、送信直前の状態と一致したときだけ実行します。これは効果が実証された方式ではなく、承認の意味と実行内容がずれる誤承認を減らすための運用設計です。",
          "一方、低リスクで読み取り専用、可逆、回数制限付きな反復操作に毎回確認画面を出すと、承認疲れを増やし、自動化の便益を失います。範囲を限定した常設権限を認めるかは、状態変更、可逆性、影響上限、検証可能性で決めます。例外には責任者、理由、代わりとなる安全策、期限、再確認のきっかけを必須にし、恒久的な権限範囲拡張にしません。"
        ],
        "bullets": [
          "承認の決め方：承認をAIエージェント、対象、操作、主要条件値、上限、期限へ結び付ける",
          "変更時の扱い：対象または条件値が変われば承認を失効させて再評価する",
          "例外の決め方：例外に責任者、代わりとなる安全策、期限、再確認のきっかけを持たせる"
        ]
      },
      {
        "heading": "更新、期限切れ、失効、ID廃止は同じ操作ではない",
        "paragraphs": [
          "有効期間の短い接続用資格情報は露出時間を狭めても方針変更を即時反映しません。EMA安定版は期限付きID-JAGと利用先を限定したアクセストークンを定めますが、すでに発行したアクセストークンの即時無効化の仕組みやすべての接続先へ反映される期限は定めません。[3] 解説文書にある「即時」という説明は規格上の保証ではありません。",
          "OIDF白書もオフラインまたは複数段階の委任経路の迅速な失効は十分に解決していないと認めます。[4] 資格情報の失効、更新停止、IDの廃止、残存付与権限削除は別々に管理する処理です。ID削除だけで既発行接続用の資格情報が止まったと推定できません。",
          "本稿では、更新を有効期限延長ではなく、権限を委ねる人、AIの版、用途、対象、権限範囲、条件、例外を再評価する新しい決定として扱います。失効が届かない場合は短い有効期間、有効性照会、接続口での拒否、同じ系統の資格情報の一括停止等を組み合わせ、残る時間差を本番判断に明記します。[1][4][5]"
        ]
      },
      {
        "heading": "本番承認は、委任の存在ではなく失敗試験で決める",
        "paragraphs": [
          "権限委任の記録は認可判断の入力で、安全性の実績値ではありません。本番責任者が記録を持ち、ID・権限管理／対象システムの責任者は実行主体と対象、業務統制の責任者は操作条件、セキュリティ責任者は接続用の資格情報と利用アプリのひも付けと失効経路を承認します。内部監査は通常の共同設計者にはならず、後から独立して検証します。",
          "受入では拒否、期限切れ、条件変更、再利用、失効を先に試します。人の通常の利用を止めずにAIだけを停止できること、承認後の条件値変更が拒否されること、失効後の更新と接続先への要求が失敗することを確認し、即時失効を保証できない操作は残存時間を許容できる範囲へ戻します。",
          "取消不能な発注、通知、振込は接続用の資格情報を失効しても元には戻りません。取消・相殺の責任者と期限を定めます。本稿が扱うのは委任、制約、更新、有効期限、失効までで、ログ内容、保持、アクセス、削除は別の監査ログの契約へ渡します。"
        ],
        "bullets": [
          "受入条件：拒否、期限切れ、条件変更、再利用、失効の全試験が通るまで本番権限を与えない",
          "責任分担：本番、ID・権限管理／対象システム、業務統制、セキュリティの責任を記録上で分ける",
          "取消・復旧：不可逆な効果には取消・相殺の責任者、手順、期限を置く"
        ]
      }
    ],
    "note": "本稿はID／認可設計の研究レビューで、法的助言、製品保証、侵害低減効果の実証ではありません。NISTは草案、MCPの基本仕様の認可は任意かつHTTP中心、EMAは独立拡張仕様で策定中の仕様への依存があり、OIDFは白書です。[1][2][3][4] RFC 9700は汎用OAuthのセキュリティに関する現行のベストプラクティス（BCP）でAIエージェント固有の複数段階の委任管理を定めません。[5] 即時・連鎖的失効は未解決で、ログの保持・削除は対象外です。",
    "sources": [
      {
        "id": 1,
        "authors": "Harold Booth, William Fisher, Ryan Galluzzo, Joshua Roberts",
        "year": 2026,
        "title": "Accelerating the Adoption of Software and AI Agent Identity and Authorization",
        "venue": "NIST National Cybersecurity Center of Excellence",
        "url": "https://www.nccoe.nist.gov/publications/other/accelerating-adoption-software-and-ai-agent-identity-and-authorization-concept",
        "finding": "人とAIエージェントのID分離、利用者からAIエージェントへの権限委任、AIエージェント固有の付与権限、行為帰属、IDの作成・更新・停止を今後の実装検討領域として示す。",
        "limitation": "2026年2月の構想段階の草案であり、標準、完成した実装指針、比較試験または統制効果の実証ではない。"
      },
      {
        "id": 2,
        "authors": "Model Context Protocol Project",
        "year": 2026,
        "title": "Authorization — Model Context Protocol Specification 2026-07-28",
        "venue": "Model Context Protocol Specification",
        "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization",
        "finding": "HTTP要求ごとに、アクセストークンの利用先と有効性・有効期限の検証を必須とし、権限不足時の応答（推奨）と、以前の権限範囲との和集合を要求する追加認可の手順を定める。",
        "limitation": "MCP全体では認可は任意で、HTTP接続中心であり、AIの識別子、接続先のAPI、ID廃止または連鎖的失効の完全な全体設計ではない。"
      },
      {
        "id": 3,
        "authors": "Model Context Protocol ext-auth Project",
        "year": 2026,
        "title": "Enterprise-Managed Authorization",
        "venue": "MCP Authorization Extension",
        "url": "https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization",
        "finding": "組織のIdPが出す本人確認情報をID-JAGへ交換し、利用者、利用アプリ、対象、利用先、権限範囲、有効期限を保ったアクセストークンの発行手順を定める。",
        "limitation": "基本仕様ではない任意拡張仕様で、基礎仕様に策定中のIETF文書を含み、すでに発行したアクセストークンの即時失効の仕組みまたはすべての接続先へ反映される期限を規範的に保証しない。"
      },
      {
        "id": 4,
        "authors": "OpenID Foundation AI Identity Management Community Group; lead editor Tobin South",
        "year": 2025,
        "title": "Identity Management for Agentic AI: The new frontier of authorization, authentication, and security for an AI agent world",
        "venue": "OpenID Foundation Whitepaper",
        "url": "https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf",
        "finding": "利用者になり代わる不透明な方式に代えて権限を委ねる人とAIの実行主体を区別する委任、AIエージェント固有資格情報、作成・更新・停止、一連の委任経路を設計課題として整理する。",
        "limitation": "標準または査読済みの効果研究ではなく、組織やサービスをまたぐ・オフライン・複数段階の権限委任の迅速な失効を未解決とし、WorkOSの作業支援も開示する。"
      },
      {
        "id": 5,
        "authors": "Torsten Lodderstedt, John Bradley, Andrey Labunets, Daniel Fett",
        "year": 2025,
        "title": "Best Current Practice for OAuth 2.0 Security",
        "venue": "IETF BCP 240 / RFC 9700",
        "url": "https://www.rfc-editor.org/rfc/rfc9700.html",
        "finding": "接続用の資格情報を送信元、利用先、対象、操作へ制限して要求ごとに検証し、更新用の資格情報を利用アプリと委任へ束縛して定期更新、有効期限、失効を行うBCPを示す。",
        "limitation": "汎用OAuthの推奨セキュリティ対策であり、AIエージェント固有の権限を委ねる人と実行主体の表現、AIの識別子の作成・更新・停止、または権限委任の経路全体のAIだけの即時失効を定めない。"
      }
    ],
    "image": {
      "prompt": "Edit the referenced 16:9 editorial artwork for delegated AI-agent authority. Recompose the central metaphor to remove every key-like impression. Replace the large gold ring and straight shaft with a compact, softly woven antique-gold principal cluster. Keep a clearly separate cool-blue faceted workload identity, then a narrow translucent authorization aperture, then two or three small resource nodes. Place the principal cluster, workload identity, aperture, resource nodes, and one visibly closed lower branch all inside the middle 55% of the canvas so a narrow mobile crop retains the complete authority story. The closed lower branch must end at a dark translucent barrier while the main bounded path remains open, clearly suggesting agent-only revocation. Avoid a single horizontal shaft; use gently arcing, separate fine threads and generous negative space. Preserve the deep navy paper-grain background, restrained antique-gold and muted cobalt palette, translucent scientific geometry, fine particles, calm premium research-journal mood, and exact 16:9 framing. Constraints: absolutely no key, ring-and-shaft silhouette, padlock, text, letters, numbers, symbols resembling text, logos, watermark, people, robots, screens, dashboard UI, neon cyberpunk, or literal security icons.",
      "alt": "金色の人を示す形から青いAI、許可を確認する入口、三つの対象へ細い経路が伸び、別の下側の経路だけが透明な壁で止まる抽象図",
      "aspectRatio": "16:9",
      "assetPath": "article-art/ai-agent-delegated-authorization.png",
      "status": "approved"
    },
    "readingLayout": {
      "lead": {
        "sourceLength": 180,
        "sourceChecksum": "c9bcd9ab",
        "breaks": [
          106
        ],
        "emphasis": []
      }
    },
    "url": "https://catalysphere.co.jp/articles/ai-agent-delegated-authorization/",
    "machineReadableUrl": "https://catalysphere.co.jp/articles/ai-agent-delegated-authorization/index.json",
    "topicFacets": [
      {
        "id": "ai-systems",
        "name": "AIシステム",
        "url": "https://catalysphere.co.jp/topics/ai-systems/"
      },
      {
        "id": "safety-resilience",
        "name": "安全性・レジリエンス",
        "url": "https://catalysphere.co.jp/topics/safety-resilience/"
      },
      {
        "id": "governance-risk",
        "name": "AIガバナンス",
        "url": "https://catalysphere.co.jp/topics/governance-risk/"
      }
    ]
  }
}
