トップ > AI > AI Agentの権限管理を考える 〜 Token ExchangeとAgent Fabricによる現実解

AI Agentの権限管理を考える 〜 Token ExchangeとAgent Fabricによる現実解

AI Agentforce Salesforce LLM

はじめに

皆さんこんにちは。エンジニアの竹田です。

最近、AI Agentの開発をしていて、もっとも重要だと感じているのが権限管理の話です。

AI Agentは賢くなればなるほど、さまざまなシステムやデータに自律的にアクセスして仕事をこなすようになります。これはとても便利なことですが、ここで一度立ち止まって考えてみたいことがあります。そのエージェントは、いったい誰の権限で動いているのでしょうか？

本記事では、AI Agentの権限管理がなぜ難しいのかを整理した上で、OAuthのToken Exchange（RFC 8693）とMuleSoft Agent Fabricを組み合わせた現実的な解決アプローチについて考察します。

エージェントが「システム権限」で動くことの怖さ

まず問題意識から共有します。

AI Agentを手っ取り早く動かそうとすると、多くの場合、システム権限——つまり管理者相当の強い権限を持ったサービスアカウントやAPIキー——をエージェントに与えることになります。開発中はこれで十分動きますし、権限エラーに悩まされることもないので、つい「これでいいか」となりがちです。

しかし、これは従来のバッチ処理やシステム連携にシステムアカウントを使うのとは、リスクの質が違います。従来のプログラムは決められた手順だけを実行するので、システム権限を与えても、実行される操作の範囲はコードによって静的に決まっていました。一方、AI Agentは目的を達成するために自律的に手段を選びます。つまり、実行される操作の範囲が事前には決まらないのです。

この性質とシステム権限が組み合わさると何が起きるか。エージェントは「アクセスできるものには何でもアクセスしてよい」と解釈して動きます。本来そのユーザーには見えないはずの他部署のデータを参照して回答に含めてしまう、良かれと思って本来承認が必要な更新処理まで実行してしまう——実際、世界中でこの種のAI Agent絡みの事故が報告され始めています。

セキュリティの世界には以前からConfused Deputy（混乱した代理人）問題という概念があります。強い権限を持った代理人（Deputy）が、権限の弱い依頼者にそそのかされて、依頼者本人にはできないはずの操作を実行してしまう問題です。システム権限で動くAI Agentは、まさにこのConfused Deputyになり得ます。しかもプロンプトインジェクションという「そそのかし」の手段が現実に存在する以上、これは大きな懸念事項になります。

与えた権限の範囲がそのまま事故の被害範囲になる。 これがAIエージェントの権限管理を考える際の出発点です。

Agentforceの場合：Salesforce内はユーザー権限が適用される

こうした観点で見ると、Agentforceは比較的よく考えられたつくりになっています。

Agentforceでは、ユーザーとの対話から起動されるエージェントは、基本的にそのユーザーのコンテキストで実行されます。Salesforce内のレコードへのアクセスには、プロファイル、権限セット、共有ルール、項目レベルセキュリティといったSalesforceの権限モデルがそのまま適用されます。つまり、営業担当のAさんがエージェントに問いかけた場合、エージェントが参照できるのはAさんに見える範囲のデータだけです。

これは地味ですが非常に重要な性質です。Salesforceに長年蓄積されてきた権限モデルという資産を、エージェントがそのまま継承できるからです。「エージェント用に権限を新しく設計したら、うっかり強すぎる権限を渡してしまった」という事故が構造的に起きにくくなっています。

しかしSalesforce外は別の話

問題は、エージェントがSalesforceの外に出るときです。

エージェントが外部のREST APIを呼んだり、MCPで外部システムに接続したりする場合、Salesforceの権限モデルは当然ながら外の世界には届きません。外部接続の認証はNamed Credential / External Credentialで構成することになりますが、ここでNamed Principal（システム共通の資格情報）を使うか、Per User Principal（ユーザーごとの資格情報）を使うかという設計判断が発生します。そして、手軽なのはNamed Principalです。接続先のシステムアカウントをひとつ用意すれば済むからです。

ここで冒頭の「システム権限で動くエージェント」が再登場します。箱の中（Salesforce内）ではユーザー権限が丁寧に適用されているのに、箱の外に一歩出た瞬間、全ユーザーが同一のシステム権限に合流してしまう。このギャップが盲点になりやすいのです。

※ちなみに残念ながらAgentforceのMCP対応においてはPer Userでの認証は未実装の様です（2026年7月時点）

根本問題：認可の仕組みがないプラットフォームが多い

さらに言えば、Agentforceはまだ恵まれている方です。世の中の多くのAI Agent開発プラットフォームには、そもそもエンドユーザーの権限をエージェントの行動に反映させる仕組み自体がありません。エージェントはワークロードとして固有の資格情報を持ち、その資格情報が届く範囲すべてにアクセスできる——これがデフォルトです。

従来のWebアプリケーションであれば、アプリケーションサーバがユーザーセッションを管理し、アプリケーションコードがユーザーごとのアクセス制御を実装していました。AI Agentの世界では、この「誰のために動いているのか」という情報が、エージェントからツール呼び出し、そして外部システムへと連鎖の途中で失われてしまうことが根本問題だと言えます。

解決には2段階の仕組みが必要

ではどう解決するか?整理すると、アクセス制御のアーキテクチャは、一般に次の2つの要素に分離されます。

  • PDP（Policy Decision Point）：「誰が・何に・どこまでアクセスしてよいか」を判定する場所
  • PEP（Policy Enforcement Point）：判定結果に基づいて、実際にアクセスを許可・拒否する場所

AI Agentの権限管理も、この構図で2段階に分けて考えられます。

第1段階は、認証認可基盤による判定です。 エージェントが外部システムにアクセスする際に、「このアクセスは誰のためのもので、どのスコープまで許されるのか」を判定し、それを証明するトークンを発行します。OAuth 2.0/2.1の認可サーバがこの役割を担います。MCPの仕様でも2025年の改訂でAuthorizationの章が整備され、OAuth 2.1をベースとした認可フローが標準として定義されました。業界としても、この第1段階はOAuthの枠組みで解くという方向性が固まりつつあります。

第2段階は、リソース側でのアクセス制御の執行です。 トークンで「Aさんの権限の範囲」と判定されても、実際にAさんが見られるレコードだけを返し、見られないレコードを拒否するのは、データや操作を保持しているシステム自身にしかできません。どのレコードがAさんに見えるのかを知っているのは、そのデータを持つシステムだけだからです。認可サーバがどれだけ賢くても、ここは肩代わりできません。

判定（PDP）と執行（PEP）は別の場所にある——この分離を意識すると、認可基盤を入れたのに安全でない、という事態を避けられます。

現実解：ユーザーの権限をそのまま使う

第2段階で「リソースを持つシステム側で実装するしかない」と書きましたが、ここで現実的な壁にぶつかります。

エージェントがMCPなどを通じて操作したい既存システムは、社内外に多数あります。それらすべてに手を入れて「エージェント専用の認可ロジック」を新たに実装していくのは、コスト的にも体制的にも現実的ではありません。改修がそもそも困難なシステムもあるでしょう。

そこで有力になるのが、ユーザーの権限をそのまま使うという方針です。エージェント専用の権限モデルを新設するのではなく、「いま操作している本人」の権限でリソースにアクセスさせる。いわゆるOn-Behalf-Of（OBO）の考え方です。

この方針の優れた点は、既存システムの認可ロジックをそのまま流用できることです。多くの業務システムは、すでにユーザーごとのアクセス制御を実装済みです。「Aさんとしてアクセスすれば、Aさんに許された範囲しか操作できない」——この既存の仕組みが、そのまま第2段階のPEPとして機能してくれます。しかも、エージェント経由の操作がユーザー本人の権限を超えないことが構造的に保証されるので、先ほどのConfused Deputy問題への対策にもなります。監査ログにも「誰の操作か」が自然に残ります。

もちろん、エージェントにユーザーを超える権限を意図的に持たせたいケース（自動実行のバックグラウンドジョブなど）もありますが、対話型のエージェントであれば、ユーザー権限の継承で事足りる場合が多く、それが最も適切な場合も多いというのが実感です。

では「ユーザーの権限をエージェントに引き継ぐ」を技術的にどう実現するか。ここで登場するのが、OAuth 2.0の拡張仕様であるToken Exchange（RFC 8693）です。

ここからはToken Exchangeと既存のユーザ権限でのアクセス制御を前提として、その実現方法を見ていきます。

第1段階の実装：Token Exchange（RFC 8693）

Token Exchangeは、その名の通り「トークンを別のトークンに交換する」ためのプロトコルです。認可サーバのトークンエンドポイントに対してリクエストを送り、手持ちのトークンを別のリソースに対して有効なトークンに交換してもらいます。

エージェントの文脈で重要なパラメータは次の3つです。

  • subject_token：「誰のためのアクセスか」を表す。ここにユーザーを表す識別子を渡します
  • actor_token：「誰が代行しているのか」を表す。ここにエージェント自身を表す識別子を渡します
  • audience：「どのシステム向けなのか」を表す。ここにエージェントがアクセスする先のシステムの識別子を渡します

これらを分けて渡せることが、エージェントにとって本質的に重要です。交換後のトークンには「主体はユーザーAさん、代行者はエージェントX」という委任（delegation）の構造を埋め込めます（発行されたトークンの act クレームに代行者が記録されます）。単にユーザーになりすます impersonation ではなく、「エージェントがユーザーのために動いている」ことをトークン自体が表現できるわけです。リソース側や監査の場面で、人間の直接操作とエージェント経由の操作を区別できることは、運用上大きな意味を持ちます。またaudienceの指定によってエージェントが代行してアクセスする先を絞ることができます。

フローの全体像はこうなります。

  1. ユーザーがエージェントにログインし、ユーザートークンが得られる
  2. エージェントが外部システムにアクセスする必要が生じる
  3. エージェントは認可サーバでToken Exchangeを行い、「ユーザーAさんの、対象外部システム向けトークン」を取得する
  4. エージェントはそのトークンで外部システムのAPIを呼ぶ
  5. 外部システムは通常どおりユーザー権限でアクセス制御を行う

これで実現できました。

...とはいえこれを個々の接続ごとに個別実装していくのは大変です。エージェント側にはトークン交換とトークンのライフサイクル管理の実装が必要になり、接続先が増えるたびに同じような実装を繰り返すことになります。標準仕様は存在するもののシステムで使い切れるかというと、まだ距離があります。

その距離を埋めるもの：MuleSoft Agent Fabric

その距離を埋める手段としてフレクトとして注目しているのが、MuleSoft Agent Fabricです。

Agent Fabricは、企業内に増殖するエージェントを統制するための基盤で、エージェントを登録・発見するAgent Registry、エージェント間の連携を仲介するAgent Broker、通信を可視化するAgent Visualizer、そしてガバナンスを担うAgent Governanceで構成されます。権限管理の文脈で効いてくるのが、このAgent Governanceです。

Agent Governanceの実体はMuleSoftのOmni Gateway（旧名称Flex Gateway）であり、その中核ではEnvoy Proxyが動いています。Envoyはオープンソースであり世界中で実績のある高性能プロキシです。Agent Fabricのアプローチは、エージェントと外部リソースの間のすべての通信を、ゲートウェイ（プロキシ）という関所に通すというものです。

この構成の何が嬉しいのかというと、認証認可のような横断的関心事を、エージェント側のアプリケーションコードから、ゲートウェイが持つポリシー（フィルター）へ移せることです。

  • Token Exchangeの処理を、ゲートウェイのポリシーとして一元的に適用できる
  • 具体的にはエージェントが操作対象システムにアクセスする際に、ゲートウェイ上でポリシーがIdPに対するToken Exchangeの要求を実行し、subject_token,audienceといった値を適切なものに設定したトークンを発行する※
  • ゆえに個々のエージェントでToken Exchangeの実装を行う必要がない
  • エージェントが増えても、接続先が増えても、ポリシーの適用箇所はゲートウェイ一箇所のまま

各エージェントにOAuthクライアントの実装を作り込む代わりに、通り道に一枚ゲートウェイを挟んでポリシーで解決する。サービスメッシュがマイクロサービスに対して行ってきたこと（認証・認可・可観測性のインフラ層への分離）を、AIエージェントに対して行うアプローチだと言えます。第1段階の実装コスト問題は、これでかなり現実的になります。

※MuleSoftによるこちらの記事によると、現時点ではactor_tokenに対応しておらず代わりにより簡易的なazpで対応しているようです

第2段階もAgent Fabricで解決できるケース

さらに、第2段階についてもAgent Fabricが効くケースがあります。

前述の通り、第2段階の原則は「リソースを持つシステム側での権限制御対応」です。ただし、もしその外部システムがREST API経由で、すでにユーザーごとの権限制御を実装済みなのであれば——つまり「Aさんのトークンで呼べばAさんに許された結果だけが返る」APIになっているのであれば、話は非常にシンプルになります。

Agent Fabricには、既存のREST APIをMCPサーバとして公開する機能があります。API仕様を取り込み、各エンドポイントをMCPのツールとしてエージェントから呼び出せるようにするものです。このMCP化の経路でも通信はOmni Gatewayを通るため、第1段階のトークン処理を適用しながら、ユーザーのコンテキストを保ったままAPIを呼び出せます。

すると何が起きるかというと、既存APIの認可ロジックが、そのままエージェント向けのPEPとして機能することになります。 第2段階のために新しい実装を書く必要がないのです。長年運用されてきたAPIの権限制御という資産を、MCP化という薄い変換層だけでエージェントの世界に持ち込める。既存システムへの改修を避けたい現場にとって、これは大きな価値だと感じています。

まとめ

ここまでの議論を整理します。

論点 内容
問題の本質 エージェントは実行される操作が事前に決まらないため、システム権限を与えると権限範囲がそのまま被害範囲になる（Confused Deputy問題）
必要な構造 判定（PDP：認可基盤）と執行（PEP：リソース側）の2段階の分離
方針 エージェント専用の権限モデルを新設せず、ユーザー権限を引き継ぐ（On-Behalf-Of）
第1段階の実装 Token Exchange（RFC 8693）。subject_token / actor_token / audienceにより「誰のために・誰が代行して・どのシステムへ」を委任構造としてトークンに埋め込む
実装コストの解決 Agent Fabric（Flex Gateway / Envoy）により、トークン処理を個別実装からゲートウェイのポリシーへ移す
第2段階の近道 ユーザー毎の権限制御済みREST APIなら、Agent FabricでMCP化するだけで既存の認可ロジックがそのままPEPとして機能する

おわりに

2026年に入ってから、ClaudeをはじめとするAIツールは本当に優秀になりました。それに伴って、エージェントと外部システムとの接続、そしてそのときの権限制御が、AI活用の成否を分けるテーマになってきています。エージェントが優秀になればなるほど、より多くのシステムにつながり、より重要なデータを扱うようになるからです。

今回はToken ExchangeとAgent Fabricを軸に紹介しましたが、この領域では他にもさまざまなツールやアプローチが登場してきています。エージェントのアイデンティティ管理は業界全体でまさに標準化が進んでいる最中で、「これが正解」というベストプラクティスが確立しているわけではありません。

まだまだ発展途上のAI Agent開発、いろいろな話題があって面白いですね。こうした技術の発展をキャッチアップしながら、エンジニアとしてやれることを地道にやっていきましょう。