「この AI エージェント、どの権限で動いているんですか」——顧客のセキュリティ担当からそう問われて、答えに詰まる。調べてみると、社内ツールに組み込んだエージェントは、担当者本人の管理者 API キーをそのまま使って動いていた。監査ログを開いても、そこに残っているのは担当者の ID だけで、いつ・どの操作が人間の手によるもので、どれがエージェントの自動実行だったのかが区別できない。なりすましの痕跡があっても切り分けられず、過剰な権限を持ったまま動き続けている。受託でエージェント機能を組み込むとき、いま静かに増えているのがこの状態です。
問題の根は、人間を前提に作られた ID やサービス向けの認証の枠組みに、エージェントを無理やり当てはめていることにあります。エージェントは人間のように画面の前で都度ログインするわけでもなく、従来のバッチ処理のように固定の役割で黙々と動くわけでもない。利用者の代わりに判断し、別のツールやエージェントを呼び、その先でさらに権限を行使する。この「誰かの代理として、連鎖的に動く」性質が、既存のアクセス制御と噛み合わない。InfoQ が 2026 年 6 月に報じた AI Agent Identity and Permission Challenges（InfoQ） は、まさにこの「エージェントは人間用にもサービス用にも作られていない ID モデルに収まらない」という認識から始まり、Uber と Auth0 がそれぞれどう作り直しているかを整理しています。本記事では、その方向性を手がかりに、受託でエージェントを実装・保守する立場から認証・認可の設計を実務に落とします。
なぜ「担当者と同じキー」が負債になるのか
エージェントに担当者の API キーや管理者権限をそのまま渡す。最初は手軽で、すぐ動きます。問題は、運用が育つほど次の三つが効いてくることです。
第一に、過剰権限。人間の担当者は「念のため」広い権限を持っていることが多く、それをエージェントが丸ごと継承します。本来そのタスクに必要なのは「特定の DB テーブルを読む」だけなのに、書き込みも削除も、別システムへの管理操作までできてしまう。エージェントがプロンプトインジェクションで誘導されたり、想定外の入力で暴走したりしたとき、被害範囲がその広い権限の分だけ広がります。Auth0 はこれを「過剰なエージェンシー（excessive agency）」と呼び、最小権限（PoLP）を出発点に締めるべきだと整理しています（Mitigate Excessive Agency in AI Agents（Auth0））。
第二に、監査できない。担当者の ID で動いている以上、ログに残るのは担当者の名前だけです。後から事故やデータ漏えいを調べても、「人が操作したのか、エージェントが自動でやったのか」「どの利用者の依頼を起点に動いたのか」が構造化されて残っていない。受託では、この「経路を追えない」状態がそのまま説明責任の欠如になります。
第三に、なりすましと再利用のリスク。長命の API キーや共有トークンは、一度漏れれば誰でも・いつまでも使えてしまう。エージェント間で同じトークンを使い回していると、ある経路で盗まれたトークンが別の経路で通ってしまい、どこから侵入されたのかを切り分けられません。
整理すると、エージェントを既存の枠組みに当てはめたときの破綻はこうなります。
| 当てはめ方 | 何が起きるか |
|---|---|
| 人間ユーザーとして扱う（担当者のキーを流用） | 過剰権限を継承し、ログ上で人とエージェントを区別できない |
| サービスアカウントとして扱う（共有の固定キー） | 「誰の代理か」が消え、長命キーの漏えい・使い回しに弱い |
| 非人間アイデンティティ（NHI）として扱う | 委任元・実行主体・スコープを保ったまま統制できる |
三つ目の「非人間アイデンティティ（NHI: Non-Human Identity）として扱う」が、Uber も Auth0 も向かっている方向です。エージェントに人間のお下がりでも共有キーでもなく、固有のアイデンティティと、そのタスクに絞った権限を与える。これが設計の前提になります。
エージェントに「固有のアイデンティティ」と「最小スコープ」を与える
まずやるべきは、ツールの導入ではなく、エージェントを独立した主体として登録することです。エージェントごと（あるいはエージェントの役割ごと）に固有の ID を発行し、それに紐づく権限を、人間の権限とは別系統で管理します。
そのうえで、権限はタスク単位に絞ります。「このエージェントは何でもできる」ではなく、「このエージェントは、この利用者の依頼に対して、このリソースをこの操作だけできる」という粒度です。OAuth で言えば、広いスコープを一括で渡すのではなく、タスクに対応した細かいスコープを必要なときだけ発行する。Auth0 はこれを「ブロードな API アクセスではなく、タスクベースの認可でツールをスコープする」と表現し、利用者から継承したトークンではなくエージェント自身のスコープ付きクレデンシャルを持たせることを勧めています（Access Control in the Era of AI Agents（Auth0））。
スコープの設計を、ざっくり擬似コードで表すとこうなります。広いロールを一発で渡すのではなく、エージェントの役割ごとに「読めるもの・書けるもの・呼べる外部 API」を明示的に列挙する考え方です。
# エージェントの役割定義（最小権限の例）
agent:
id: agent-invoice-summarizer # 人間とは別系統の固有ID
scopes:
- invoices:read # 請求データの読み取りのみ
- reports:write # レポート出力先への書き込みのみ
forbidden:
- invoices:delete # 削除は決して許可しない
- admin:* # 管理操作は範囲外
human_in_the_loop:
- payments:execute # 支払い実行は人間の承認が必須ここで重要なのは、forbidden と human_in_the_loop を明示することです。「許可リストに無いものは全部禁止」を原則にしつつ、支払い・削除・外部送信のような取り返しのつかない操作は、たとえスコープ上は技術的に可能でも、人間の承認を挟む。Auth0 はこの人間承認を、CIBA（Client-Initiated Backchannel Authentication）という仕組みで実装し、承認されたときだけその操作に絞ったトークンを発行する——拒否されればトークンは存在せず、ツールは実行されない、という設計を示しています。エージェントに「考える自由」は与えても、「実行する権限」は段階的に絞る、という分け方です。
この「常設の広い権限を持たせない」発想は、エージェント固有の話ではありません。本番サーバーへの常時 SSH をやめて監査できるジョブ実行に寄せる考え方と地続きで、常設SSHを廃しジョブ実行を委ねる記事で扱った「属人的な常設アクセスを撤廃する」という統制の延長線上にあります。
「誰の代理で動いているか」を委任で表現する
エージェントの難しさは、それがたいてい誰かの代理で動くことにあります。利用者 A の依頼を受けたエージェントが、別のツールやサブエージェントを呼び、その先でさらに別の操作をする。このとき、最終的にリソースへアクセスする時点で「これは A の依頼を起点に、エージェント B が実行している」という文脈が失われると、認可判断もログも崩れます。
これを表現する仕組みが、委任（オンビハーフオブ）です。標準としては OAuth 2.0 Token Exchange（RFC 8693）が、まさにこの委任を扱います。トークンの中に、本来の主体（subject、＝利用者 A）と、その代理で動く実行主体（actor、＝エージェント B）を区別して入れられる。act クレームが「誰が誰の代理で動いているか」を、may_act クレームが「この主体は誰の代理を務めてよいか」を表します。
# RFC 8693 のトークン交換のイメージ（委任の表現）
{
"sub": "user-a", # 本来の主体（依頼した利用者）
"act": { # 代理で動いている実行主体
"sub": "agent-invoice-summarizer"
},
"scope": "invoices:read reports:write",
"aud": "billing-api", # このトークンが通る相手を限定
"exp": 1750300000 # 短い有効期限（数分〜十数分）
}Uber が公開したアーキテクチャは、この発想を多段のエージェント連携にまで広げています。同社のブログ Solving the Identity Crisis for AI Agents（Uber） と前掲 InfoQ の報道によれば、Uber は Security Token Service（STS）をトラストブローカーとして、エージェントのワークフローの一ホップごとに短命の JWT を発行します。各トークンは行き先にスコープが絞られ有効期限が短いためリプレイに強く、肝心なのは、直前の呼び出し元だけでなく起点の人間から中間のエージェントまでの「参加者の連鎖（attested actor chain）」が埋め込まれている点です。これにより最下流のリソースを守るゲートウェイは、「起点の人間は誰か」と「いま操作しているエージェントは誰か」の両方を見て認可を判断できます。Uber ではこの検証・認可を MCP（Model Context Protocol）ゲートウェイが担い、報道時点で週あたり約 6 万件のタスク実行をさばいているとされます。中小の受託にそのまま持ち込む規模ではありませんが、「代理の連鎖を追える形でトークンに刻む」という原則は規模を問わず効きます。
なお、エージェント特化の委任については IETF でも標準化の議論が進んでおり、「AI エージェントが利用者の代理でトークンを取得する」ための OAuth 拡張ドラフトが提出されています。ただし 2026 年 6 月時点ではまだドラフト段階で確定した標準ではないため、設計上は確立済みの RFC 8693 と OAuth 2.1 を土台にし、ドラフトは動向としてウォッチする、という位置づけが妥当です。エージェントが外部 API を叩く際の認証の土台としては、MCPサーバーのOAuth 2.1認証の記事で扱った認可サーバーの考え方が、そのまま委任設計の前提になります。
短命トークンと「エージェント専用クレデンシャル」を運用に乗せる
委任を表現できても、トークンの寿命と保管がずさんなら統制は崩れます。設計の柱は二つ。トークンを短命にすることと、生のクレデンシャルをエージェント本体に持たせないことです。
短命トークンは、漏れても被害の窓を狭めます。長命の API キーは一度漏れれば無期限で使えますが、有効期限が数分のトークンなら、漏れても使える時間が限られ、なりすましの再利用も難しくなる。Uber が一ホップごとに短命 JWT を発行しているのも、この理由です。受託では、ここを「秒数のチューニング」だけの話にせず、期限切れ時の自動再発行（リフレッシュ）と失効（リボーク）の経路まで含めて設計します。エージェントが暴走したと判明したとき、即座にそのエージェントの ID を失効させて全トークンを無効化できる「止める手段」が無いと、最小権限も短命トークンも片手落ちになります。
生のクレデンシャルを持たせない、という点では、Auth0 の Token Vault のような「トークンの保管・交換を担う層」をエージェントの外に置く考え方が参考になります（Auth0 Token Vault（Auth0））。エージェントが外部サービス（業務 SaaS など）を利用者の代理で叩くとき、エージェント自身は外部サービスのリフレッシュトークンを保持しません。実行時にこの層へ「この利用者のこの操作に必要なトークンをくれ」と要求し、利用者に紐づいた・他に使い回せないアクセストークンを受け取る。これにより、LLM の文脈やクライアント側のコードに生のクレデンシャルが露出する事故を防げます。
監査ログは、これらを束ねて初めて意味を持ちます。最低限、次の三つを構造化して残します。
{
"timestamp": "2026-06-19T10:23:11Z",
"principal": "user-a", // 起点の利用者
"actor": "agent-invoice-summarizer", // 実行したエージェント
"actor_chain": ["agent-orchestrator", "agent-invoice-summarizer"],
"action": "invoices:read",
"resource": "billing-api/invoices/2026-06",
"decision": "allow", // 認可の結果
"token_id": "jti-7f3a...", // 失効・追跡用のトークン識別子
"human_approval": null // 人間承認が要る操作なら承認者を記録
}ポイントは、principal（誰の依頼か）と actor（誰が実行したか）を別フィールドで残すことです。冒頭の「人かエージェントか区別できない」という症状は、まさにこの二つを一緒くたにしていたから起きます。両者を分けて記録できていれば、顧客のセキュリティ担当に「いつ・誰の依頼で・どのエージェントが・何をしたか」を、後からそのまま提示できます。
受託で組み込むときの落とし穴
弊社が支援したある社内業務システムの受託案件（卸売業向け、社名は伏せます）では、受領した既存のエージェント機能が、運用担当者の管理者トークンをそのまま使う作りになっていました。デモでは問題なく動いていたものの、セキュリティ診断で「エージェントの操作と人間の操作がログ上で同一に見え、過剰権限である」と指摘され、本番展開が止まっていました。
私たちは作り直しではなく段階的な移行を選び、まずエージェントに固有 ID を割り当てて管理者権限の継承を切り、タスクに必要なスコープだけを発行する形に変えました。次に、外部 SaaS への呼び出しを担当者キーの直接利用から、利用者に紐づくトークンを実行時に受け取る方式に寄せ、生のクレデンシャルをエージェント本体から外しました。最後に、支払い・データ削除の二操作にだけ人間承認を挟み、ログに principal と actor を分けて記録するようにした。派手な基盤入れ替えはしていません。やったのは、人間前提だった統制を「主体が機械になった分だけ」厳密にやり直しただけです。結果、診断の指摘は解消し、本番展開が再開できました。
この案件で一番効いた学びは、認証・認可をエージェントの「実装が終わってから」足そうとすると高くつくということです。プロンプトやツール連携を先に作り込み、後から権限を絞ろうとすると、エージェントが暗黙に頼っていた広い権限を一つずつ剥がす作業になり、動作確認のたびに何が壊れるか分からない。最初から「このエージェントは誰の代理で、何を、どこまでできるのか」を権限定義として書き、そこに実装を合わせるほうが、結果的に速い。
もう一つの落とし穴は、エージェント単体だけ見て満足してしまうことです。実際の運用では、どの部署が・どんな目的で・どのエージェントを動かしているのかという全体像が見えていないと、いくら個々のエージェントを締めても抜け道が残ります。組織として「何が動いているか」を把握する統制は、クラウドAIガバナンスとシャドーAIの記事で扱った「禁止ではなく可視化から入る」という考え方と地続きで、本記事の認証・認可はその一段下のレイヤーにあたります。
どこから着手するか
エージェントを業務に組み込むこと自体は、もう避けられない流れです。問題は、それを人間用・サービス用に作られた ID の枠組みに当てはめたまま運用していることにある。守るべき原則はシンプルで、エージェントには固有のアイデンティティを与え、誰の代理かを委任として表現し、権限はタスクに絞り、トークンは短命にし、人かエージェントかを分けて記録する。Uber や Auth0 のような大規模事例も、規模こそ違え、向かっている先はこの原則です。
最初の一歩としては、いま社内や委託先で動いているエージェントが「どの ID で・どの権限で動いているか」を一度たどってみることをお勧めします。担当者のキーを流用している経路が一つでも見つかれば、そこが着手すべき場所です。そのうえで、固有 ID の発行とスコープの最小化のどちらから手を付けるかを、操作の取り返しのつかなさで優先順位を付ければ、進め方の輪郭が見えてきます。
エージェントの認証・認可を既存の受託システムにどう織り込むか、あるいは受領した既存実装の権限設計をどう立て直すかでお悩みでしたら、グリームハブのお問い合わせからご相談ください。現行のエージェント構成と権限の流れを拝見したうえで、委任・スコープ・監査の設計をご一緒に組み直します。
Sources
- AI Agent Identity and Permission Challenges: How Uber and Auth0 Are Rethinking Access Control － InfoQ
- Solving the Identity Crisis for AI Agents － Uber Blog
- Access Control in the Era of AI Agents － Auth0 Blog
- Mitigate Excessive Agency in AI Agents with Zero Trust Security － Auth0 Blog
- Auth0 Token Vault: Secure Token Exchange for AI Agents － Auth0 Blog
- RFC 8693: OAuth 2.0 Token Exchange － RFC Editor
