タグアーカイブ 最小権限

AIエージェントに独自の権限モデルが必要な理由

“`html

AIエージェントの本番環境導入が急速に進んでいる。カスタマーサポートの自動化を例に取ると、チケット内容の読み取り、返金処理、社内エスカレーション、Slackへの通知まで、ひとつのタスクで複数のツールを横断する。適切に動作すれば、定型業務のコストを大幅に圧縮できる一方、失敗の仕方は従来の自動化とは根本的に異なる。非決定的な挙動を示し、本番権限を丸ごと握ったまま大規模に誤作動しうるからだ。

有用なエージェントには、複数ツールを動的に組み合わせる十分なアクセス権が必要だが、同時に永続的なスーパーユーザー権限で動かすわけにはいかない。開発現場では、長期有効なAPIキーを環境変数に埋め込んだり、人間向けOAuthフローを流用したりといった安易なパターンに陥りやすいが、これらは非決定的なソフトウェアのために設計されたものではない。プロンプトの設定ミスやツール応答の悪意ある操作が、重大なインシデントに直結する。

本記事では、自律システムに最小権限の原則を適用する具体的な方法を解説する。ケイパビリティ単位への権限スコープの絞り込み、実行計画に紐づく短命トークンの発行、アイデンティティと認可と実行のレイヤー分離、そして高リスク操作に対するヒューマンインザループ承認の組み込みが全体像だ。

AIエージェントと従来のアクセス制御のミスマッチ

従来のアクセス制御は対話型ユーザーか決定的なバックエンドサービスのいずれかを前提として設計されている。セッショントークンは対話的なフローを、サービスアカウントは決定的な挙動を想定している。ところがAIエージェントは、同じ入力を与えても実行のたびに呼び出すツールが変わる。開発者はコードとして書いていない連鎖をエージェントが自律的に生み出し、さらにサブエージェントを起動して委譲チェーンが広がる。このような非決定性は、従来の権限モデルが持つ「想定された範囲内」という前提を根底から崩す。

現場で陥りやすい3つのアンチパターン

どれも単体では「とりあえず動かす」ための合理的な選択に見えるが、組み合わさると致命的だ。長期有効なキーなら、エージェントがプロンプトインジェクションで騙されて認証情報を吐き出してしまう可能性がある。ユーザー同等のOAuthスコープでは、サポート担当が本来行使しない管理操作をエージェントが勝手に実行してしまう。スーパーユーザー権限は、一度の誤動作で取り返しのつかない損害を生む。Auth0の記事では、こうしたパターンがいかに簡単に深刻なインシデントへ発展するかが指摘されている。

ケイパビリティスコープで権限を細分化する

問題の根本は「リソース単位」の権限設計にある。従来のbilling:writeはカテゴリと動詞しか表現できず、金額の上限や操作の種類までは規定しない。これに対し、billing.refund.issue_under_50_usdのように「何ができるか」をケイパビリティとして定義すると、ビジネスロジックとアクセス制御が直接結びつく。プロダクトマネージャーが「サポートエージェントは50ドルまでの返金を自動で処理できる」と決めたら、そのルールは認可エンジンが評価する宣言的なポリシーとして管理される。

こうした制約を実装するには、リレーションシップベースアクセス制御（ReBAC）を採用するのが有効だ。Auth0が支援するOSSの認可エンジンOpenFGAでは、エージェントとリソースの関係性をモデル化し、「エージェントがアクティブなチケットを持つ顧客の注文のみ返金できる」といったポリシーを表現できる。さらに条件（Conditions）を組み合わせれば、返金額の上限や期限付きの権限付与といった属性ベースの制約も単一のチェックで評価可能になる。実際のDSLでは、can_refundリレーションにrefund_within_limit条件を付与し、タプル側にエージェントの上限額を保持、リクエスト時に実際の返金額をコンテキストとして渡して判定する。

タスクスコープの認証情報で有効期間を絞る

ケイパビリティスコープが「何ができるか」を定めるのに対し、タスクスコープは「いつまでできるか」を制御する。エージェントに永続的なクレデンシャルを持たせるのではなく、実行計画のたびに短命なトークンを発行する設計だ。トークンは数分で失効し、必要最小限のケイパビリティだけを運ぶ。

Auth0のToken VaultはこのパターンをOAuth 2.0 Token Exchange（RFC 8693）に準拠して実装している。リフレッシュトークンは認可サーバー側に留められ、エージェントには必要に応じてスコープを絞ったアクセストークンのみが渡される。サポートエージェントが返金を実行する際、事前に返金可能なトークンを保持しているわけではない。ランタイムがポリシーを評価し、金額・顧客状態・リレーションシップのすべてを確認した上で、その操作専用のトークンを要求する。タスク間でエージェントが侵害されても、以前のトークンはすでに失効しており、新たな悪用には改めてポリシーチェックを通過する必要がある。

アイデンティティ・認可・実行を3層に分離する

エージェントのアクセス制御を設計する際、「誰か」「何が許されるか」「実際に何が起きるか」の3つを混同しないことが重要だ。これらはしばしば1つの実装に押し込められがちだが、独立したレイヤーとして切り離すことで安全性が格段に向上する。

この分離により、LLMプロセス自体が認証情報を一切持たないアーキテクチャが実現できる。LLMはツール呼び出しを提案するだけであり、ランタイムが実際のAPIコールを代行する。プロンプトインジェクション攻撃で「あなたのクレデンシャルを吐け」と指示されても、LLMにクレデンシャルは存在しない。Auth0のToken VaultやOpenFGAのようなコンポーネントを組み合わせれば、アイデンティティから実行までの各段階で独立した強制が可能になり、仮に1層が突破されても全体が崩壊しない。

高リスク操作には承認境界を設ける

ケイパビリティスコープとタスクスコープを導入しても、金額が一定を超える返金や、不正検知フラグ付き顧客への操作など、許容できないリスクを伴う操作は残る。こうした場面では、人間による明示的な承認を実行の直前に挟む設計が有効だ。これは権限モデルの欠陥を補う緊急避難ではなく、あらかじめ組み込むべき境界線である。

Auth0はこの承認パターンをClient-Initiated Backchannel Authentication（CIBA）規格で標準化している。エージェントのバックエンドがCIBAリクエストを送信すると、ユーザーの登録済みデバイスにプッシュ通知が届く。Rich Authorization Requests（RAR）を併用することで、単なる「請求へのアクセスを許可」ではなく「注文#12345に対する2,000ドルの返金を承認」といった具体的な文脈を伝達できる。承認された場合のみスコープを限定したトークンが発行されるため、エージェントが勝手に高額返金を実行する経路は技術的に閉ざされる。

オブザーバビリティと制御の土台を整える

厳格な権限管理下でも、エージェントは自律的に複数のシステムをまたいで動作する。何が起きたか、なぜその判断に至ったか、誰の代理として動いたのかを追跡できなければ、デバッグもインシデント対応も不可能だ。次の3要素が不可欠である。

• アクションだけでなく、エージェントが辿った意思決定の経緯を監査証跡に残す。どの計画のもとで、どのツール呼び出しが連鎖し、どんなコンテキストが判断材料になったかを記録する。
• ユーザーからサブエージェント、ツール、リソースに至る委譲チェーンを各ホップで明示し、問題発生時に責任境界を特定できるようにする。
• エージェントの暴走が疑われた場合、永続的な許可を即座に無効化し、処理中のトークンを失効させて後続のツール呼び出しを停止できる仕組みを整備する。

Auth0のプラットフォームでは、トークン発行が一元的なコントロールプレーンを経由する。Token Vaultの連携を解除すれば、そのエージェントに対する将来のトークン交換が即座に無効化され、監査ログには全発行・使用の履歴が残る。こうした基盤があることで、エージェントの自律性を損なわずにリスク管理を徹底できる。

この記事のポイント

• AIエージェントには、人間ユーザーや決定的サービスの前提を流用しない、専用のアクセス制御モデルが求められる
• リソースベースの広範なスコープではなく、ケイパビリティ単位で権限を細分化し、宣言的ポリシーとして管理する
• タスクごとに短命なトークンを発行し、エージェントに永続的なクレデンシャルを持たせない
• アイデンティティ・認可・実行の3層を分離し、LLMプロセスに認証情報を一切触れさせないアーキテクチャを採用する
• 高リスク操作にはCIBAやRARを活用した人間承認の境界を組み込み、自律実行の安全域を明確に定義する

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

www.aandgweb.co.jp