ケイパビリティベースのアクセス制御はエージェントのツール権限をどのように制限するのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does Capability-Based Access Control Limit Agent Tool Permissions? - Zima Store Online

権限ベースのアクセス制御は、すべてのツール呼び出しが継承する暗黙の権限ではなく、権限を明示的かつリソースに結び付いたケイパビリティとして扱うことで、エージェントの権限を制限します。

ホームサーバーでは、あるエージェントにはバックアップ先の検査、別のエージェントには1つのサービスの再起動、さらに別のエージェントには写真フォルダーの読み取りだけを許可し、マスター認証情報を共有せずに済みます。

ケイパビリティは権限を特定のリソースに結び付ける

ケイパビリティベースのアクセス制御では、対象オブジェクトを識別し、そのオブジェクトで利用できる権限を伴うトークンまたは参照として権限を表します。

seL4では、ケイパビリティをエンティティまたはオブジェクトへのアクセス許可を与える偽造不能なトークンと説明しています。所有していること自体が認可の仕組みの一部です。seL4は、特定のカーネルオブジェクトを参照するケイパビリティによって権限を表現し、リソースに結び付いた権限の具体例をseL4ケイパビリティモデルで示しています。

ホームAIエージェントでは、バックアップツールにファイルシステム全体への暗黙のアクセス権ではなく、1つのリポジトリに対する権限だけを渡せます。パスを知っているだけでは、権限は与えられません。

所有によって暗黙の権限を明示的な委任に置き換える

従来の環境では、プロセスの認証情報や広範なAPIトークンを通じて、暗黙の権限が提供されることがよくあります。

ケイパビリティシステムでは、コンポーネントが実際に保持している参照によって、権限を明示的にします。

seL4のcapDLは、システムのどの部分が、別のどの部分に対するケイパビリティを持つかを記述します。こうした分配がアクセス制御の境界を定義します。WasmtimeはWASIリソースに対するケイパビリティ指向の分離を説明しており、広範な暗黙のアクセスを明示的な所有に置き換える方法をWasmtimeのケイパビリティセキュリティモデルで示しています。

したがって、写真整理用のサブエージェントにはインポートフォルダーへの読み取りアクセスとステージングへの書き込みアクセスだけを与え、アーカイブを削除する権限は与えない、といった構成が可能です。

権限はリソースそのものより狭くできる

ケイパビリティには、参照先オブジェクトで利用できる操作を制限する権限を持たせられます。

2つのエージェントが同じオブジェクトに対するケイパビリティを保持しながら、異なる権限を持つこともできます。

seL4は、ケイパビリティがオブジェクト参照とアクセス権を内包し、許可される操作を制御すると説明しています。Bytecode AllianceはWASIをケイパビリティベースのセキュリティを中心に説明しており、付与される権限をホストリソースそのものより狭くできるという考えをWASIのケイパビリティベースセキュリティで支えています。

監視ワークフローにはステータスの読み取り権限を持たせ、保守ワークフローには再起動権限を持たせることができます。サービスは同じでも、実行できる操作は異なります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

委任によって、より小さなケイパビリティをサブタスクに渡せる

ケイパビリティシステムは、権限を作業とともに渡せるため、エージェントの分割に適しています。親エージェントは、マスター認証情報を転送するのではなく、各ヘルパーに必要なものだけを委任できます。

Cap'n Protoは、オブジェクトを呼び出す権限も伝える参照としてRPC参照をモデル化しています。参照を渡すことは、特定の能力を渡すことです。Cap’n Proto RPCは、オブジェクト参照を他のコンポーネントに渡せるケイパビリティとして扱っており、委任された権限の有用なモデルをCap’n Protoオブジェクトケイパビリティで示しています。

1つのログディレクトリを検査するよう依頼されたヘルパーには、そのディレクトリだけに対する読み取りケイパビリティを渡せます。プロンプトに他のリソースが記載されていても、要求しただけで権限を拡大することはできません。

ケイパビリティの仕組みとツールのスコープは異なる層にある

ツールのスコープは、エージェントのアクションをどこまで狭くするかというポリシー上の選択です。

ケイパビリティベースのアクセス制御は、その権限を表現し、実行時に強制するための仕組みです。

ZimaSpaceのホームAIエージェントのツールスコープ分析では、自律性が高まるほど、アクション、リソース、引数、認証情報のスコープを狭めるべき理由を説明しています。現在IETFで進められているエージェントトークンの権限縮小に関するドラフトでは、下流のエージェント向けに委任された権限を狭める仕組みを検討しており、権限縮小エージェントトークンのドラフトで委任の境界を示しています。

エージェントのロジックが失敗した場合でも、ケイパビリティによる強制は重要です。ZimaSpaceのツール呼び出しループの繰り返しに関する分析は、行動上の失敗と権限制限を別々に扱うべき理由を示しています。

失効とレガシーAPIは依然として実装上の境界となる

実用的なシステムでは、失われた権限を失効させ、一時的なアクセスを期限切れにし、ユーザー、ロール、ベアラートークンしか理解できないサービスと連携する方法も必要です。

seL4はケイパビリティの導出と削除の操作を提供していますが、失効の動作は周囲のアーキテクチャに依存します。cap-stdプロジェクトは、外部リソースを暗黙のグローバルではなくケイパビリティ値として公開すると同時に、レガシーAPIと失効が別々のエンジニアリング上の課題であることをcap-stdケイパビリティベースAPIで示しています。

NAS APIの周囲にケイパビリティラッパーを置いても、その強度は背後にあるゲートウェイ次第です。最終的にすべてのリクエストが制限のない管理者トークンを使うのであれば、見かけ上の細かな権限制御は、その境界の下で失われる可能性があります。