## Summary Currently, operations involving agents, flows, and triggers require top-level group (TLG) owner permissions when using service accounts. This creates significant friction for customers, particularly at scale: - Trigger creation requires TLG ownership, preventing service accounts from being reused across projects - Large enterprise customers could potentially require hundreds or thousands of service accounts since they are unique per project - Service accounts require elevated permissions beyond what is required for these functions - This becomes a bottleneck for adoption ### Goal Reduce permission barriers for common agent and flow operations. Users should be able to perform routine tasks like trigger creation, agent enablement, and flow enablement without requiring top-level group ownership. **Operations in scope:** - Trigger creation - Agent enablement - Flow enablement ### Additional Reference - Product has [confirmed](https://gitlab.slack.com/archives/C08T5J1KXKQ/p1770400516965599?thread_ts=1770239615.219649&cid=C08T5J1KXKQ) that the default minimum role for enabling an agent/flow/trigger at the project level should be Maintainer (of the project) - In a separate workstream, the security team is working on a Governance package that will be available to customers who want to create policies and HITL checks around agent/flow workflows, so reducing oversight with this change is acceptable. However, this solution must be flexible to scale to the needs of the governance features to come. [epic reference](https://gitlab.com/groups/gitlab-org/-/work_items/20278) - Security has [approved](https://gitlab.com/groups/gitlab-org/-/epics/20229#note_3034626405) the use of a project-level service account with the new feature being tracking in [this issue](https://gitlab.com/groups/gitlab-org/-/work_items/20438). ## Success criteria - [ ] Users can create triggers for agents and flows without requiring top-level group ownership - [ ] Users can enable agents in their projects without requiring top-level group ownership - [ ] Users can enable flows in their projects without requiring top-level group ownership - [ ] Solution maintains appropriate security controls and doesn't introduce new vulnerabilities - [ ] Permission model is clear and understandable to users and admins