こんにちは、ネクストモードのゆきなわです。
AI エージェントが SaaS を操作するとき、使われる権限は利用者本人のものとは限りません。エージェント専用の ID で動く場合もあれば、あらかじめ保存された接続の資格情報で動く場合もあります。
本記事では、エージェントの権限主体（誰の権限で動くか）を次の3つのモデルに分け、企業の情報セキュリティ担当者が確認すべきポイントを整理します。
本記事の想定読者と扱う範囲は次のとおりです。
本記事のポイント
- AI エージェントは、必ずしも利用者本人の権限を上限として動くわけではありません。
- ユーザー・エージェント・SaaS・ID 基盤を分けて捉えると、権限の境界を把握しやすくなります。
- エージェントを使える権限と、エージェントが SaaS（やそのデータ）にアクセスできる権限は別物です。
企業における AI エージェントの利活用は、試験利用から業務利用の段階へ移りつつあります。Okta が経営層・VP クラスを対象に実施した2025年の調査（AI at Work 2025）では、91% の組織がすでに AI エージェントを利用しています。
一方で、IT 部門の把握や承認を経ないまま、従業員が AI ツールやエージェントを業務データに接続するシャドー AI（エージェントによるものはシャドー AI エージェントとも呼ばれます）が統制上の課題になっています。エージェントは承認画面の外でも自律的に動き、接続と資格情報は利用部門ごとに増え続けるためです。
この課題への対応として、AI エージェントを人間のユーザーと同じように ID 基盤で管理する仕組みの整備が進んでいます。Okta for AI Agents、Microsoft Entra Agent ID、Google Cloud の Agent Identity、Amazon Bedrock AgentCore の Identity など、エージェントを個別の ID として登録・管理する製品が主要ベンダーから登場し、接続認可を IdP へ集約する標準仕様（第2回で扱う ID-JAG や MCP の Enterprise-Managed Authorization）の策定も進んでいます。
本シリーズでは、こうした仕組みが AI エージェントの認証・認可の課題をどこまでカバーできるのかを、Okta for AI Agents を中心に他製品とも比較しながら紐解いていきます。第1回はその土台として、権限主体のモデルと判断の手がかりを整理します。全3回の構成は次のとおりです。
本シリーズの軸となる Okta for AI Agents の機能全体像は、弊社記事「Okta for AI Agents とは？シャドー AI 時代に備えるエージェント管理の全体像」で解説しています。
AI エージェントが外部の SaaS を操作するとき、そこで適用される権限の主体は一通りではありません。本記事では、その違いを次の3つのモデルに分けます。あわせて、それぞれで見るべき管理ポイントも整理します。
| モデル | 権限の基準（誰の権限で動くか） | 主な管理ポイント |
|---|---|---|
| A：ユーザー代理型 | 委任元ユーザー。リソース側でそのユーザーの権限が適用される | 委任範囲、スコープ、実行時ポリシー |
| B：エージェント独立権限型 | エージェント専用のワークロード ID | 所有者、最小権限、共有先 |
| C：保存接続依存型 | 保存された資格情報。実際の利用者権限で再評価されない | 接続所有者、共有範囲、資格情報の回収 |
利用者の直感に近いのはモデル A ですが、統制上の盲点になりやすいのは B と C です。
最も一般的で直感にも近いモデルです。「Slack の未読を要約して Notion のデータベースに起票してほしい」とユーザーが頼むケースがこれに該当します。下流アクセス（エージェントから見た接続先サービスへのアクセス）は特定ユーザーの委任に結び付き、リソース側でそのユーザーの権限が適用されます。
委任を実現する代表的な仕組みは2つあります。ひとつは Microsoft 環境の OBO (On-Behalf-Of) フロー、もうひとつはベンダー非依存の標準である OAuth 2.0 Token Exchange（RFC 8693）です。どちらもユーザーとエージェントの委任関係を表現できますが、同一のフローではありません。OBO は JWT bearer グラントと requested_token_use=on_behalf_of を使う Microsoft 固有のフローで、RFC 8693 は委任・偽装を汎用的に表現できるトークン交換の標準仕様です。
注意したいのは、OBO や Token Exchange を使うだけでは、ユーザー権限が自動的に上限になるわけではない点です。モデル A の実効権限は、次の4つの条件がすべて重なる範囲に決まります。
認可サーバーやリソース側などの各制御ポイントがそれぞれの条件を適用し、どれか1つでも許可しない操作は実行できません。結果として、実効権限はユーザー権限以下に保たれます。
特定ユーザーの代理ではなく、エージェント専用のワークロード ID が権限主体になるモデルです。運用上は、必ず人間のオーナーを紐づけたうえで最小権限を与え、エージェント停止時に権限を回収できるようにしておくことが前提になります。ワークロード ID の割り当てや認証方式（client credentials グラントなど）は、後述のエージェント認証で扱います。
このモデルでは、管理する権限が2つに分かれます。どのデータにアクセスできるかはエージェント側の権限で決まり、ユーザー側に残るのはそのエージェントを使えるかどうかという利用権限です。両者はまったく別の管理対象であり、ユーザー本人の直接アクセス権はエージェントの権限上限にはなりません。
ただし、モデル B が常に利用者の権限を超えた開示につながるわけではありません。分かれ目は、エージェントが取得した結果を利用者の権限で再評価・再フィルタするかどうかです。再評価する設計であれば、エージェント ID の権限が広くても、利用者への開示範囲は本人の権限内に抑えられます。再評価しない設計では、利用者はエージェントを介して、本人が直接アクセスできない情報を受け取る可能性があります。
このモデルの代表例が、後述する Notion のカスタムエージェントです。
接続を最初に作成した人や共有アカウントの資格情報が保存され、実際の利用者やタスクの権限で再評価されないまま使われ続けるモデルです。典型例は、ある担当者が自分のアカウントで MCP 接続を認可・保存し、その接続をチームで共有するケースです。以後は誰がエージェントを使っても、外部 SaaS 側では接続作成者の権限で操作が実行されます。
この形態では、誰がエージェントを使うかと外部 SaaS で実際に何ができるかが乖離しやすくなります。SaaS 側の監査ログに記録される主体も接続作成者となるため利用者単位の追跡が難しく、作成者の異動・退職後も保存された資格情報が有効なまま残る可能性があります。統制の方法は第2回・第3回で詳しく扱います。
モデル A / B / C を分ける基準
分類の軸はいまエージェントを起動している人がいるかではなく、下流アクセスの認可主体が誰かです。たとえばスケジュール実行のような無人実行でも、委任元ユーザーの認可を継続適用し、リソース側でそのユーザーの権限が適用されるならモデル A です。保存されたリフレッシュトークンで動く場合も同様で、リフレッシュトークンはリソースオーナーであるユーザーがクライアントへ与えた認可を表すからです。
- A：下流アクセスが特定ユーザーの委任に結び付き、リソース側でそのユーザー権限が適用される。
- B：エージェント専用のワークロード ID が権限主体になる。
- C：接続作成者や共有アカウントの保存資格情報が、実際の利用者・タスク所有者の権限で再評価されずに使われる。
B と C の境界は、サービスアカウントの持ち方で整理できます。エージェントごとに専用のサービスアカウントを割り当てるなら B、複数のエージェントや利用者で1つのサービスアカウントを共有するなら C です。
実際の判別には、次の観点が使えます。
- アクセストークンの
sub/act/client_id（実装によりazp）に誰が現れるか- 資格情報を保管しているのは誰か
- SaaS 側の監査ログに記録される主体は誰か
- リソース側で利用者権限を再評価・再フィルタするか
ここまでの3モデルを具体的に理解できる実例が、Notion のカスタムエージェントです。通常の Notion AI は、利用者本人の権限を継承して動作します（モデル A）。これに対してカスタムエージェントは、独立した権限を持つチームメンバーのように機能します（モデル B）。さらに外部サービスへの接続では、保存された接続を共有するモデル C の要素も併存します。モデル A / B の違いは Notion 公式ヘルプにも明記されています。カスタムエージェント自体の機能や構築方法の詳細は、下記の弊社記事で解説しているのでご参照ください。
公式ヘルプの「予算ボット（BudgetBot）」の例は、この設計思想をよく表しています。エージェントには財務チーム限定のページへのアクセス権を付与し、各部門のリードにはエージェントの利用権限だけを渡します。部門リードは財務ページそのものを開くことなく、自部門の予算状況など必要な答えだけをエージェントへの質問で得られます。財務データを扱える担当者に問い合わせて回答をもらう、という人間同士の業務フローをエージェントに置き換えた形です。
Notion はこの動作を、下記の公式ブログにて「権限の境界を越えて業務を調整できるようにするための意図的な仕様」と説明しています。エージェントを、固有のアクセス権を持つ独立したチームメンバーとして扱う発想です。依頼者が作成者と異なる共有利用でも、対話ユーザーが存在しない定時・イベント実行でも一貫して動けるのは、この独立したアクセス権があるためです。ただし裏を返せば、部門リードは本来直接アクセスできない財務情報をエージェント経由で取得できることになります。同記事にも、エージェントがエンドユーザーより多くの行を閲覧できる場合、本来アクセスできない情報を返し得るとの記載があります。
独立権限型で注意したいリスクは、大きく2つに分けられます。
2つ目のリスクについては、Notion 自身が公式ブログで初期の社内版の事例を挙げています。ユーザーがエージェントに広い Slack 書き込み権限を与えがちだったため、全社チャンネル #general への意図しない投稿が発生しました。この経験から、Slack の細粒度権限などの統制が追加されています。
これら2つのリスクは、独立権限型に特有の新種というより、従来の代理主体や共有サービスアカウントにもあった問題が、共有利用と自動実行によって顕在化したものです。構造としては権限を持つ代理主体を介した越境アクセスであり、それ自体は意図された設計です。ただし、依頼者やタスクに対する認可確認が不十分な場合には、confused deputy（権限を持つ主体が第三者の依頼で権限を不適切に行使する問題）へ発展し得ます。
こうしたリスクに対して Notion は設計上の対策を講じています。エージェントのライフサイクルに沿って見ると次の3つになります。
ただし、Notion が制御できるのは、接続できるリソースやツールの範囲と操作時の確認、つまり自社プラットフォームの内側までです。接続先 SaaS での最終認可、アクセストークンの失効、接続先に残る操作ログは、Notion 単独では完結しません。複数の SaaS をまたぐ接続と資格情報の統制には、各サービスの管理機能や ID 基盤を組み合わせた設計が必要です。このプラットフォームの外側をどう統制するかが、第2回以降の主題になります。
Notion の例が示すとおり、同じ製品の中でも異なる権限モデルが併存することがあります。自社のエージェントがどのモデルにあたるかは、登場人物を分け、どこで認可が決まるかを追うことで判別できます。本章では、登場人物を整理する4者モデル、2種類の認証、認可を決める7つの確認ポイントの順に、判断の道具立てを揃えます。
ユーザーが SaaS にログインして操作する従来の構図では、1) ユーザー、2) SaaS、3) ID 基盤（認証と認可を担う）の3つが主な主体でした。AI エージェントの導入により、ここにユーザーの代わりに判断・操作する第4の主体が加わります。本シリーズでは、この4つをまとめて4者モデルと呼びます。
| 主体 | 役割 | 認証・認可上の責務 |
|---|---|---|
| ユーザー | 業務上の依頼者・利用者。モデル A ではデータ権限の主体でもある | SSO・MFA で認証され、条件付きアクセスで制御される |
| AI エージェント | タスクを実行して SaaS / API を操作する非人間主体。ユーザー代理・専用 ID・保存資格情報のいずれでも動き得る | 自身の ID を持ち、どの主体・目的・条件で動くかを制約される |
| SaaS / リソースサーバー | エージェントが操作する業務アプリ / API | 受け取ったアクセストークンを検証し、アプリ内権限で最終判定する |
| ID 基盤（IdP） | 認証・接続認可・ライフサイクル管理の起点 | ユーザーとエージェントの認証、接続認可、トークン発行から失効・監査までを担う（構成により認可サーバーを兼ねる） |
なお、4者モデルは OAuth 2.0 の4ロール（resource owner、client、authorization server、resource server）におおむね対応しますが、一対一の対応ではなく、本シリーズの説明のための抽象化です。AI エージェントは OAuth に新しいロールを追加するものではありません。従来から存在した client / application が、自律的に判断・操作する主体として明示的な管理対象になった、と捉えるのが実態に即しています。
4者の間で取り交わされるやり取りは、1) 誰なのかを確かめる認証と、2) 何をしてよいかを決める認可に大別されます。AI エージェントが加わることで、どちらにも従来の人間向けの仕組みだけでは足りない要素が出てきます。
認証は2種類に分かれます。ひとつはユーザー認証です。プロトコルでは OIDC や SAML、運用では SSO や MFA、ポリシー制御ではデバイストラストや条件付きアクセスが、この領域にあたります。AI エージェントの文脈では、誰がエージェントを使えるか（利用権限）と、誰の代理として動くか（委任）の起点になります。
もうひとつはエージェント認証で、AI エージェント自身が正規の実行主体であることを確認します。前提として、エージェントには適切な管理単位でワークロード ID を割り当てます。複数のエージェントや実行環境が1つのアプリケーション ID を共有すると、操作をエージェント・所有者・タスク単位で追跡できなくなるためです。独立権限でアクセストークンを取得する場合は client credentials グラントが典型で、認可サーバーに対するクライアント認証には private_key_jwt や mTLS を利用できます。
エージェントの認可は、OAuth スコープだけでは決まりません。本シリーズでは、実効的な権限を決める観点を、次の7つの確認ポイントとして整理します。
この7つは、すべてを常に満たすことを求める固定の仕組みではなく、実効的な権限がどこで決まるかを追うためのチェックポイントです。大きくは、1〜4が権限の上限や接続の条件を設定し、5〜7がタスクや実行時の文脈に応じて許可範囲をさらに絞り込みます。どのポイントが強く効くかは、権限主体のモデル（A / B / C）によって変わります。なお、人による承認（6）や DLP（7）は、狭義の認可だけでなくその周辺統制にもまたがります。
たとえば「Slack の未読コメントを Notion へ登録する」場合、Slack に接続できる（3）だけでは十分ではありません。Slack から読み取れる範囲（4）、Notion へ書き込める範囲（3・4）、依頼内容に対する操作の妥当性（5）、人による承認の要否（6）は、それぞれ別に決まります。
なお、モデル A / B の区別は、Microsoft の delegated / application permissions の区別におおむね対応します。
この7つの確認ポイントのうちどこまでを ID 基盤側で担えるかを、第2回以降で Okta for AI Agents を中心に解説します。
ここまで整理した分類の枠組みを、主要なエンドユーザー向け AI サービスに当てはめてみます。結論から言うと、モデル A（ユーザー代理型）が多く見られます。ただし同一製品でも、個人 OAuth・企業管理認可・保存資格情報・専用ワークロード ID のどれを使うかでモデルは変わることがあります。そのため以下の表は、製品全体ではなく代表的なアクセス経路を分類したものです。
| サービス / アクセス経路 | 主なモデル | 確認上の注意 |
|---|---|---|
| Microsoft 365 Copilot | A：ユーザー代理型 | ユーザーの Microsoft 365 における権限が上限 |
| Gemini (Google Workspace) のアプリ連携 | A：ユーザー代理型 | Drive / Gmail / Calendar へのアクセスはユーザー本人の権限の範囲 |
| ChatGPT のアプリ（旧称コネクタ） | A：ユーザー代理型 | 接続先ごとに個別同意。read / write・再フィルタ・保存トークンの扱いは機能ごとに異なる |
| Claude コネクタ（個人接続、実体は MCP） | A：ユーザー代理型 | 各ユーザーが個別に認証し、本人の権限を継承 |
| Claude Enterprise-managed auth | A（接続統制は IdP へ集約） | 権限主体は A のまま、接続認可を管理者ポリシーへ寄せる方式（第2回） |
| Notion カスタムエージェント | B：エージェント独立権限型 | 外部サービスへの保存接続ではモデル C の要素が併存 |
一方、エージェントを構築・実行する AI エージェントプラットフォーム（Microsoft Copilot Studio、Microsoft Foundry Agent Service、Amazon Bedrock AgentCore、Vertex AI Agent Engine など）は、この表のように一意には分類できません。設定や接続方法などの設計次第で、権限主体そのものが変わるためです。対応するモデルと既定値は基盤ごとに異なり、保存資格情報の扱いによってはモデル C の要素が生じることもあります。導入時には、専用のエージェント ID・ユーザー委任・保存資格情報のどれを使うかを、アクセス経路ごとに確認してください。詳細は第3回で扱います。
7つの確認ポイントを最初からすべて洗い出す必要はありません。第一歩として、自社で使われている AI エージェントについて、次の3つの質問に答えられるかを確認してください。
この3つは、そのままモデルの判別にも使えます。1問目は下流アクセスの認可主体そのもの、2問目はモデル B に特有の利用権限とデータ権限の分離、3問目はモデル C で問題になりやすい保存資格情報の回収に対応しています。3つの質問に答える過程で、自社のエージェントが A / B / C のどれにあたるかも自然と見えてきます。
本記事では、AI エージェントが誰の権限で動くかをモデル A / B / C に分類し、Notion カスタムエージェントの実例と、判断の手がかりとなる4者モデル・7つの確認ポイントを整理しました。権限主体は導入形態によって変わり、最終認可や操作ログは接続先の SaaS ごとに分散します。そのため、個々の SaaS の設定や個々のユーザーの同意を追うだけでは、組織として全体像を把握できません。ここに、接続認可とライフサイクル管理を共通の管理基盤へ集約する理由があります。
権限主体と接続統制は別の軸
A / B / C は、誰の権限で動くかという権限主体の分類です。これとは別に、その接続認可を組織側でどう集中統制するかという軸があります。両者は独立した軸ですが、統制に使える手段はモデルごとに異なります。
- モデル A（ユーザー代理型の OAuth 接続）：Cross App Access (XAA) / ID-JAG / MCP EMA で接続認可を IdP へ集約する
- モデル B（独立ワークロード）：client credentials・ワークロード ID・認可サーバーのクライアントポリシーで統制する
- モデル C（保存・共有資格情報）：ボールト（vault：認証情報を保管・管理するシークレットストア）と特権管理で保護するか、OAuth／ワークロード ID ベースへ移行する
注意したいのは、現在の ID-JAG がユーザーに代わる委任アクセスを対象とした仕様である点です。純粋な app-only／ワークロード権限や静的 API キーは、同じ仕組みでは直接統制できません。ボールトと特権管理については第3回で扱います。
本記事で分類した3つのモデルは、次回以降で Okta for AI Agents がどこをカバーするのかを判断するための基準になります。第2回では、外部 SaaS への接続認可を ID 基盤へ集約する仕組み（ID-JAG・Cross App Access (XAA)・MCP Enterprise-Managed Authorization）を取り上げます。上の整理でいえば、主にモデル A の統制手段にあたる領域です。あわせて、同じ SaaS でもアクセス経路によって権限主体が変わるという論点も扱います。
| 用語 | 説明 |
|---|---|
| OBO | On-Behalf-Of。Microsoft 環境で、ユーザーの代理として下流 API にアクセスする委任フロー |
| RFC 8693 | OAuth 2.0 Token Exchange。委任・偽装を汎用的に表現できるトークン交換の標準仕様 |
| ワークロード ID | 実行主体（アプリやエージェント）そのものに割り当てる ID。資格情報の供給やフェデレーションに用いる |
| client credentials | OAuth 2.0 のグラントの1つ。ユーザーの委任を介さず、クライアント（アプリ・エージェント）自身の資格情報でアクセストークンを取得する方式。モデル B の典型 |
| confused deputy | 権限を持つ主体が、権限を持たない第三者の依頼に応じて権限を不適切に行使してしまう古典的な問題 |
| MCP | Model Context Protocol。AI エージェントが外部ツール・データソースに接続するためのプロトコル |
| IdP | Identity Provider。ユーザーやワークロードの認証を担う。本シリーズでは認可サーバー機能を兼ねる企業 ID 基盤を便宜上 IdP と表記 |
| XAA | Cross App Access。ID-JAG を核とするアプリ間接続パターンと実装エコシステムの名称。Okta が策定・実装を主導（第2回で詳述） |
| ID-JAG | Identity Assertion JWT Authorization Grant。企業 IdP が発行する署名済み JWT で、ユーザー委任にもとづく下流のアクセストークン取得を認可する許可証。仕様は IETF の OAuth 拡張ドラフト（第2回で詳述） |
| EMA | Enterprise-Managed Authorization。ID-JAG を MCP 接続へ適用する公式 MCP 認可拡張（第2回で詳述） |
| DLP | Data Loss Prevention。データの外部送出や横展開を制御する仕組み |
本記事はシリーズ AI エージェントの認証・認可を ID 基盤に集約する の第1回です。記載の各製品の仕様・挙動については2026年7月時点の情報を元にしています。公式ドキュメントの更新により変わる可能性があるため、導入検討時は一次情報での確認を推奨します。
Okta や AI エージェントのセキュリティ統制に関するご相談は、ネクストモードまでお気軽にお問い合わせください。