Split DAP Execute permission into foreground and background execution

Problem

Based on the research and discussions in #582055 (closed), we need to split the existing Execute permission for the Duo Agent Platform (DAP) to better align with the execution models and role requirements:

  • Foreground (synchronous) execution: Runs in the foreground or locally without CI/CD pipelines, accessible to Guest+ roles
  • Background (asynchronous) execution: Runs via CI/CD pipelines, requires Developer+ roles due to pipeline limitations

Proposal

Add a new permission attribute to complement the existing minimum_access_level_execute permission:

Existing: minimum_access_level_execute (Foreground)

  • Minimum role: Guest+
  • Execution type: Synchronous/local
  • Does not consume: CI/CD compute minutes
  • Controls access to:
    • Agentic Chat (Web UI and IDE)
    • Foundational Agents (Planner, Security Analyst) via Chat
    • Custom Agents via Chat
    • Software Development Flow (IDE)

New: minimum_access_level_execute_asynchronously (Background)

  • Minimum role: Developer+
  • Execution type: Asynchronous/remote via CI/CD pipelines
  • Consumes: CI/CD compute minutes
  • Controls access to:
    • Fix CI/CD Pipeline Flow
    • Convert to GitLab CI/CD Flow
    • Issue to Merge Request Flow
    • Custom Flows (UI-triggered)
    • External Agents

Prerequisites

Before implementing this split, we need to loosen existing permissions to align foreground execution with Guest+ access:

  • #582506 - Allow Guest+ to execute foreground flows
  • #582507 - Allow Guest+ to execute custom agents in foreground (Agentic Chat)

Implementation

Model Changes

Following the pattern established in #578551 (closed), extend ai_settings and namespace_ai_settings tables:

New column to add:

  • minimum_access_level_execute_asynchronously (integer, nullable) - Access level for background execution (developer+)

Existing column:

  • minimum_access_level_execute - Will control foreground/synchronous execution (guest+)

Acceptance Criteria

  • Database migration adds minimum_access_level_execute_asynchronously column to ai_settings and namespace_ai_settings
  • Validation ensures minimum_access_level_execute_asynchronously is limited to developer+ roles
  • Validation ensure minimum_access_level_execute is limited to guest+ roles
  • Already added code for UI and API for the previous approach with only one execute permission from [Backend] Role-based permissions controls for DAP (&19743) is updated
  • Unit tests cover both permission checks.
  • Database schema documentation is updated.

Benefits

  • Granular control: Customers can control AI access and compute spending separately
  • Role alignment: Matches existing GitLab role capabilities (Guest can't trigger pipelines)
  • Cost management: Background execution permission directly relates to CI/CD minute consumption
  • Security: Maintains Developer+ requirement for pipeline-based operations

Related Issues

  • #582055 (closed) - [Spike] Split-up permission - execute background and foreground
  • #578551 (closed) - Role-based permissions DAP - Model implementation
  • Parent Epic: &19743 - [Backend] Role-based permissions controls for DAP

References

See detailed research and discussion in #582055 (closed), particularly:

Edited by 🤖 GitLab Bot 🤖