feat(tools): Approve off by default and respect a tiered settings system
What does this MR do and why?
Resolves: [DAP] Introduce tiered settings system with app... (#596366 - closed)
This merge request modifies how GitLab handles tool approval settings for AI-powered Duo Workflow sessions. The main changes include:
Database Changes: Adds a new setting column to project settings and changes the default behavior from requiring approval (true) to not requiring approval (false) for new installations.
Enhanced Configuration: Replaces a simple on/off toggle with a three-state system that allows administrators to set tool approval as "default on", "default off", or "never allowed" at different organizational levels (instance, group, and project).
Improved Scope Handling: Updates the system to better determine which approval settings apply by considering the most specific context - checking project settings first, then group settings, rather than always using the top-level organization settings.
API Updates: Modifies the GraphQL and REST APIs to support the new three-state approval system and adds project-level configuration options.
User Interface: Updates the settings interface to show the current approval state and whether it's locked by higher-level administrators.
The overall effect is giving administrators more granular control over when AI tools require user approval before executing actions, with better inheritance of settings from organization to group to project levels.
Migration note
The migration only changes the column default, it does not update any existing rows. This feature has not yet been deployed to production, so there are no existing admin configurations or data affected by this change. The migration is fully reversible.
References
Screenshots or screen recordings
| Location | After |
|---|---|
| Dropdown closed | ![]() |
| Dropdown selector | ![]() |
| Top level group blocks feature | / ![]() |
| Project level toggle | ![]() |
| Top level group blocks project level toggle | ![]() |
How to set up and validate locally
Since this MR is split into a backend MR (this one) and a frontend MR: feat(dap): Enable tool approval toggle setting ... (!228511 - merged), it's a bit harder to test.
Locally, I have been using a master branch for this feature that I push and pull updates from for testing. That would be the best way to run this locally:
- Check out the fullstack branch:
db/approve-tool-setting-fullstack - Test changing settings on group/namespace Duo configuration pages
- Build out this feature to the editor extensions and confirm that the
Approve for Sessionfeature is disabled when the settings reflect that state. - Ensure that
Default offis the default when opening a new namespace/group where the top level group has not altered the setting
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.





