複合アイデンティティ

コンポジットIDとは、2つのIDを1つのトークンに結合する認証および認可メカニズムです:

• サービスアカウント。実際のアクションを実行するマシンユーザー。
• 人間のユーザー。リクエストを開始した人。

この二重IDアプローチは、重大な課題を解決します。エージェントは、エージェントをトリガーしたユーザーのアクセス権、またはサービスアカウントに付与されたアクセス権を超えない範囲でアクションを実行する必要があり、同時に、アクションが人間のユーザーによって直接ではなく、エージェントによって実行されたことを明確に示すために、明確なIDを維持する必要があります。

コンポジットIDが重要な理由

コンポジットIDが重要なのは、以下のことを保証するのに役立つためです:

• 追跡可能性: すべてのエージェントのアクティビティーはサービスアカウントに明確に帰属するため、監査ログとコミット履歴で自動化されたアクションを簡単に識別できます。
• セキュリティ: エージェントは、サービスアカウントとトリガーユーザーのみがアクセスできるアクションを実行できます。この交差的なアクセスにより、特権エスカレーションが防止されます。
• アカウンタビリティ: 人間のユーザーのIDはトークンに埋め込まれ、エージェントのアクションをそれらをトリガーした人に結び付ける監査証跡を作成します。

たとえば、エージェントにコードのテストの作成を依頼すると、結果として得られるコミットは、サービスアカウントによってユーザーに代わって作成されたことを示します。

コンポジットIDの使用場所

コンポジットIDは、ワークフローとエージェントがRunnerで実行される場合に使用されます。このリストには以下が含まれます:

• Foundationalワークフロー。
• カスタムワークフロー。
• 外部エージェント。
• エンドポイントapi/v4/ai/duo_workflows/workflowsを介して開始されたすべてのワークフロー。

コンポジットIDは、UIおよびIDEのGitLab Duo Chat（エージェント）には適用されません。

コンポジットIDの仕組み

リクエストを認証するトークンは、次の2つのアイデンティティを組み合わせたものです:

• プライマリオ作成者: トークンのオーナーであり、デベロッパーロールを持つサービスアカウント。
• セカンダリ作成者: エージェントまたはワークフローを開始した人間のユーザー。人間のユーザーのidIDは、動的スコープを使用してトークンのスコープに含まれています。

このコンポジットIDにより、GitLab Duo Agent Platformによって作成されたすべてのアクティビティーは、サービスアカウントに正しく帰属され、人間のユーザーまたはサービスアカウントによる特権エスカレーションを防止できます。

コンポジットIDワークフロー

コンポジットIDはワークフローの一部です。

1. AIカタログでワークフローを作成します。
   • コンポジットIDに関連する変更は発生しません。
2. トップレベルグループのワークフローを有効にします。
   • 有効にするには、オーナーである必要があります。
   • サービスアカウントがトップレベルグループに作成されます。（名前はai-flowname-groupnameに似ています）。
3. プロジェクトのワークフローを有効にします。
   • ワークフローは、トップレベルグループで有効になっている必要があります。
   • プロジェクトで有効にするには、メンテナーである必要があります。
   • サービスアカウントがデベロッパーロールでプロジェクトに追加されます。
4. ユーザーがワークフローを実行します。

   • ワークフローは、1回限りのコンポジットIDによって実行されます。このIDには、ユーザーのロールとサービスアカウントのデベロッパーロールの組み合わせがあり、どちらか制限の厳しい方が使用されます。そのため、ユーザーがメンテナーであっても、サービスアカウントがデベロッパーである場合は、デベロッパーロールが使用されます。

   • ワークフローは、次の両方のプロジェクトにアクセスできます:

     • ユーザーがアクセスできる。
     • サービスアカウントが追加された。

     たとえば、サービスアカウントが他のプロジェクトに追加され、ユーザーがそれらのプロジェクトにアクセスできる場合、ユーザーが以前にそこでワークフローを使用したことがなくても、ワークフローはそれらのプロジェクトにアクセスできます。

AIカタログワークフローのトークン権限

AIカタログワークフローは、異なる権限スコープを持つ異なるトークンタイプを使用します:

• AIワークフローでコンポジットIDに使用されるOAuthトークンは、ai_workflowsおよびmcpスコープへのアクセスが制限されています。このOAuthトークンは、AIゲートウェイに渡されてワークフローを実行します。
• ワークフローの一部としてトリガーされるCIジョブトークンは、利用可能なジョブトークン権限によって権限がさらに制限されます。

これらは異なるスコープを持つ異なるトークンタイプであるため、CI/CDジョブにはOAuthトークンとは異なる権限があります。

マージリクエストのコンプライアンスに関する考慮事項

ワークフローがマージリクエストを作成すると、マージリクエストは、ワークフローをトリガーした人間のユーザーではなく、サービスアカウントに帰属します。この帰属モデルは、以下を含む、職務分掌を必要とするコンプライアンスフレームワークと矛盾する可能性があります:

• SOC 2（システムおよび組織管理2）
• SOX（サーベンスオクスリー法）
• ISO 27001（情報セキュリティ管理）
• FedRAMP（米国連邦情報セキュリティ管理プログラム）

これらのコンプライアンスフレームワークでは通常、ユーザーがコードの変更を作成し、本番環境へのデプロイのためにそれらの変更を承認できないことが必要です。

帰属モデルについて

サービスアカウントがコミットを作成してマージリクエストを開いたとしても、人間のユーザーが作成者と見なされる理由は次のとおりです:

• 人間のユーザーがサービスアカウントに変更の作成を指示した。
• コンプライアンスの観点からは、AIシステムにコードの作成をプロンプトすることは、自分でコードを記述することと同じです。
• サービスアカウントは、人間のユーザーの意図のプロキシとして機能します。

コンプライアンス要件の対象となる組織は、マージリクエストを作成するFoundationalワークフローをオフにする必要があります。