AIエージェントのガバナンス：アイデンティティ、委任、権限の実践

AIエージェントがシステム内でタスクを実行する際、そのアイデンティティと権限管理は重要な課題です。多くのチームは迅速なデプロイのために共有APIキーや開発者の資格情報をエージェントに使用し、深刻なガバナンスの脆弱性を生み出しています。本記事では、各エージェントに明確なアイデンティティと限定的な権限を与え、すべての操作を承認元まで追跡可能にする委任モデルを提案します。

**誤ったアプローチ**

一つ目の誤りは「ユーザーへのなりすまし」です。エージェントが人間ユーザーの全権限を継承し、権限が過剰に拡大します。例えば、サポート担当者が注文照会のためにエージェントを起動すると、エージェントは財務レポートや人事記録など無関係なデータにアクセス可能になります。プロンプトインジェクション攻撃を受ければ、攻撃者はユーザーの全API権限を取得できます。監査ログでも人間の操作とエージェントの行動を区別できません。

二つ目の誤りはサービスアカウントの使用です。エージェントに独立した身分は与えられますが、責任追及が困難です。サービスアカウントは解雇できず、インシデントレビューで尋問できません。セットアップしたエンジニアが退職した後も権限が長期にわたって見直されず、セキュリティリスクとなります。NIST SP 800-207はこれを「所有権のみに基づく暗黙の信頼」と呼び、ゼロトラストの原則に反します。

**委任モデル：正しい道**

正しいモデルは、エージェントが独自のアイデンティティを持ち、人間に代わって行動することです。両方のアイデンティティが保持され、権限はエージェントの役割と委任者の権限の共通部分（積集合）となります。式で表すと：有効権限 = エージェント役割 ∩ 委任者権限。インターンが管理者権限のエージェントを起動しても、インターンレベルの結果しか得られません。管理者が限定されたエージェントを起動しても、エージェントの範囲内の操作しかできません。どちらも相手の権限を拡大しません。

Red Hatはこれを「検証し、決して信頼しない」と呼び、NIST SP 800-207は「認証と認可はセッション確立前に個別の機能として実行される」と述べています。同じ原則をAIエージェントに適用します。

**アイデンティティがアンカー**

エージェントには永続的で安定した識別子が必要であり、人間と同じアイデンティティシステム、ディレクトリ、ライフサイクル、失効パスを使用します。独立したアイデンティティがなければ、エージェントはシステム内の「幽霊」となり、名前を付けられず、失効も調査もできません。

**上限と下限**

すべての操作で二重の境界が強制されます。上限（エージェントの役割上限、管理者が設定）と下限（委任者の権限下限）です。有効権限は常に狭い方が優先されます。例えば、請求書の読み取りと作成のみ許可されたエージェントは給与データにアクセスできません。これはLLMの整合性に頼るのではなく、プラットフォーム層が呼び出しをブロックするためです。

プロンプトインジェクションが発生しても、エージェントの操作範囲は共通部分に制限され、爆発半径は数学的に保証されます。

**エージェントは権限を知らない**

重要な設計上の選択：エージェントはトークンを保持せず、権限をチェックせず、委任ユーザーについて何も知りません。すべての認可はプラットフォーム層で行われ、エージェントのプロセス、プロンプト、攻撃者の到達範囲の外側にあります。これにより、同じエージェントコードが異なる委任者により異なる有効範囲を持ち、コード変更なしで設定のみで対応できます。

**自律トリガーと無効な委任**

cronジョブやwebhookなどの自律トリガーでは、人間が直接関与しません。ルールは変わりません：委任コンテキストなし＝拒否。各自律トリガーは人間によって設定され、システムは作成時に委任者を記録し、実行ごとに再検証します。委任は存在するか？アクティブか？委任者に権限はまだあるか？いずれかのチェックに失敗すると、エージェントは起動しません。

退職したエンジニアが設定した同期タスクは、この仕組みがないと無効な権限で実行され続けますが、この仕組みにより委任者がオフボードされると即座にトリガーが無効化され、手動クリーンアップは不要です。

**すべてのアクションに二つの名前**

各操作は、実行主体（例：invoice-agent）と承認者（例：[email protected]）、およびトリガー方法を記録します。監査はデータベーストリガーレベルで取得され、データ変更と同じトランザクション内で行われ、エージェントによるバイパスや改ざんは不可能です。

**トークン契約**

内部委任トークンはRFC 8693（トークン交換）に従います：アイデンティティのみを含み、権限はリクエストごとにデータベースから解決されます。有効期間は短く（120秒）、対象サービスが制限されています。トークンは「このエージェントがこの人間の代理である」ことのみを示し、プラットフォームがリクエストごとに組み合わせの権限を決定します。

**RootCXでの実践**

RootCX Coreにデプロイされたエージェントは、初回呼び出しから自動的にガバナンスされたアイデンティティを取得します。設定不要。決定論的アイデンティティ、人間と同じRBAC、ツール呼び出しごとの共通部分計算、自律トリガーに対する常設委任検証、エージェントプロセスの外での認可、二重アイデンティティ監査、短命トークン。ビルダーはガバナンスを意識する必要がなく、プラットフォームがOktaが人間の認証を処理するのと同様に透過的に扱います。

**8項目チェックリスト**

1. すべてのエージェントに独自のアイデンティティがあるか？
2. エージェントごとに能力上限が設定されているか？
3. 有効権限は共通部分か？
4. 「委任者なし」＝拒否か？
5. エージェントは権限を認識しないか？
6. 自律トリガーに常設委任があるか？
7. トークンは短命かつ対象サービス限定か？
8. 監査証跡に両方のアイデンティティが含まれているか？

8/8が達成されていれば統制されたエージェント、それ以外はトレンチコートを着たスクリプトとAPIキーに過ぎません。