9月21日、InfoQが「Securing AI Agents: Identity, Authorization, and the DPACT Framework」と題したポッドキャストを公開した。AIエージェントのアイデンティティ・認可・セキュリティにおける課題と、それに対処するための「DPACTフレームワーク」について詳しく論じられている。特に注目すべきは、プロンプトインジェクション攻撃や不正な権限委譲といった、AIエージェント固有の攻撃経路への対処だ。従来のAPI認証モデルでは、これらのリスクに十分に対応できないという主張は、AIエージェントを実務に投入しようとしているエンジニアにとって見逃せない論点となっている。
AIエージェントが「人間の代わりに動く」時代のセキュリティ課題
LLMベースのAIエージェントが実際のシステムにアクセスし、タスクを自律的に実行するようになった今、従来のAPI認証モデルが前提としていた「人間がアクセスしている」という前提が崩れつつある。エージェントはDBを参照し、外部サービスを呼び出し、別のエージェントに処理を委譲する。この連鎖の中で「誰が、何の権限で、何をしているか」を追跡することが極めて困難になっている。
本ポッドキャストでInfoQに登場したのは、AIセキュリティを専門とするSahil Agarwal氏だ。同氏は、単純なトークンベースのアクセス管理から脱却し、「制限付き委任権限（bounded delegated authority）」を中心に据えた設計思想への転換を主張する。
なお、AIエージェントのセキュリティリスクは業界全体でも注目されており、OWASP LLM Top 10ではLLMアプリケーションにおける上位の脅威としてプロンプトインジェクションや過剰な権限付与が明示されている。DPACTフレームワークはこうした業界的な問題意識と軌を一にするものだ。
最大のリスク：プロンプトインジェクション攻撃と長命トークンの組み合わせ
現状の多くのAIエージェント実装では、エージェントにAPIキーや長命トークンを渡して「あとはよろしく」という形になりがちだ。しかしこのアプローチは、攻撃者にとって格好の標的となる。
プロンプトインジェクション攻撃とは、悪意ある入力をエージェントへの指示に紛れ込ませ、エージェントに意図しない操作を実行させる攻撃手法だ。エージェントが長命トークンや広範な権限を保持している状況でこの攻撃を受けると、そのトークンが持つ権限が丸ごと悪用されるリスクがある。たとえば外部Webページの内容を要約するよう指示されたエージェントが、そのページに仕込まれた悪意ある命令を読み取り、ユーザーのデータを外部に送信してしまう、といったシナリオが現実に想定される。
Agarwal氏は、このリスクに対抗するためにDPACTフレームワークを提唱している。
DPACTフレームワークとは何か
DPACTフレームワークは、AIエージェントシステムにおける認可・セキュリティ設計の指針となる5つの原則の頭文字をとったものだ。
| 頭文字 | 原則 | 意味 |
|---|---|---|
| D | Delegation（委任） | エージェントは人間やシステムから明示的に権限を委任された範囲でのみ動作する |
| P | Policy（ポリシー） | アクセス制御はコードではなくポリシーとして定義・管理する |
| A | Auditability（監査可能性） | エージェントのすべての行動は後から検証可能な形で記録される |
| C | Context（コンテキスト） | 権限はリクエストの文脈（誰が、何のために、どこから）に応じて評価される |
| T | Time（時間） | 権限には有効期限を設け、必要な期間のみ付与する |
この5原則のうち、特に設計上の転換点となるのが「Delegation（委任）」と「Time（時間）」の組み合わせだ。DPACTの考え方では、エージェントが持つ権限はタスク単位・時間単位で明示的に制限されなければならない。たとえば「このユーザーのカレンダーを今後30分間だけ読み取れる」という粒度での権限付与が理想とされる。長命なクレデンシャルを短命なスコープ付きトークンに置き換えるこのアプローチは、プロンプトインジェクション攻撃を受けた際の被害範囲を大幅に限定できる。
「誰がエージェントか」を識別する難しさ
Agarwal氏がもう一つ強調するのが、AIエージェントのアイデンティティ問題だ。
人間のユーザーであれば、OAuth・MFA（多要素認証）・セッション管理といった成熟した仕組みがある。OAuthはサービス間の権限委譲を標準化したプロトコルであり、MFAは認証時に複数の確認要素を要求することで不正アクセスを防ぐ仕組みだ。しかしAIエージェントは「人間でもなく、従来のサービスアカウントでもない」という中間的な存在であり、これらの仕組みをそのまま適用しにくい。マルチエージェント構成では、あるエージェントが別のエージェントを呼び出す際、その呼び出し元の正当性をどう検証するかという問題がさらに複雑化する。
この文脈で同氏は、エージェント間の信頼連鎖（chain of trust）を明示的に設計することの重要性を指摘している。単に「呼び出し元のエージェントが正しいトークンを持っている」だけでは不十分であり、そのトークンがどのような委任経路で発行されたかを検証できる仕組みが必要だという。
実務への示唆
Agarwal氏は抽象論にとどまらず、設計者が今すぐ取り組むべき実践的な方向性についても言及している。
- 最小権限の徹底：エージェントにはタスク遂行に必要な最小限の権限のみを付与する
- ポリシーのコード化：OPA（Open Policy Agent）のようなポリシーエンジンを活用し、アクセス制御ロジックをアプリケーションコードから分離する。OPAはCNCFのプロジェクトとして広く採用されており、AIエージェントのポリシー管理にも応用が広がっている
- 監査ログの設計：「エージェントが何をしたか」だけでなく「なぜその権限が付与されたか」まで記録に残す
- タイムボックスの活用：長命なクレデンシャルを避け、短命なトークンをタスクごとに発行する設計を採用する
AIエージェントのセキュリティは、まだ業界全体としてベストプラクティスが固まっていない領域だ。OWASP LLM Top 10のような取り組みが標準化を進めている段階であり、DPACTフレームワークはその空白を埋めるための実用的な出発点として機能する。
詳細はSecuring AI Agents: Identity, Authorization, and the DPACT Frameworkを参照していただきたい。
