正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

複合アイデンティティ

複合アイデンティティは、次の2つのアイデンティティを1つのトークンに結合する認証および認可のメカニズムです:

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

コンポジットIDは、GitLab Duo Agent Platformに自動的に含まれます。

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

複合アイデンティティが重要な理由

複合アイデンティティが重要なのは、次のことを確実に実現できるからです:

  • トレーサビリティ: すべてのエージェントのアクティビティはサービスアカウントに明確に帰属するため、監査ログとコミット履歴において自動化されたアクションを容易に識別できます。
  • セキュリティ: エージェントは、サービスアカウントとトリガー元のユーザーの両方に実行が許可されているアクションのみを実行できます。この共通部分に限定されたアクセスにより、特権エスカレーションを防止します。
  • 責任: 人間のユーザーのアイデンティティがトークンに埋め込まれることで、エージェントのアクションから、それをトリガーしたユーザーまで遡れる監査証跡が作成されます。

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

複合アイデンティティを使用する場面

複合アイデンティティは、フローとエージェントがRunner上で実行される場合に使用されます。該当するのは、次のような場面です:

  • 基本フロー。
  • カスタムフロー。
  • 外部エージェント。
  • エンドポイントapi/v4/ai/duo_workflows/workflowsを通じて開始されるすべてのフロー。

コンポジットIDは、UIおよびIDE内のGitLab Duo Agentic Chatには適用されません。

複合アイデンティティの仕組み

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

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

このコンポジットIDにより、GitLab Duo Agent Platformによって作成されたすべてのアクティビティが人間ユーザーに帰属されることが保証され、同時に人間ユーザーまたはサービスアカウントによる権限昇格が防止されます。

複合アイデンティティのワークフロー

複合アイデンティティはワークフローの一部です。

  1. AIカタログでフローを作成します。
    • 複合アイデンティティに関連する変更はありません。
  2. プロジェクトのフローを有効にします。
    • トップレベルグループにサービスアカウントが作成されます。（名前はai-flowname-groupnameのようになります）。
    • デベロッパーロールが付与されたサービスアカウントが、プロジェクトに追加されます。
  3. ユーザーがフローを実行します。

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

    • フローは、次の両方の条件を満たすすべてのプロジェクトにアクセスできます:

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

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

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

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

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

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

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

フローがマージリクエストを作成すると、そのマージリクエストはサービスアカウントではなく、フローをトリガーした人間ユーザーに帰属されます。これは、職務分掌を必要とするコンプライアンスフレームワーク（以下を含む）に準拠するために行われます:

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

これらのフレームワークでは通常、同一のユーザーがコード変更を作成し、本番環境へのデプロイに向けてその変更を承認することはできないとされています。

帰属モデルについて

サービスアカウントがコミットを作成してマージリクエストをオープンしたとしても、次の理由により、人間のユーザーが作成者と見なされます:

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