【論文翻訳】認証された委任と認可されたAIエージェント
AIエージェントが人の代わりにデータを検索し推論し、Actionまでする世界を考えると、Agent自身がどう認証し認可されるのかが問題になります。
AIエージェントに対する認証認可アーキテクチャに関する論文「Authenticated Delegation and Authorized AI Agents」を解説します。
要旨
認証され、認可され、監査可能な、AIエージェントへの権限委譲のための新しいフレームワークは、既存の識別とアクセス管理プロトコルをベースに、OAuth 2.0とOpenID Connectをエージェント固有の認証情報とメタデータで拡張し、確立された認証とウェブインフラとの互換性を維持します。さらに、柔軟な自然言語の権限を監査可能なアクセス制御構成に変換するためのフレームワークを提案します。
このアプローチにより、AIエージェントの即時展開を促進し、主要なセキュリティおよび責任の問題に対処し、エージェンティックAIシステムが適切な行動のみを実行し、デジタルサービスプロバイダーがAIエージェントとのインタラクションをリスクなしに可能にするためのツールを提供します。
1. 背景と目的
AIエージェントとは、様々な外部デジタルツールやサービスとの相互作用を含め、ユーザーに代わって限られた直接的な監督下で複雑な目標を追求することができるAIシステムのことを指します。
AIエージェントは、特定のタスク実行能力やプロンプトインジェクションなどの攻撃脅威の懸念があります。そのため、資格情報(Credentials)と検証(Verification)は、以下の観点で重要です。
- AIシステムのプロパティとメタデータの検証
- オンライン空間における人間の一意的な識別(少なくとも人間とAIエージェントの区別)
- 文脈上の信頼性の保護
- AIによる影響力の行使の緩和
- AIによる人間の操作の防止
- より広範なAIシステムの管理または監査
そのため、エージェントに明示的に権限を委譲し、それらのエージェントをAIとして識別する必要があります。つまり、これらのエージェントに対してセキュリティと許可に関する人間中心の選択を強制する方法が必要です。
ここで改めて、認証と認可、監査可能性の3つの概念を整理しましょう。
-
認証(authentication)
- エンティティの身元を確認します。
-
認可(authorization)
- 認可は、認証された ID が実行できる許可されたアクションおよびリソースアクセスを決定し、委任された活動の範囲と制限を定義します。
-
監査可能性(auditability)
- すべての関係者が、クレーム、クレデンシャル、および属性が変更されていないことを検査および検証でき、信頼できる認証および認可の決定をサポートします。
本論文では、以下の3つの点に焦点を当てています。以下の図は「2.認証付き委任(deligation)」のための概念図です。
- AIエージェントにとって認証された委任がなぜ重要であり、どのようなリスクを軽減できるか
- AIエージェントへの認証付き委任(delegation)を可能にするために、既存の認証および認可プロトコルを拡張することでこのニーズに直接対処し、OpenIDの役割を検討する
- 自然言語の認可設定を監査可能で詳細なアクセス制御ルールに変換する方法
2. 認証付き委任(delegation)が重要な理由
認証付き委任は、AIシステムに対してツール、ウェブ、またはコンピュータ環境へのアクセスを必要とするタスクを実行させるプロセスであり、第三者が以下のことを検証できるようにすることを指します。
- (a) 相互作用しているエンティティがAIエージェントであること
- (b) AIエージェントが特定の人間ユーザーを代表して行動していること
- (c) AIエージェントが特定の行動を実行するための必要な権限を与えられていること。
認証付き委任は、人間ユーザーが特定のAIエージェントにデジタルサービスや別のAIエージェントにアクセスさせるためのデジタル認可を作成し、その認証が対応するサービスまたはエージェントによって検証されるというプロセスです。
このような認可情報には、エージェントインスタンスの固有識別子、エージェントが許可されている行動に関する権限などの情報が含まれます。また、認可は、認可を与えた人間のデジタルアイデンティティにリンクされている必要があります。(電子メールアドレスやドメイン固有識別子など)
※AIエージェントだからと言って、従来の既存の認証および認可メカニズムとは大きく異なりません。
2.1. 認証付き委任の機能
認証付き委任は、AIエージェントが複雑なタスクを実行し、ワークフローを自動化し、人間ユーザーに代わってデジタルサービスとシームレスに連携するための手段です。しかし、そのような権限を与えることは、認可範囲のずれ、リソースの乱用、または明確な責任の欠如といったリスクも伴います。
脆弱性を軽減させるために、強固な身元確認、明確な範囲設定、および相互認証が、エンタープライズプロセスの合理化から安全なマルチエージェントの協調まで、実用的なユースケースをどのように可能にするかを説明します。
2.1.1. AIエージェントへの権限委任における現在の課題
LLMの能力が向上するにつれて、AIエージェントをより自律的かつ汎用的にすること求められています。その重要な側面の一つが、ツールの使用や外部サービスへのアクセス能力です。
個人または組織のアカウントとのやり取り、機密情報へのアクセス、重要なインフラとのやり取りなどのユースケースに対応するためには、より強固な委任フレームワークが必要です。
2.1.2. 制限の伝達と範囲の制限
現在のAIエージェントの範囲を制限するアプローチは限られています。ユーザーはエージェントに対して強力なプロンプトを提供してその行動を制限することができますが、限界があります。ツールやウェブサイトへのアクセスをブロックすることはできますが、制御の粒度が限られています。AIシステムの導入者は、特定の行動やウェブサイトのサブドメインを監視およびブロックするなどの追加の制御を実装することができますが、これらの制限をエージェントが相互作用するサービスに伝えることはありません。
より強固な相互作用を可能にする方法
AIエージェントの範囲を明示的に制限し、これらの制限をエージェントが相互作用するサービスに伝えることで、AIエージェントとサービス間で強固に相互作用させられます。この設計がウェブ、API、自然言語アクセス全体でどのように行われるかについては「4. AIエージェントの範囲と権限の定義」で詳細に説明します。
2.1.3. マルチエージェントコミュニケーションにおける認証
複数のAIエージェントがタスクを協力して実行する際には相互認証が最も重要となります。通信チャネルのセキュリティを確保するだけでは不十分であり、エージェントは自らが代表するユーザーや組織を正確に認証する必要があります。
相互認証の役割
相互認証は、エージェントがお互いの意図、能力、および権限を信頼できるようにし、なりすまし、不正行為、権限のない行動を防止します。この検証は、信頼性、安全性、および説明責任のあるマルチエージェントエコシステムを構築するために不可欠です。
2.1.4. オンライン空間での人間空間の保護
AIエージェントが人間を模倣する能力が向上するつれて、テキストの作成、人格、そして微妙な人間の相互作用を再現することができるようになりました。そのため、本物の人々が存在するデジタル環境を維持することが難しくなっています。この課題は、安全で人間のみが利用できるオンライン空間を必要とし、人間性を検証することで大規模な操作を抑制する背景です。
認証付き委任の役割
多くのAIエージェントは、直接関与することができない、または関与したくない人間ユーザーの代理として有用なプロキシやアシスタント、代表者として機能します。認証付き委任により、選択的にAIエージェントにアクセスできるようにしつつ、AIエージェントが検証済みの人間の主体とリンクされていることを保証することができます。
2.1.5. 文脈の完全性のサポート
文脈の完全性とは
文脈の完全性は、文脈固有の規範やプライバシーに従うことを指します。これには、情報の流れに関与する人物(誰が関与しているか)、共有される情報の属性(どの情報が共有されるか)、情報が共有される条件(どの条件で情報が共有されるか)、およびこれらの規範を形作る社会的文脈(文化的、制度的、または状況的な環境)が含まれます。
文脈の完全性の役割
文脈の完全性は、AIエージェントが文脈通りの、透明性のある、社会規範や人間の委任者の期待に沿った行動を取るための視点を提供します。これには、AIが自律的に行うことが合理的な決定や、どの条件下で人間の監督や介入が必要か(例:人間が関与する必要がある場合や責任者が誰であるか)を検討することが含まれます。
2.2. 本論文で仕組みを提案する背景
認証付き委任、AIの結果の追跡可能性から、AIシステムがアクセスできる空間や行動の制限まで、さまざまな課題に対処できます。
識別と資格認証システムの最終的な目標は、安全なオンライン環境と認証されたサービスアクセスを促進することです。この目的のために、既存のさまざまなプロトコルや標準が開発されており、人間のユーザーとAIシステムの両方に対応しています。これらのプロトコルや標準は、異なる文脈でこれらの目標を維持するためにカスタマイズされています。
2.2.1. 他のAI識別情報との比較
オンラインでの人間の身元確認には、OAuth 2.0のようなシンプルな認証から、W3Cの検証可能なクレデンシャル、分散型識別子、EUデジタルIDのプライバシー保護デジタルウォレットなど、多くの研究があります。
人間性の証明
自動化されたSybil攻撃を防ぐために設計された人間性の証明システムや、CAPTCHAのようなシンプルなテューリングテスト、より堅牢なクレデンシャルが開発されています。より一般的には、「顧客を知る」という目標と、細かなアクセス許可(アイデンティティおよびアクセス管理、IAM)はインターネット上で一般的です。
ボットアクセスの制限
多くのウェブサイトは、サービスへのボットのアクセスを制限しています。これは、ボットや未認証のAIエージェントの存在が乱用や害を引き起こす可能性があるため重要ですが、多くの場合「ユーザーエージェント」レベルで行われます(例えば、すべての「GPTBot」ユーザーエージェントを禁止するなど)。
AIシステムの出力の追跡と検証
ウォーターマーキング技術やコンテンツの由来を確かめる手段が、AI生成コンテンツの起源を特定するための潜在的な解決策として浮上しています。しかし、これらのアプローチは信頼性の問題に直面しており、AIエージェントを使用する際の包括的な説明責任や安全性を確立するには不十分です。現在の検証方法の固有の制限は、コンテンツの作成だけでなく、AIシステムの展開と相互作用の広範な影響を追跡できるような、より強固なフレームワークが必要です。
機密性の高いAI機能へのアクセス管理
商業プラットフォームはAPIトークンとアクセス制御を実装しています。これらの開発は、AIシステムが外部サービスにアクセスする際に、その信頼性と許可を証明する堅固なメカニズムを必要とするという認識が高まっていることによる対応です。特に、AIシステムが重要なインフラや意思決定プロセスに統合されるにつれて、その必要性は増しています。
AIエージェントの特定インスタンスの特定
既存の認証および許可プロトコルを使用して、AIエージェントがユーザーの代理として制御された方法で行動できるようにする認証付き委任を拡張します。これにより、AIエージェントがユーザーを代理して透明性と説明責任を持って行動できるようになります。
2.2.2. Model Context ProtocolとGPT Actionsとの比較
Model Context Protocol (MCP)とは
Anthropicが最近発表したModel Context Protocol (MCP)は、AIシステムと外部ツールやデータソースの間で安全で構造化されたやり取りを可能にします。MCPは、リアルタイムでのデータ取得、APIとの連携、タスクの実行などを促進するための標準的なフレームワークを提供し、AIの出力の関連性を高めることを目指しています。
非常に有用な標準ではありますが、認証付きの委任に関しては限界があります。システム間の通信やアクセス制御を可能にするのみで、より広範な認証やアイデンティティ管理には対応していません。
GPT Actions
同様に、OpenAIのGPT Actionsは、GPTモデルがフライト予約やAPIからのデータ取得など特定のアクションを実行できるようにする統合機能を提供しています。しかし、これもMCPと同様の制約があります。
LangChainのAgent ProtocolやLangGraph Platformは、これらのアイデアをさらに発展させ、複数のエージェントが互いに連携できるようにしています。
2.2.3. エージェントAIシステムの文書化、安全性、ガバナンス
エージェントAIシステムおよびそのデータの文書化は、研究と実践の重要な分野です。バイアス、プライバシー、著作権に関する懸念に十分に対処することは難しいです。
最近の研究では、AIエージェントの能力と限界を理解するために、その文書化の必要性が強調されています。静的なシステム記述を超えて、動的な行動や相互作用パターンを捉えることが求められています。AIシステムがますますエージェント的になるにつれて、その進化する能力、意思決定プロセス、および潜在的なリスクを文書化する新しいフレームワークが必要です。
エージェントの行動を検証および逆転するランタイムや、言語モデル間の構造化されたコミュニケーションプロトコルが研究されています。研究者たちは、欺瞞的な行動を特定するための最先端モデルを評価したり、過去のインシデントを追跡し、エージェントの相互作用に対する広範な保護策を確立する必要があります。
2.2.4 認証付き委任がソリューションを統合する方法
以下の既存のアプローチを組み合わせて拡張しています
- AIエージェントのIDと資格情報
- 人間ユーザーの証明と身元確認
-
コンテンツの出所証明とウォーターマーキングメソッド
※デジタルコンテンツ(画像、動画、音楽など)に特定の情報(著作権者の名前やロゴなど)を埋め込む技術
これらのアプローチを統合したフレームワークは以下の特長を持ちます。
-
既存のアイデンティティ管理手法を継承
- AIエージェントのための明確な範囲設定とメタデータを導入
-
詳細な許可設定
- 実行可能な許可のセットを細かく設定
-
明確な責任のチェーン
- 各委任された行動に付随するコンテキストシグナル(例:モデルの認定資格や制限)
-
信頼性の向上
- 簡単なエージェントIDシステムカードよりも確実に検証可能な構造を実現
認証付き委任は、AIエージェントの行動を以下の要素に結び付けることで、安全で責任あるAIインタラクションの統一基盤を作成します。
- 検証可能な人間
- 認識されたAI固有の資格情報
3. AIエージェントの識別と認証のためのOpenID Connectの拡張
主なポイントは既存のインターネットインフラとの互換性を保つことです。
- 既存のプロトコルを利用して、ユーザーからAIエージェントへの権限の委任メカニズムを導入
- トークンベースの認証フレームワークである、OpenID ConnectとOAuth 2.0を活用
3.1 OAuth2.0とOpenID-Connect
既存のOAuth2.0とOpenID-Connectの特長を見てみましょう。
-
OAuth 2.0プロトコル
- RESTfulパラダイムに基づき、あるサービスが別のサービスにあるリソースにアクセスするための認可をユーザーが提供する必要があったために生まれました。
- 重要な要件は、ユーザーが不在(例:オフライン)でもアクセスが継続的に許可されることです。
-
既存のユーザー認証プロトコル
- MIT KerberosやCHAPなど、主に人間ユーザーがホストコンピューターを利用して認証サーバーに接続する際に使用されます。
3.2 ユーザーからAIエージェントへの権限委任
OAuth 2.0プロトコルは、人間ユーザーがAIエージェントに特定のタスクを委任するための新しいメカニズムを確立するために利用できます。つまり、人間ユーザーがAIエージェントに対して、ユーザーに代わって限定されたタスクを実行する権限を与えるということです。
拡張の考え方
-
ユーザーの認証
- 人間ユーザーはまず、自身の身元を証明するためにOpenIDプロバイダー(OP)に認証を行います。
-
AIエージェントの登録
- ユーザーはAIエージェントをOPに登録します。これにより、後で外部のエンティティがAIエージェントに関する追加情報を取得できるようになります。この登録は、ベンダーを通じてエージェントが作成される際に自動的に行うことも可能です(例:OpenAIで新しいアシスタントインスタンスを作成する場合など)。
- 既存のOAuth 2.0クライアント登録プロトコルをカスタマイズして、ユーザーがAIエージェントをOpenIDプロバイダーに登録し、AIエージェントを人間ユーザーの代理人として指定することができます。
-
新しい委任トークンの発行
- ユーザーは、AIエージェントがユーザーに代わってタスクを実行する権限を与える新しい委任トークンを発行します。ここで、「認可」という用語は、AIエージェントが人間の委任者によって所有されていることを明確にすることを指します。
トークンの利用
ユーザーIDトークンとAIエージェント委任トークン
- これらのトークンはW3C検証済みクレデンシャル(VC)データ構造内で参照(またはコピー)することができます。
- これにより、AIエージェントは他のエンティティ(他のサービスや他のAIエージェント)とのやり取りでVCを使用でき、両方のトークンが標準のOPで検証可能であるという利点があります。
図解(OpenID Connect(OIDC)とUser Managed Access(UMA)プロトコルの統合)
人間のユーザーからAIエージェントへの委任権限を確立するためのプロセスは以下の通りです。
- 人間のユーザーがOpenIDプロバイダー(OP)に認証
- AIエージェントを登録
- 委任トークンを発行
- トークンによりAIエージェントがユーザーに代わって認可されたタスクを実行可能に
3.3 トークンベースの認証フレームワーク
既存のOIDC(OpenID Connect)フレームワークを拡張することで、AIエージェントの関連属性と委任に関するメタデータを、身元関連のトークンセットで提供することができます。
-
ユーザーIDトークン
- これはOpenIDプロバイダー(OP)サービスによって発行/署名される既存のIDトークンデータ構造です。人間ユーザーに関する情報を表すもので、通常のログインで使用されるものと同様です。
-
エージェントIDトークン
- これはOAuth 2.0ネイティブクライアントとして発行されるAIエージェントに関する情報を含むトークンです。エージェントの所有者がすべての鍵情報と秘密のパラメータを管理します。このトークンには、エージェントのユニーク識別子から、システムのドキュメント、能力や制限に関するメタデータ、他のAIシステムとの関係属性など、より詳細な情報を含めることができます。
-
委任トークン
- この新しく導入されたトークンは、AIエージェントがユーザーに代わって行動する権限を明示的に付与します。委任トークンは人間の委任者によって発行および署名され、対応するユーザーのIDトークンとエージェントのIDトークンの参照(例:ハッシュ)を含み、OPを信頼するサービスによって検証されます。
- 委任の性質に関する情報も共有できます。例えば、エージェントの要約された目標や範囲の制限を共有することで、第三者がAIエージェントを有用なエンドポイントやインタラクションパラダイムに導くのに役立ちます。
- 委任トークンには、有効期限や取り消しエンドポイントなどの有効条件を指定する必要があり、偽造を防ぐためにユーザーによってデジタル署名されます。さらに、トークンには補足的なメタデータ(例:ログ記録や監査用のURL)を含めることができ、サービスプロバイダーがやり取りを記録し、委任された行動を監視し、異常に適切に対応できるようにします。
- 委任トークンが有効なユーザーIDトークンと適切に発行されたエージェントIDトークンを参照していることを確認することで、リモートサービスはアクセスを許可する前に、AIエージェントの権限の真正性と範囲を確認できます。
3.4 委任の範囲制限
委任フレームワークは、人間ユーザーがAIエージェントの行動に対して明確な範囲を定義するための仕組みです。
委任トークンに範囲の制限をエンコードすることで、AIエージェントの行動範囲を明確に設定できます。ユーザーは、AIエージェントに対してどのような行動が許可されるかを具体的に定義することができます。
AIエージェントの行動は非常に多様であり、柔軟性が高いため、範囲設定は独自で興味深い課題となります。
3.5 検証可能な資格情報を代替手段として使用する
検証可能な資格情報(VC)ベースのアプローチ
- 組織や個人などの発行者が、ユーザー、AIエージェント、または検証可能な改ざん防止属性が必要な他のエンティティに関するさまざまな主張を証明するクレデンシャルに署名できます。
- VCは特定のトランスポートプロトコルに依存しないため、分散型またはピアツーピアの方法で提示および検証できます。これは、トークンの発行と検証を中央のOpenIDプロバイダー(OP)に依存するOIDCとは対照的です。
VC(検証可能な資格情報)の主な利点
- プライバシーの向上
- すべての属性を開示するのではなく、単一のIDプロバイダーに依存することもなく、ユーザーやAIエージェントは特定のやり取りに必要な情報だけを共有できます。
- 選択的開示
- この「選択的開示」能力により、中央集中的なログ記録やプラットフォーム間の相関に対する懸念を軽減できます。
- やり取りが複数のドメインや組織にまたがる場合に有効です。
OIDCをVCベースのモデルに完全に置き換える場合のトレードオフ
OIDCの利点はこれらです。
- OIDCは既にライブラリと導入事例の強力なエコシステムを享受しています。
- トークンの更新、取り消し、対象制限などの問題に対してよくテストされたサポートを提供しています。
VCの課題はこれらです。
- VCは強力ですが、これらのフローを大規模に再現するには追加の作業が必要です。
- 特に、各検証呼び出しが新しい署名チェックやブロックチェーンまたは分散型台帳とのやり取りを要求する場合です。
多くの企業環境では、完全に分散型のIDインフラストラクチャを採用する前に、VCを既存のシングルサインオン(SSO)や多要素認証フレームワークに組み込むことを好むかもしれません。
ハイブリッドソリューション
実際にはハイブリッドソリューションが最も実用的なことが多いです。
ユーザーまたはAIエージェントは、豊富な属性や規制の承認をエンコードしたVCを保存および管理できます。
既存の認証または認可エンドポイントと互換性を持たせるために、OIDCトークンを活用することができます。
- エージェントIDトークンは、その行動、属性、文脈、および関係属性に関する詳細なメタデータを含むVCを埋め込むことができます。
- OIDCを統合するサービスプロバイダーは、従来のトークンベースのハンドシェイクを利用しながら、埋め込まれたVCを解析して、追加の信頼性とコンテキストを得ることができます。
- 例として、OID4VCがこれをサポートしています。
4. AIエージェントの範囲と権限の定義
認証された委任は、強固なスコーピングメカニズムと密接に結びついています。ユーザーは自分の権限と指示を明確かつ曖昧さなく指定する必要があります。しかし、AIエージェントが実行できる行動の範囲が非常に広いため、これは矛盾となります。
信頼性や整合性の観点では、AIエージェントが指示を正しく守ることが重要ですが、誤った指示、プロンプトインジェクション攻撃、およびセキュリティ監査の難しさといったリスクがあるため、純粋な自然言語のプロンプトだけでは範囲設定、権限、セキュリティツールとして不十分です。AIエージェントのインフラストラクチャが、柔軟な自然言語のスコーピング指示を機械で読める、バージョン管理可能で監査可能な構造化された権限言語に変換することで、このギャップをどのように埋めるかを提案します。
タスクスコーピングとリソーススコーピングの違いの整理をします。
-
タスクスコーピング
- エージェントがユーザーの代わりに実行するアクションやワークフローを指定することを指します。
- これらのアクションは、大まかなタスク(例:「財務報告書の作成」)から、より具体的なアクション(例:「新しいデータベースエントリの作成」)まで多岐にわたります。
-
リソーススコーピング
- エージェントが使用または変更できるリソース(情報、API、ツールなど)を指定することを指します。
タスクスコーピングとリソーススコーピングは概念的には別々のものですが、密接に関連しています。例えば、特定のタスクの実行を制限することで、エージェントが不必要なリソースにアクセスしないようにすることができます。同様に、特定のリソースへのアクセスを制限することで、実行可能なタスクも制約されます。
次に、アクセス制御メカニズムが複雑なAIエージェントや自然言語ワークフローとどのように統合できるかについて説明します。構造化された権限がエージェントのスコーピングにどのように強力かつ一般化可能な基盤を提供し、自然言語や人間の監視がこれらのアクセス制御に対する柔軟なインターフェースについても説明します。
4.1 構造化された権限言語
多くのスコーピングメカニズムは、構造化され、システムが読み取れるポリシー仕様です。これらの仕様は、どのエンティティが、どの条件下で、どの権限を持つかを明確に定義します。
いくつかの権限のエンコード言語やフレームワーク
- XACML(拡張アクセス制御マークアップ言語)は、XMLを使ってアクセス制御ポリシーをエンコードおよび評価します。
- ODRL(オープンデジタル権利言語)は、デジタルコンテンツの使用権限を表現するために設計されています。
- 他にも、OBAC、ROWLBAC、KaOS、MultiOrBACなどの言語があり、これらはリソース、主体、権限をモデル化するために通常はOWLを使用して記述されるオントロジーに依存しています。
構造化された言語は機械が読み取れる形式であり、従来の非AIシステムによって確実に適用することができます。実際の観点から言えば、リソーススコーピングに適しており、リソースは通常、個別に分類、列挙、セキュリティドメインにグループ化することができます。
しかし、これらには3つの主な欠点があります。
- これらのフレームワークはリソースの列挙には適していますが、タスクが一連の操作として簡単に記述できない場合、タスクスコーピングには柔軟性に欠けます。
- ポリシーの定義は、リソースやタスクの数が多い環境や、ウェブコンテキストのように可能なウェブインタラクションの数が膨大である場合に、長く複雑になることがあります。
- エージェントが相互作用する異なるデジタルシステムに対して更新が必要です。
これらの欠点にもかかわらず、構造化された権限言語はアクセス制御の基盤として重要です。リソーススコーピングにおいて、正確で監査可能な基盤を提供します。代替アプローチとして、エージェントが環境とどのように相互作用するかを制約するためにスキーマ検証を使用する方法もあります。
4.2 認証フロー
エージェントの行動を制御するもう一つの方法は認証フローです。つまり、エージェントがアクションを実行する前に、ユーザーや他の権限から確認を求めるタイミングを決定することです。すべてのアクセス決定を単一のポリシー定義に前もって組み込むのではなく、認証フローは、境界線上または高リスクの操作に対して動的にユーザーの承認を要求します。
このアプローチの主な利点は、ユーザーがすべてのケースを静的なポリシーで定義する必要がないことです。さらに、認証フローは他のスコーピングメカニズムと組み合わせることができます。
一方、頻繁な承認フローはユーザー体験に悪影響を与える可能性があります。この場合、ユーザーは適切なレビューをせずに承認を与えてしまいます。また、どのリクエストが明示的な承認を必要とするかを判断することは容易ではなく、誤分類は過度のプロンプトや重要な操作が見逃される結果を招く可能性があります。
実際には、共通のシナリオに対する強力で構造化されたポリシー定義と、まれに発生する特に重要なアクションに対する動的な認証フローを組み合わせることができます。このアプローチにより、ユーザーは日常的なチェックの大部分を自動化されたポリシーに任せつつ、新規または曖昧なリクエストに対してはユーザーの承認を求めることができます。
4.3 自然言語メカニズム
モデルの動作を安全な方向に誘導するためにプロンプトがよく使用されます。例えば、ユーザーが「公開文書の要約を作成してもいいけれど、機密のメトリクスは開示してはいけない」と言うように指示することができます。このような指示は、原則としてLLMベースのシステムによって解析され実行されます。
強みはユーザーフレンドリーさです。技術的でないユーザーにとって、自然言語でポリシーを表現する方が、正式なルールを書くよりもはるかに簡単です。さらに、自然言語は、構造化された言語でエンコードするのが難しい、微妙または文脈に依存する指示を捉えることができます。これにより、タスクおよびリソースのスコーピングに理想的です。最後に、自然言語は他のLLMベースのエージェントとのやり取りなど、自然言語の読み取りや使用を必要とするアクションに対してポリシーを適用するために使用できます。
しかし、自然言語は信頼性のあるポリシー適用に必要な精度を欠くことがよくあります。例えば、「機密データ」や「プライベートメール」といった用語は、文脈によって異なる解釈をされる可能性があります。この問題は、異なるポリシー間の競合の場合に特に重要であり、あいまいで文脈に依存する指示が異なる解釈を生む可能性があります。LLMに完全に頼ってあいまいな自然言語の指示を解釈し、適用することはセキュリティ面でリスクが高くなります。
4.4 構造化された権限、自然言語、およびユーザーの監視の組み合わせ
自然言語との接続
構造化されたリソーススコーピングは堅牢で監査可能ですが、使いやすさと柔軟性に欠けます。この問題に対処するために、LLMや別のスコーピングプロンプトに指示を与え、適用すべきスコーピングの制限を柔軟に表現することができます。これらの自然言語によるスコープは、該当する環境におけるエージェントまたはAIシステムによって、構造化されたスコーピング形式に変換されることができます。
同様のプロセスは、エージェントが相互作用する異なる環境やデジタルサービスにも適用することができ、広範なサービスやコンテキストにわたって柔軟な権限指示を適用することができます(AIエージェントの広範なアクションスペースを考慮すると重要です)。
人間をシステムに組み込む
最後の重要なステップは、人間の委任者を通じてこれらの構造化されたアクセス制御を検証することです。認証ワークフローは、ユーザーが異なるシステムの構造化されたアクセス制御の制限を短時間でレビューし、承認するようにします。例えば、Wrightの研究では、LLMエージェントが構造化された情報(この場合、会議の日程)に合意し、それが人間のユーザーによって確認されます。
ハイブリッド実装への統合
これらの要素を実装に統合するのは比較的簡単です。LLMは、高レベルの自然言語によるリソース制約を、ユーザーがレビューし承認できる形式的な構造化されたルールに変換するのを支援します。
このようなワークフローの多くの具体的な詳細(中間検証チェックやLLMの構造化された言語への変換の堅牢性の評価など)を解決する必要がありますが、これらの具体的な点は今後の課題とします。
最終的に、構造化され明確なリソース制約に焦点を当てることが、AIエージェントが特定の環境内で認可された範囲内にとどまることを確保する最も信頼性の高い方法です。高レベルな自然言語によるタスク制約の余地はありますが、これらは主な適用メカニズムへのガイダンスとして扱うべきです。実際、自然言語はAIエージェントの行動の非常に広範な可能性を適切に処理できますが、それをアクセス制御に変換することで、エージェントの行動制限が有限で監査可能なコントロールに基づくものになります。このアプローチを、よく設計された認証フローと組み合わせ、生成されたポリシーの解釈をユーザーに支援することで、人為的なミスの可能性を減らし、責任の強化と認証された委任の堅牢性の向上が期待できます。
4.4.1 エージェント間のスコーピング
ユーザー - エージェント - サービス モデルを超えて、このアプローチはエージェントが他のエージェントに自分の制限を伝播させたい場合に適用できます。
これは、異なる組織間でのエージェント間のコミュニケーションが発生するシナリオで特に有用です。それぞれの組織には別々のポリシーやリソース制約があります。
このようなワークフローは、エージェントが柔軟な自然言語で通信する場合でも、その基礎となるスコーピングと記録管理が監査可能な決定的なポリシーに基づいていることを保証します。その結果、不正なデータ共有や無制限のエージェント行動のリスクが大幅に減少し、各エージェントの委任者から制限された資格情報を「継承」する能力が厳密に制御されます。
5. Discussion
5.1 OpenID Connectアプローチの問題点
OpenID Connect (OIDC)およびOAuth 2.0ベースのフレームワークは、認証および委任のための堅牢で実績のあるメカニズムを提供します。しかし、それにはトレードオフが伴い、プライバシー、セキュリティ、および監査可能性において異なるトレードオフを持つ他の代替手段よりも複雑になる可能性があります。
複数のサインインフローによるオーバーヘッド
OpenID Connectアプローチの大きな欠点の一つは、各サービスプロバイダーでAIエージェントを認証するために必要な複数のサインインフローによって引き起こされる可能性のあるオーバーヘッドです。これは、新しいメールクライアントを設定する際に、ユーザーがさまざまなサービスへのアクセスを認証するために繰り返しログインしなければならない経験と似ています。このような認証フローは、各プロバイダーが独自にAIエージェントの委任資格情報を確認することでセキュリティを強化しますが、安全なシステムへのアクセスを遅らせることで使いやすさが犠牲となり得ます。
理論的には、完全なOIDC認証フローを実行せずに委任トークンを直接提示することでこの負担を回避することは可能です。しかし、このショートカットは、特にトークンの新鮮さと検証に関連する重要なセキュリティ保証を犠牲にします。
OpenIDプロバイダへの依存の増大とプライバシーリスク
OpenIDプロバイダ(例:Google、Facebook、または同等のエンティティ)への依存は、システム的なプライバシーの懸念があります。OIDCプロバイダはすべての認証フローを仲介するため、各種サービス間で個別のAIエージェントのインタラクションを追跡および関連付ける能力を持ちます。これには、統計的な使用状況の分析を収集することや、依存パーティにログの共有を要求することが含まれ、大規模な行動プロファイリングを促進します。このような集中化された可視性はユーザープライバシーを損なうとともに、潜在的な監視の一点を生み出します。
これらのリスクに対処するためには、ペアごとの匿名識別子やログ共有要件の最小化などの強力なプライバシー緩和策が必要ですが、これらのメカニズムはシステムにさらなる複雑さをもたらします。
W3C Verifiable Credentials(VC)との比較
この論文では、OpenID Connect(OIDC)フレームワーク内にW3C Verifiable Credentials(VC)を埋め込む能力を強調していますが、完全なOIDC認証フローは、ネイティブなW3C VCベースの委任および認証プロセスと比較して重いかもしれません。W3C VCの発行、認証、委任メカニズムは、繰り返しの認証フローや中央プロバイダの仲介の追加オーバーヘッドを伴わずに、AIエージェントの身元確認のための同じ要件を直接満たすことができます。
さらに、W3C VCベースのアプローチは、単一のプロバイダに信頼の仲介や資格の使用を追跡させることがないため、本質的にプライバシー保護の性質を持っています。簡素化されたVCベースのプロセスは、必要に応じてOIDC互換の資格情報を生成し、シンプルさとプライバシーを維持しながら相互運用性を実現できます。
まとめると、これらの制限は、OIDCベースのフレームワークにおけるセキュリティ、使いやすさ、およびプライバシーの間の重要なトレードオフです。
5.2 自然言語スコーピングの限界
自然言語のスコーピング指示を構造化された権限言語に変換することは、より柔軟なインターフェースを可能にしますが、いくつかの課題もあります
信頼性と正確性の評価
最大の課題の一つは、ユーザーの自然言語仕様から機械が読み取れるポリシーへの変換が正確であることを保証することです。自然言語の指示には文脈依存やあいまいな用語が含まれることが多く、それがAIシステムによる誤解を招きやすくします。人間が介在するアプローチ(Human-in-the-loopアプローチ)により、ポリシーレビューを通じてこれらのリスクを軽減できますが、その人間による検証も完璧ではありません。
- ユーザーは微妙な変換間違いを見逃す可能性があります。
- 権限仕様の複雑さが増すと、元の自然言語の指示と生成された構造化ポリシーとの整合性を確認することが、技術的(大規模なポリシー定義のため)にも認知的(レビューアの負担のため)にも困難になります。
LLM攻撃の新たな脅威ベクトル
言語ベースのインターフェースの弱点を悪用すると、純粋に静的なアクセス制御では存在しない新たな脅威が露呈します。プロンプト注入や脱獄攻撃により、LLMは不正な権限を付与してしまします。リソースやタスクスコーピング指示を通常のチャットセッションや対話から分離することで攻撃の可能性は減少しますが、それでも新しい攻撃対象が発生し、それを守る必要があります。
文脈
ポリシーが進化したり、タスクの文脈が時間とともに変化するにつれて、以前の自然言語指示が新たに導入されたリソースと一致しなくなるリスクがあります。指示の複数の改訂を一貫して維持することは容易ではありません。
制限を強制するための第三者への部分的な依存
一部のコンテキストでは、アクセス制御ルールが対話する外部環境やエージェントに適用されます。これらのアクセス制御の適用に対するセキュリティを維持するために、対応するパーティがネイティブエージェントを信頼するだけでなく、ルールを強制する必要がある場合があります。このような場合、第三者の信頼性が重要な失敗点となります。
5.3 モデルベンダーはこれを提供できるか?
モデルベンダー(例:OpenAI、Anthropic、Google)は、AIシステムがデジタルサービスにアクセスする際にどのユーザーが代表されているか、そして意図されたスコープや権限が何であるかを共有するツールを提供します。しかし、現在のアプローチは、セキュリティおよび検証の観点からは不十分です。例えば、AIシステムのユーザーエージェント文字列に情報を含めることや、AIシステムによるAPI呼び出しに情報を書き込むことです。代わりに、これらのサービスはユーザーエクスペリエンスを変更せずにAIシステムのためのOpenIDプロバイダとして機能するか、または認証された委任フレームワークの別のインスタンス化を好む場合には、AIエージェントおよびユーザーのための堅牢で一意のIDと組み合わせたW3C検証可能な資格情報を提供できます。
5.5 認証された委任の法的基盤
代理権法は、一方の当事者(委任者)が他方の当事者(人間の代理人)に自分の代わりに行動することを許可する状況に対処します。代理権法は、第三者が最終的な責任を持つ者を確認する必要がなく、不当に不利益を被らないようにするために、委任者が代理人の行為に対して責任を負う場合を決定することです。
AIエージェントが学習し、自己修正し、自律的に動作することに既存の代理権法がどのように適応するかは不確かです。意図、同意、観察可能な権限といった従来の概念は、現在の自律システムには適用が難しいです。これらの不確実性に対応するために、認証された委任フレームワークは、各権限の委任が検証可能なモデルを提供します。このフレームワークは、第三者がAIエージェントが本当に委任者の代わりに行動することを自動的に確認できるようにします。
**AIを強化したシステムにおける信頼と責任の重要な要素は、意味のある人間の監視を維持することにあります。**例えば、EU AI法は、倫理的で透明性があり、責任を持った結果を確保するために、高リスクのAI決定における人間の関与の重要性を強調しています。
- 認証された委任フレームワークは、この原則をサポートし、エージェントのワークフローにおける人間の役割を明確にします。
- コードの不透明な層の背後にAIシステムへの権限を委任するのではなく、第三者はAIがいつ、どのように、そしてどの条件で行動する権限を持つかを確立できます。
- これにより、人間は決定を確認し、エラーを修正し、自動化された行動が広範な法的および倫理的基準と一致していることを保証できます。
6. 結論
この論文は、AIエージェントへの認証された委任のための実践的なフレームワークを提案し、デジタル空間における認可、責任、身元確認、およびアクセス制御管理に関する緊急の課題に対処しています。既存のOAuth 2.0およびOpenID Connectプロトコルを、AI専用の資格情報と委任メカニズムで拡張することで、ユーザーからAIエージェントへの権限の安全な委任を可能にし、明確な責任の連鎖を維持します。
提案されたトークンベースのフレームワーク(ユーザーIDトークン、エージェントIDトークン、委任トークンで構成)は、エージェントの身元確認、権限の制御、および監査証跡の維持のための堅牢な基盤を提供し、自然言語指示に応じて生成される詳細で堅牢なスコープ制限をサポートします。
AIエージェントがデジタル空間でますます普及する中、このようなフレームワークは、AIエージェントが適切な範囲内で動作し、委任者に対して責任を負うことを確保するために不可欠です。今後の研究の方向性としては、一般的なAIエージェントタスクのための標準化されたスコープ定義の開発、プライバシー保護の委任メカニズムの探求、サービスプロバイダーがエージェント認証ポリシーを実装および管理するのに役立つツールの作成が含まれます。最終的には、AIシステムが既存のデジタルインフラに安全かつ生産的に統合されることを目指しています。
Discussion