Permissions model suggestion for DAP

Summary

This issue proposes a permissions model for GitLab Duo Automate to control access to agents and flows across projects and groups. Based on discussions from the DAP sync meeting on Oct 23, 2025, we need to establish clear permissions for Show, Manage (Create, Duplicate, Edit, Delete), and Run actions.

Background

Currently, we have an initial permissions structure in place, but several aspects need further discussion and refinement, particularly around:

  • Whether permissions should be more granular and configurable
  • The appropriate role levels for each action

Current Permissions Overview

Action Current roles Limitation Configurable Reasonable Reasonable for
New Logged-in+ No project/group context ❌ - -
Create Maintainer+ - ✅ Association could be controllable
❌ If creating means enabling		 ✅ Guest+
Show Public: Logged-in+
Private: ?		 - ✅ ✅ Guest+
Duplicate Public: Logged-in+
Private: ?		 Same as create ✅ ✅ Guest+
Edit Maintainer+ - ✅ ✅ Guest+
Delete Maintainer+ - ✅ ✅ Guest+
Publish Maintainer+ - - - -
Enable Owner+ Owner+ ❌ - -
Run Developer+ - ✅ ✅ Guest+

Key Principles

  1. Service Account Permissions: Service accounts will be bound to the project. Flows will only have permissions at the intersection of the user executing the flow and the service account, preventing privilege escalation.
  2. Manage Action: This permission controls the association with the source project or group. Users can only create agents or flows for projects/groups where they have the required role.
  3. Enable Action: Currently limited to Owner+ because of service account implications. Enable is required to use public or own agents/flows for projects and groups.

Open Questions

  1. Association Changes: Can the association with the project and group be changed after creation?
    • Current answer: No
  2. Run Permissions: What happens if there are no permissions left after the intersection of user and service account permissions?
    • Also discussed here
  3. Enabling Automate Menu: How to enable the Automate menu for a project or group?
    • Current answer: Enable Duo
  4. Alternative Approach: Should we use a "which roles can execute a certain agent or flow?" model instead?

Proposed Priorities

Based on the discussion, the suggested priority for implementation is:

  1. Run - Most critical for functionality
  2. Manage (Create, Duplicate, Edit, Delete) - Core content management.
  3. Show - Access control for viewing.

Discussion Points

  • Should we make permissions more configurable at the project/group level?
  • How should we handle private vs. public agents/flows for Show and Duplicate actions?

Next Steps

  • Reach consensus on appropriate role levels for each action
  • Determine configurability requirements
  • Define behavior when permission intersection results in no permissions
  • Document the final permissions model
  • Create implementation issues
Edited by Lukas Wanko