EPFLとSwisscomの共同プロジェクトであるCAPMASは、macaroonを介して、AIの子エージェントに限定的なスコープの権限を付与することを可能にします。これにより、トークン処理のレイテンシを30分の1に削減し、ユーザーのフル権限を持つJWTがエージェントの手に渡らないようにします。

なぜこの変更が重要なのか

LLMがダウンストリームのツールをオーケストレーションする際、チームは生成された「子」エージェントに対して、ユーザーがログインに使用したものと同じJWTを渡してしまうことがよくあります。JWTは、ユーザーが保持するすべての権限（人事データ、プロジェクトファイル、管理者権限など）をリスト化した署名付きのデータ塊です。もしモデルがハルシネーション（幻覚）によって破壊的なコマンドを生成した場合、子エージェントはユーザーの全権限を用いてそれを実行できてしまいます。たった一つのミスが、組織全体のデータ流出につながる可能性があります。

現在の回避策の欠点

RFC 8693のトークン交換フローを使用して、オンデマンドで限定的なトークンを発行すると、IAMシステムへのラウンドトリップが増え、ネットワークトラフィックが増大し、顕著なレイテンシが発生します。多数の短命なエージェントを立ち上げるチームにとって、このオーバーヘッドは致命的なものとなります。

CAPMASの仕組み

CAPMASは、権限付与を2つのステージに分割します：

  1. IAM側でのエンコーディング – IAMサービスがエンコーダーを実行し、自然言語のリクエスト（例：「financeフォルダ内のファイルをリストアップする」）を、一致する一連の特権に変換します。
  2. Macaroonの作成 – これらの特権は、macaroon内のcaveats（制約事項）となります。macaroonは柔軟なトークン形式であり、ダウンストリームのエージェントがさらなる制限を追加することはできますが、既存の制限を削除することはできません。

エージェントがmacaroonを受け取ると、そのスコープをさらに絞り込むこと（例：ファイルリストのリクエストを特定のサブディレクトリのみに制限するなど）はできますが、広げることはできません。各ホップにおいて、IAMサービスはすべてのcaveatsの積集合を検証し、どのエージェントも元の許可範囲を超えないことを保証します。

自明なパフォーマンス数値

  • 速度 – CAPMASは権限リクエストを20ミリ秒未満で処理し、これはRFC 8693による交換よりも約30倍高速です。
  • 精度 – 大規模なツールカタログを用いたベンチマークでは、標準的なLLMは必要な特権の53%を見逃しました。一方、CAPMASはミス率わずか2.1%で、90.9%の精度を達成しました。
  • 帯域幅 – macaroonは最終的なcaveatsのセットのみを保持するため、交換されるデータ量は、フル・トークン交換フローが必要とする量のわずか一部で済みます。

実用的な導入ワークフロー

  1. リクエストの事前フィルタリング – オーケストレーターがツールカタログに触れる前に、ユーザーの自然言語による意図をtop-kの許可リスト（allowlist）に変換します。
  2. 許可リストの封印 – その許可リストを、子エージェントが拡張できないようなmacaroonにエンコードします。
  3. サービスでの検証 – リクエストを承認する前に、対象のサービスがIAMに対してすべてのcaveatsの積集合を計算するよう要求します。

これらのステップにより、「子に家の鍵を丸ごと渡す」パターンから、「使い捨ての限定的なスコープの鍵を渡す」モデルへと置き換えることができます。

CAPMASで解決できないこと

このフレームワークは、攻撃者がLLMのプロンプトを操作して悪意のあるコマンドを注入する「プロンプトインジェクション攻撃」を防ぐものではありません。その保護対象は、悪意はないが好奇心旺盛な（honest-but-curious）エージェントや、フルJWTに基づいて動作してしまう可能性のある信頼できないLLMです。プロンプトベースの脅威に対処するには、入力のサニタイズ、サンドボックス化、モデルレベルのガードレールなど、別途防御策を講じる必要があります。

恩恵を受ける対象

  • エンタープライズ開発者 – 内部APIを呼び出すAI駆動型アシスタントを構築している開発者。
  • セキュリティチーム – モデルが侵害された際の被害範囲（blast radius）を縮小したいチーム。
  • プロダクトオーナー – 高頻度でエージェントを立ち上げる際に、高速で信頼性の高い権限チェックを必要とする担当者。

今後の展望

CAPMASは提案段階のデザインです。

要点: フルユーザーJWTを限定的なスコープのmacaroonに置き換えることで、開発者は従来のトークン交換フローによるレイテンシのペナルティを支払うことなく、AIエージェントの誠実さを保つ手段を得られます。ただし、プロンプトインジェクション対策の継続的な必要性というトレードオフは残ります。