本記事は「AI Agents Are Not Users - Building an Identity Model That Reflects That」を翻訳した記事です。
2026年4月、レンタカー会社が使用するB2BプラットフォームPocketOSにおいて、AIコーディングエージェントが本番データベース全体を削除しました。ボリュームレベルのバックアップも含めてわずか9秒で削除しました。エージェントは最先端モデルで実行されるCursorでした。創設者が後に「ベンダーが開発者に指示する内容そのもの」と説明した明確な安全ルールで構成されていました。日常的なステージングタスクを処理していた際に認証情報の不一致に遭遇し、十分な権限を持つトークンを見つけ、すべてを消去する単一のGraphQLミューテーションを発行しました。
システムプロンプトは承認なしに破壊的な行動をしないよう指示していましたが、システムプロンプトはあくまで助言であり強制力はありません。事後分析で明らかになったように、より深刻なアーキテクチャ上の失敗は、非決定的なエージェントに人間のオペレーターと同じアクセス権を与え、自然言語の指示を信頼してアクセス権を利用した行動を制限したことです。
エージェントは人間のユーザーのようには振る舞いませんでした。継続的に実行され、明確な指示を無視しました。また、固定されたコードパスや監査人が読み取れるワークフローを持たないため、バックエンドサービスのようにも振る舞いませんでした。基盤となるアイデンティティレイヤーは、アイデンティティインフラストラクチャが提供する2つの形態のいずれかを選択する必要がありました。誤った選択をしましたが、正しい形態が実際には存在しなかったため、正しく選択する方法はありませんでした。
本記事では、AIエージェントを人間のユーザーや従来のマシンアイデンティティとは異なる、独自のファーストクラスのアイデンティティとして扱う必要があると主張します。従来のモデルが破綻する理由、ファーストクラスのエージェントアイデンティティの構成要素、ライフサイクル管理を変更する方法、プロビジョニング時にロールに組み込むのではなく実行時にリクエストに対して認可を評価する必要がある理由、そしてどのような可観測性の要件が生じるかについて説明します。目的は新しいアイデンティティプリミティブをゼロから構築することではなく、既存のインフラストラクチャを拡張して想定外のアクタークラスを処理することです。
従来のモデルが破綻する理由
OAuthの委譲はエージェントにユーザーと同じ権限を与えます。ユーザーが自身で保持するスコープでCRMへのアクセス権をエージェントに付与すると、特定の瞬間に何を求められているかに関係なく、将来のすべてのやり取りにおいてエージェントはユーザーと同じ操作を実行できます。意図しているのは選択的な委譲ですが、OAuthは指定の粒度で表現できません。「現在作業中のアカウントの連絡先詳細はエージェントに表示させるが、法的な保留キューにあるものは表示させない」と指定するには、ほとんどの製品が公開していない複雑なスコープエンジニアリングが必要です。
サービスアカウントには逆の問題があります。エージェントは独自の認証情報を取得しますが、認証情報は通常静的で広範なスコープを持ち、ユーザーコンテキストから切り離されています。問題が発生した場合、監査ログにはサービスアカウントが実行したと表示されますが、情報はほとんどありません。委譲のチェーンを遡る方法も、どのアクションをトリガーしたユーザーリクエストを確認する方法も、サービスアカウント全体を取り消すことなく単一のエージェント実行を取り消す方法もありません。
両方のモデルにはエージェントの使用規模が拡大するにつれて悪化する4つの障害モードが共通しています。
- 過剰な権限付与: スコープは通常、機能レベル(
billing.refund.issue_under_50_usd)ではなくリソースレベル(billing:write)で定義されるため、認証情報は目の前のタスクにエージェントが必要とする以上の広範な権限を持ちます。 - 影響範囲: エージェントプロセス、メモリ、またはログが侵害されると、本番システムへの常時アクセスを許可する認証情報が公開されます。
- 行動コンテキストの欠如: どちらの操作も両方のアクションを認可する同じ広範なスコープの認証情報を提示するため、アイデンティティレイヤーは「エージェントがチケットを要約している」状態と「エージェントが返金を発行している」状態を区別できません。
- 認証情報のスプロール化: エージェントが新しいツールと統合するたびに、プロビジョニング、保存、ローテーション、および監査するための別の認証情報が必要になります。
4つの障害モードはすべてAIエージェント以前から存在しており、従来の自動化に関連するインシデントで見られました。しかしエージェントは主に2つの理由で状況を悪化させます。
- 認証情報の権限と特定の瞬間にエージェントが実行している作業との間のギャップは、従来の自動化よりもはるかに広くなります。
- エージェントの動作は、両方のモデルに組み込まれた前提と矛盾する形で非決定的です。
サービスアカウントが安全な理由の一部は、サービスアカウントを呼び出すコードが固定されているためです。エージェントの「コード」は、信頼できない可能性のある自然言語入力を解釈するLLMによって操作されるツール呼び出しループです。自動化コードの決定性に依存できなくなると、認証情報のスコープ設定がエージェントの実行できる操作に対する数少ない残りの制約の1つになります。
ファーストクラスのエージェントアイデンティティの姿
ファーストクラスのエージェントアイデンティティは、異なるラベルを持つサービスアカウント以上のものです。独自のライフサイクル、権限、ポリシーバインディング、および監査証跡を持っています。ユーザーと従来のマシンアイデンティティの両方から構造的に区別されるアイデンティティプリミティブです。
Auth0のきめ細かな認可製品を支えるCNCF認可エンジンであるOpenFGAは、エージェントの認可パターンで概念を形式化しています。エージェントはユーザーと同じ権限階層に参加するファーストクラスのプリンシパルとしてモデル化され、認可モデル内に独自のタイプとリソースへの独自の関係を持ちますが、権限はユーザーロールからそのまま継承されるのではなく機能にスコープされタスクにバインドされます。
具体的には、ファーストクラスのエージェントアイデンティティには4つのプロパティがあります。
- ディレクトリ識別子: ユーザーやサービスアカウントとは異なり、エージェントタイプ、エージェント定義バージョン、および理想的には動作の責任者を記述するメタデータを持ちます。
- スコープされた権限: エージェントがユーザーの代理として機能している場合でも、ユーザーの権限とは別にビジネス用語で定義されます。
- 委譲コンテキスト: エージェントが誰かの代理として機能する場合に、アクターとしてのエージェントとサブジェクトとしてのユーザーの両方を記録します。ダウンストリームシステムには「サービスアカウントがアクションを実行した」だけでなく「委譲された権限Zを使用してユーザーYの代理として機能するエージェントX」と表示されます。
- 専用の監査証跡: 基盤となるツールが生成するログとは別に、委譲チェーンをそのままにしてすべてのアクションを特定のエージェントアイデンティティに帰属させます。
バックエンドサービスには監査人が読み取れる静的なワークフローとコードパスがあるため、広範なスコープの認証情報はコードの処理によって制約されます。エージェントには制約がありません。ワークフローはLLMによって実行時に決定され、コードパスは信頼できない入力を受け取るツール呼び出しループです。認証情報はコードが実行しない役割を果たす必要があり、プロビジョニング時ではなくリクエストレベルで役割を果たす必要があります。OAuth 2.0Token Exchange(RFC 8693)は動的でリクエストスコープの委譲をサポートするように設計されており、Auth0のToken Vaultが構築される基盤です。
短命なアクターのライフサイクル管理
ユーザーアカウントは数年間存続し、サービスアカウントはサービスの存続期間中存続します。エージェントアイデンティティは中間に位置し、多くの場合スペクトルの下位にあります。サポートチケットを処理する長時間実行されるエージェントは、デプロイの存続期間中存続する場合があります。単一のユーザーのクエリに応答するために1回実行されるタスクスコープのエージェントは、タスクの期間中のみ存在する場合があります。
プロビジョニングが対話型になることはめったにありません。同意はユーザーがエージェントを使用するアプリケーションを認可したときに発生し、エージェントアイデンティティはアプリケーションによってオンデマンドで作成されます。プロビジョニングはプログラム的でべき等であり、人間の承認ワークフローではなくエージェント定義に結び付けられる必要があります。
実行コンテキストの認証情報は、エージェントのアイデンティティを確立する認証情報と同じであってはなりません。アイデンティティはエージェントが誰であり原則として何を実行できるかを確立しますが、実行コンテキストの認証情報はエージェントの目の前にある操作にスコープされ、特定の呼び出しを認可する短命のトークンです。Auth0のToken VaultがOAuthレイヤーで実装するパターンは次のとおりです。エージェントは接続されたサービスの有効期間の長いリフレッシュトークンを保持せず、代わりにOAuth 2.0 Token Exchangeを通じてジャストインタイムのアクセストークンをリクエストします。エージェントが侵害された場合、公開される認証情報は現在保持している短命のトークンのみです。
以下の図はフローが実際にどのように機能するかを示しています。2つのフェーズがあります。アプリケーションが最初に認可されると、ユーザーが同意を与え、アイデンティティプロバイダーは有効期間の長いリフレッシュトークンをToken Vaultに保存し、そこに留まります。次に、エージェントが実行する必要がある各操作について、特定の操作にスコープされた短命のアクセストークンをリクエストします。アイデンティティプロバイダーはポリシーに照らしてリクエストを評価し、数日ではなく数分間有効なトークンを返し、エージェントは単一のツール呼び出しに使用してから破棄します。エージェントが侵害された場合、攻撃者はメモリ内にある短命のトークンのみを継承し、アイデンティティプロバイダーで接続を取り消すと将来のすべてのトークン交換が直ちに無効になります。
一時停止と廃止も簡単、迅速、かつ正確である必要があります。PocketOSのインシデントを振り返ります。エージェントが暴走したとき、「何が起こったのかを把握するまでの10分間、エージェントのデータベース書き込み機能を無効にする」というような対応はできませんでした。使用していた認証情報は常時権限を与えており、常時権限は認証情報全体のレベルでしか取り消せません。単一のアイデンティティプロバイダーを通じてトークン発行を集中管理することで、よりきめ細かな取り消しが可能になります。接続を取り消すとシステムの残りの部分は稼働したまま、将来のトークン交換が直ちに無効になるためです。
ポリシー主導の認可
静的なロール割り当ては、ユーザーおよびサービスアイデンティティの従来のモデルです。アクターはロールを持ち、ロールは権限を付与し、権限はアクションに対してチェックされます。動作が予測可能な場合は問題なく機能しますが、エージェントには不十分です。エージェントは原則として幅広い機能セットにアクセスできる場合がありますが、特定のタスクではタスク自体によって決定される狭いサブセットのみを行使する必要があります。
より優れたモデルは、認可をアイデンティティではなく動作にバインドし、特定のリクエストに対して実行時に評価することです。本記事には2つの関連するパターンがあります。属性ベースのアクセス制御(ABAC)は、エージェントが代理を務めるユーザー、リソース、時間、アクション、およびタスクパラメーターなどのコンテキスト属性を考慮します。関係ベースのアクセス制御(ReBAC)はさらに進んで、エンティティ間の関係の観点から認可を表現します。関係はスコープエンジニアリングを通じてエンコードされるものではなく、モデル内のファーストクラスの概念であるため、「エージェントはアクティブな割り当てられたチケットを持つアカウントの連絡先詳細を読み取れる」といったルールを自然に記述できます。
ほとんどのチームにとってABACだけで十分です。認可ルールを「特定の属性は別の属性と等しい」と表現できる場合、完全なリレーショナルグラフは必要ないかもしれません。ReBACはマルチテナントシステム全体で何千ものリソースと関係のペアを管理する場合に役立ちます。他のモデルでルールを表現するコストが法外になるためです。シングルテナント製品と少数のリソースタイプを持つ小規模なチームの場合、リクエストに対して属性を評価するポリシーエンジンで要件の大部分をカバーできます。ReBACは必要ないかもしれませんが、エージェントをデプロイする場合はどのような形であれ、ポリシー主導で実行時に評価される認可が必要です。
OpenFGA上に構築されたAuth0のきめ細かな認可は、ReBACバージョンを実行するための開発者にとってよりアクセスしやすい方法の1つです。認可モデルはタイプと関係を定義し、条件チェックは特定のリクエストに対して特定の関係が成立するかどうかを問い合わせます。以下はユーザー、エージェント、アカウント間のいくつかの関係と条件を含むOpenFGA認可モデル定義の例です。
model schema 1.1 type user type agent type account relations define owner: [user] define assigned_agent: [agent with active_assignment] define can_read: assigned_agent or owner condition active_assignment(current_time: timestamp, expires_at: timestamp) { current_time < expires_at }
エージェントアイデンティティはファーストクラスのタイプとして関係グラフに参加します。条件式には実行時コンテキストが組み込まれます。例では自動的に期限切れになる時間制限付きの割り当てです。チェックはエージェントがプロビジョニングされたときではなく、エージェントがアクションを試行した瞬間に発生します。割り当ての期限が切れている場合、チェックは失敗し、エージェントはアクションを実行できません。
静的な権限はリアルタイムで自律的な決定を下すエージェントに追いつけません。過剰な権限付与の問題を修正するためにロールの変更が展開されるまでに、エージェントは古い権限で何千回もアクションを実行しています。ポリシー主導の認可は決定をアクションの瞬間に移動させます。コンテキストが既知であり、認可レイヤーは予想される動作の一般化に対してではなく特定のリクエストを評価できます。監査証跡が意味を持つ理由も同様です。すべてのチェックは事前に構成されたロールメンバーシップの副作用ではなく、特定のリクエストに結び付けられた個別の決定です。
可観測性と否認防止
ユーザープロキシまたはサービスアカウントモデルは、説明責任のチェーンを崩壊させます。ログには「ユーザー」または「サービス」が何かを実行したと表示されますが、どのエージェントが関与したか、またはどのタスクを実行していたかの記録はありません。ファーストクラスのエージェントアイデンティティを使用するとチェーンが保持され、3つの可観測性要件が明らかになります。
- 委譲チェーンの明示化: 各API呼び出しは、各ホップが記録された状態で、
user → agent → sub-agent → tool → resourceを通じて遡って追跡可能である必要があります。OAuth 2.0 Token Exchangeは概念をサポートしており、アクターとサブジェクトのクレームがトークン自体で委譲関係を表現します。 - アクションだけでなく決定のログ記録: 最終的な決定を知るだけでは不十分です。エージェントがどの計画を実行していたか、どのツール呼び出しが時点につながったか、どの入力が決定を形成したか、およびどのポリシー評価が各ステップを承認または拒否したかを知る必要があります。従来の監査ログよりも分散トレーシングに近いアプローチです。
- 元のユーザーの意図への否認防止の拡張: ユーザーがアクションを認可する場合、認可は一般的なスコープではなく承認された特定のアクションにバインドされる必要があります。Rich Authorization Requests(RAR)は、認可リクエストに承認される内容に関する構造化された詳細を含めることで概念をサポートします。非同期ユーザー承認のためのClient-Initiated Backchannel Authentication(CIBA)と組み合わせることで、監査ログはユーザーが正確に何を承認し、エージェントがどのように実行したかを示せます。
Auth0のToken Vaultのような集中型トークン発行は、すべての認証情報を単一のコントロールプレーン経由でルーティングすることで3つの要件すべてをサポートします。すべてのトークンはエージェントアイデンティティ、発行対象のユーザー、スコープ、および時間とともにログに記録されます。すべての取り消しは直ちに伝播します。アイデンティティプロバイダーがすでに記録しているため、監査インフラストラクチャは複数のツールに分散したログから保管チェーンを再構築する必要はありません。
エージェントアイデンティティの構築
AIエージェントをファーストクラスのアイデンティティとして扱うことは、もはや理論上の演習ではありません。ユーザープロキシ委譲と静的サービスアカウントの従来のモデルは、実行時に自然言語を解釈する非決定的なアクター向けに設計されておらず、エージェントがビジネスに依存する作業をより多く引き受けるにつれて、残されたギャップは急速に悪化します。適切な対応は、エージェントの動作に合わせて設計されたプリミティブで既存のアイデンティティインフラストラクチャを拡張することです。独自のライフサイクルを持つ個別のアイデンティティ、ロールではなく動作にバインドされたポリシー、およびユーザーの意図から自律的なアクションまでの委譲チェーンを保持する監査証跡です。
構成要素のほとんどは存在します。OAuth 2.0 Token Exchangeは委譲セマンティクスを提供します。CIBAとRich Authorization Requestsは標準ベースの承認フローを提供します。OpenFGAや同様のエンジンはポリシーインフラストラクチャを提供します。Auth0のToken Vaultやきめ細かな認可などの製品は、構成要素を開発者がアクセスしやすいプラットフォームに組み立てます。OpenFGAのエージェントの認可ガイダンスに文書化されているパターンは、実際に適用する方法を示しています。
組織はアイデンティティモデルが最も馴染みのある認証情報パターンで取り繕う実装の詳細ではないことを認識する必要があります。PocketOSのインシデントは異常な事故ではありませんでした。想定されていないアクタークラスにアイデンティティモデルを適用したことによる予測可能な結果でした。本番環境のAIエージェントは、ユーザーアカウントやサービスアイデンティティのプロビジョニングと同じ注意を払う価値があり、どちらでもないことを認識する必要があります。
About the author
Cameron Pavey
Senior Developer