AIエージェントの従来のセキュリティは、多くの場合「環境権限」に依存しています。このモデルでは、プログラムは単にその環境にあるという理由だけで権限を行使します。例えば、プロセスが特定のUnixユーザーとして実行されているためにディレクトリを読み取れたり、環境変数にトークンが存在するためにAIエージェントがGitHubリポジトリにアクセスできたりするようなケースです。これは重大なリスクを生みます。もしエージェントがプロンプトインジェクションや依存関係の脆弱性を介して侵害された場合、攻撃者はその広範な資格情報に関連付けられたすべての権限を継承してしまいます。Ederaは、すでに権限を持っているワークロードを制約しようとするのではなく、セキュリティは、ワークロードに特定のケイパビリティが明示的に付与されるまで、ワークロードに一切の権限を与えないことから始めるべきだと主張しています。
Ederaのアプローチは、オブジェクト・ケイパビリティ（OCAP）モデルに基づいています。これは「指定（どのオブジェクトと対話しているか）」と「権限（それに対して何ができるか）」を、単一の偽造不可能な参照に統合するものです。ケイパビリティ指向のシステムでは、エージェントは汎用的な資格情報を必要としません。代わりに、`github.write(repository="acme/payments")`のように、特定の操作を実行する権限を表すハンドルを保持するだけです。これは、実際の資格情報を保持する「ケイパビリティ・ブローカー」を通じて実装されます。例えば、Ederaの`capcurl`コンセプトでは、ブローカーがGitHubトークンを管理し、エージェントに対して限定的な権限を公開します。エージェントはトークンを一切目にすることなく、ブローカーはリクエストを実行する前に、許可されたパス、レート制限、または特定のHTTPメソッドなどの特定の制約を強制します。
この図は、エージェントが広範な資格情報を保持することから、ケイパビリティ・ブローカーを使用して狭い範囲のハンドルを受け取ることへの移行を説明しています。
このモデルは、AIエージェントの動作が動的であり、静的なポリシーでは予測が困難であるため、特に適しています。ケイパビリティは構成可能で粒度が細かいため、エージェントの実効的なパワーは、付与された特定の権限の合計となります。例えば、Model Context Protocol (MCP) サーバーを、インフラ全体への特権的なブリッジを与えるのではなく、特定の3つのコマンドのみに制限することができます。OCAPはアイデンティティに取って代わるものではありません。Ederaは依然としてSPIFFE/SPIREを使用してワークロードの「誰であるか」を確立していますが、よりクリーンな関心の分離を提供します。アイデンティティは主体を確立し、ケイパビリティはその主体に許可される特定の最小権限の操作を管理します。これにより、microVMがホストからの隔離を提供し、限定的な権限がそのサンドボックス内でエージェントが行える操作からの隔離を提供する、2層のセキュリティモデルが構築されます。
この視覚資料は、エージェントのパワーが「git-diff」や「restart-deployment」のような特定の権限の合計であるという、ケイパビリティの粒度を実証しています。