## Release notes GitLab Dedicated administrators can now lock GitLab Duo and the Duo Agent Platform (DAP) to **Always off** for selected subgroups, even while the rest of the instance stays **Off by default**. Previously, you could either disable Duo across an entire hierarchy or let every subgroup Owner decide, with no way to hard-ban some subgroups while allowing others to opt in. Now you can enforce a default-deny, per-subgroup allowlist. Mark specific subgroups as **Always off (locked)** so their descendants can never enable Duo/DAP, while leaving other subgroups Owner-controllable. Only administrators can apply or remove the lock, and affected Owners see clear messaging that Duo is locked by an ancestor. This helps compliance and platform governance teams meet strict data-classification requirements. (insert image here) https://docs.gitlab.com/ee/#amazing > **Note:** The source of truth for this release note has moved to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/244246. Edit the MR directly to make changes. --- <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=595666) </details> ### Summary For GitLab Dedicated, we need the ability for **instance admins to mark specific subgroups as permanently “Always off (locked)” for GitLab Duo / Duo Agent Platform (DAP)**, while keeping the rest of the instance **Off by default but owner‑controllable**. Concretely: * The **instance** should be configured as **Off by default** for Duo/DAP. * For a **chosen set of subgroups**, instance admins must be able to enforce **Always off (non‑overrideable)** so that local Owners can never enable Duo/DAP there. * For **all other subgroups**, Duo/DAP should remain **Off by default**, but **subgroup/project Owners can still decide to turn Duo on/off** for their own scope. --- ### Desired access-control model The customer’s requirements: 1. **Owners can control if their repo’s data can be used by AI (where Duo can access data)** * By default, subgroup / project Owners should be able to decide whether their group/project can interact with AI by toggling Duo availability, based on their data sensitivity. 2. **Default‑off posture across the platform** * At the Dedicated instance level, Duo/DAP should be **Off by default**, so all groups/subgroups/projects start with AI disabled until explicitly enabled. 3. **Admin‑only “Never allow AI here” for selected subgroups** * Central platform admins must be able to designate specific agency subgroups as **permanently disabled for Duo/DAP**, such that all descendant groups and projects remain **AI-disabled**, and **local subgroup/project Owners are unable to change this state**. This “Always off (locked)” configuration must be **settable and removable only by instance administrators**. 4. **Mixed behavior under the same parent** * Under the same instance (or top‑level group), we need to support a mix of: * Subgroups that are **permanently Always off (admin‑locked)**, and * Subgroups that are **Off by default but owner‑controllable**, where the subgroup Owners can choose to turn Duo/DAP on or off. 5. **Central override / emergency control:** * Instance admins can override Requirement 1 for specific subtrees when needed (e.g., policy change, incident response). --- ### Current behavior (Dedicated) On GitLab Dedicated today: * Instance admins can set **GitLab Duo availability** at instance level to: * **On by default** * **Off by default** * **Always off** (kill switch, non-overrideable) * At group / subgroup / project level, **Owners can set Duo availability** to: * **On by default** * **Off by default** * **Always off** * If a **parent** namespace is set to **Always off** (with locking), **all descendants inherit that and cannot enable Duo**. * If the **instance** is set to **Off by default**, then each subgroup/project Owner can still decide to turn Duo on or off in their scope. In practice: * **Instance = Off by default** * Pros: default‑deny posture is achieved. * Cons: _all_ subgroup Owners can still turn Duo/DAP **on** in their own namespace and there is no way to “hard‑ban” some subgroups while allowing others to opt in. * **Instance (or parent group) = Always off** * Pros: complete kill switch for the entire subtree. * Cons: you cannot then **whitelist specific child subgroups**; everything under that parent stays off. What is **not possible today**: * Instance at **Off by default**, and * Under that instance: * **Subgroup A** → Always off (locked, non‑overrideable by local Owners) * **Subgroup B** → Off by default, but local Owners may turn Duo on/off * **Subgroup C** → Off by default, but local Owners may turn Duo on/off In short, you can lock an entire hierarchy, or let everyone under a parent choose, but you cannot **lock some subtrees and let others be owner‑controlled** under the same parent. --- ### Problem to solve For this Dedicated public-sector customer: * The central platform team must enforce that **certain agencies can never use DAP** (e.g., due to data classification rules). * Other agencies are allowed to **opt in** to DAP, but from a **default-off** stance. * They must do this **without giving agency subgroup Owners the power** to: * Enable Duo/DAP in namespaces that should be permanently banned, or * Disable Duo/DAP in namespaces where central governance requires AI to be available (see related FR: [ https://gitlab.com/gitlab-org/gitlab/-/work_items/594735](https://gitlab.com/gitlab-org/gitlab/-/work_items/594735)). This misalignment between Duo/DAP availability controls and the required governance model is currently a **key blocker to adopting DAP on Dedicated** (amongst other obstacles such as not having a Dedicated-hosted AI Gateway, BYOM for Dedicated not being ready). --- ### Requested change **High‑level ask** Add support for **per‑namespace “Always off (locked)” that can be applied selectively under an instance that is configured Off by default**, such that: 1. **Instance‑level configuration** * Instance Duo availability is set to **Off by default** (default‑deny posture). 2. **Per‑subgroup “Always off (locked)”** * Instance admins (or root group Owners) can mark **individual groups/subgroups** as: * **Always off (locked)** – Duo/DAP is permanently disabled for that subtree; subgroup/project Owners **cannot enable Duo/DAP** there. * This “locked Always off” should be **admin‑only**: * Only instance admins (or a clearly defined admin role) can apply/remove it. * Subgroup Owners cannot change it back to Off by default or On by default. 3. **Owner‑controllable subgroups elsewhere** * Other subgroups under the same parent remain: * **Off by default but owner‑controllable**, so their Owners can choose to enable Duo/DAP if allowed by central policy. 4. **Compatibility with existing controls** * This per‑subgroup “Always off (locked)” should integrate coherently with: * Existing **Duo availability** semantics and cascading logic. * **Member access** and seat assignment (which control who can invoke Duo/DAP). * At a high level: * **Duo availability** (with the new locked state) answers **“where can AI access data?”** * **Member access / seats** answer **“who is allowed to invoke AI?”** --- ### Relationship to existing work This request is closely related to, but not fully solved by: * **Add ‘Always on’ GitLab Duo availability mode that group Owners cannot override** * https://gitlab.com/gitlab-org/gitlab/-/work_items/594735 * That issue introduces an **“Always on (locked)”** mode for namespaces. * The present request is the **symmetric “Always off (locked)” capability at per‑subgroup granularity under an Off by default instance**, with an explicit Dedicated, multi‑tenant governance use case. --- ### Acceptance criteria (proposed) From a Dedicated admin’s point of view: * I can set Duo availability at the **instance** to **Off by default**. * For any given subgroup: * I can mark it as **Always off (locked, admin‑only)** such that: * Its descendants cannot enable Duo/DAP. * Subgroup/project Owners see that Duo is disabled and locked by an ancestor, with clear messaging. * Or I can leave it as **Off by default**, where its local Owners can decide to enable/disable Duo/DAP. * I can mix: * **Some subgroups** that are locked Always off, and * **Other subgroups** that are default‑off but owner‑controllable, under the same instance (or parent group). * The behavior is consistent on **GitLab Dedicated** and is clearly documented for admins and subgroup Owners. This would allow Dedicated customers to adopt a **default‑deny, per‑subgroup whitelist** strategy for Duo/DAP, while ensuring that certain tenants (agencies) can be **hard‑banned from AI usage at the namespace level** in a way that local Owners cannot override. *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> > [!important] > This page may contain information related to upcoming products, features and functionality. > It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. > Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->