:robot: Note: This was raised with the assistance of GitLab Duo :robot: ## Summary Several GitLab Duo security governance settings — **[Prompt injection protection](https://docs.gitlab.com/user/duo_agent_platform/security_threats/#detect-prompt-injection-attempts)** and the **[Agent Platform network access allowlist/denylist](https://docs.gitlab.com/user/duo_agent_platform/environment_sandbox/#configure-network-access-controls-for-your-instance-or-group)** — do not cascade down the group hierarchy. Each group holds its own independent value, and nothing set on a parent group is ever inherited by its subgroups or their projects. More specifically, settings stored on `Ai::NamespaceSetting` (`namespace_ai_settings` table) are per-namespace records with no inheritance. Setting a value on a group has no effect on its descendant groups, even though the settings UI offers these controls on subgroups as well, which implies they apply downward. Affected fields include: - `prompt_injection_protection_level` - `allowed_domains` / `denied_domains` (Agent Platform network access) ## Steps to reproduce Prerequisites: the `ai_prompt_scanning` feature flag enabled for the acting user, the Owner role (`admin_duo_workflow`) on the groups, and an active Duo subscription. 1. Create a group hierarchy: `parent/child` (both nested under a top-level group, so both render the setting). 1. On `parent`, set **Prompt injection protection** to **Interrupt**: - Subgroups: **Settings > General**, GitLab Duo section, under **Data privacy**. - Top-level groups on GitLab.com: **Settings > GitLab Duo > Configuration** (`_ai_settings.html.haml` excludes root .com groups from General settings). 1. Run a Duo Agent Platform session in the context of `child` (or a project under it). 1. Compare `parent.prompt_injection_protection_level` and `child.prompt_injection_protection_level` (e.g. via the group REST API `ai_settings`). ## Steps to reproduce Prerequisites: the `ai_prompt_scanning` feature flag enabled for the acting user, the Owner role (`admin_duo_workflow`) on the groups, and an active Duo subscription. 1. Create a group hierarchy: `parent/child` (both nested under a top-level group, so both render the setting). 1. On `parent`, set **Prompt injection protection** to **Interrupt**: - Subgroups: **Settings > General**, GitLab Duo section, under **Data privacy**. - Top-level groups on GitLab.com: **Settings > GitLab Duo > Configuration** ([`_ai_settings.html.haml#L3`](https://gitlab.com/gitlab-org/gitlab/-/blob/e10463251c9bfe089caa42985e36fb0a6ab3c17d/ee/app/views/groups/settings/ai/_ai_settings.html.haml#L3) excludes root .com groups from General settings). 1. Run a Duo Agent Platform session in the context of `child` (or a project under it). 1. Compare `parent.prompt_injection_protection_level` and `child.prompt_injection_protection_level` (e.g. via the group REST API `ai_settings`). ## Current behavior When you set Prompt injection protection (or network access rules) on a group, the setting only applies to that group itself. Its subgroups and their projects don't pick it up — each one uses its own setting, or the default (_Log only_) if it was never configured. So a Duo session running in a subgroup ignores what the parent group configured, and there's no warning that this is happening. The only workaround is to manually set the same value on every group that contains projects, including any created later. The value written to `parent` is stored only on `parent`'s `namespace_ai_settings` row. Every reader — `Namespace#prompt_injection_protection_level`, the GraphQL `Namespace.aiSettings` field, the REST `ai_settings` entity — returns the queried namespace's own record (or the `log_only` default when no record exists, [`ai/namespace_setting.rb#L10-14`](https://gitlab.com/gitlab-org/gitlab/-/blob/e10463251c9bfe089caa42985e36fb0a6ab3c17d/ee/app/models/ai/namespace_setting.rb#L10-14)), with no ancestor fallback. A descendant group's effective value therefore never reflects the parent's setting. The same applies to the network access allowlist/denylist. Confirmed enforcement behavior: the Duo Workflow Service reads the level from the **project's direct parent namespace** (for project-based sessions) or the **workflow's own namespace** (for namespace-level sessions), defaulting to `log_only` when absent — see [`duo_workflow_service/gitlab/gitlab_api.py#L143-151`](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/ad875a8f34e0ec8e6163a1fed423494a55b790d5/duo_workflow_service/gitlab/gitlab_api.py#L143-151) (`project_data.get("namespace").get("aiSettings") or namespace_data.get("aiSettings")`). So a session in a project under `parent/child` uses `child`'s own setting; `parent`'s **Interrupt** value is never consulted. The only workaround is to set the value on every group that directly contains projects (and every namespace where namespace-level sessions run), and repeat for each newly created group. ## Expected behavior A protection level or network boundary set on a group applies to its entire sub-hierarchy, consistent with how other Duo settings (e.g. `duo_features_enabled`) cascade. These are security guardrails; per product direction (&20729, internal), they should be enforcement cascades that descendants cannot silently escape. ## Root cause - `Ai::NamespaceSetting` ([`ee/app/models/ai/namespace_setting.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/e10463251c9bfe089caa42985e36fb0a6ab3c17d/ee/app/models/ai/namespace_setting.rb)) is a plain one-row-per-namespace model. It is not integrated with the cascading namespace settings framework ([`cascading_namespace_setting_attribute.rb#L22`](https://gitlab.com/gitlab-org/gitlab/-/blob/e10463251c9bfe089caa42985e36fb0a6ab3c17d/app/models/concerns/cascading_namespace_setting_attribute.rb#L22)): no lock columns and no ancestor-walk resolution. - `Ai::CascadeDuoSettingsService` only cascades its `DUO_SETTINGS` allowlist ([`cascade_duo_settings_service.rb#L6-18`](https://gitlab.com/gitlab-org/gitlab/-/blob/e10463251c9bfe089caa42985e36fb0a6ab3c17d/ee/app/services/ai/cascade_duo_settings_service.rb#L6-18)), which contains exclusively `NamespaceSetting`/`ProjectSetting` columns — no `Ai::NamespaceSetting` field is in it. - `Namespace` delegates the readers directly to its own `ai_settings` record ([`ee/app/models/ee/namespace.rb#L238-245`](https://gitlab.com/gitlab-org/gitlab/-/blob/e10463251c9bfe089caa42985e36fb0a6ab3c17d/ee/app/models/ee/namespace.rb#L238-245) and, for `allowed_domains`/`denied_domains`, [`#L247-252`](https://gitlab.com/gitlab-org/gitlab/-/blob/e10463251c9bfe089caa42985e36fb0a6ab3c17d/ee/app/models/ee/namespace.rb#L247-252)), so resolution never consults ancestors. - The settings UI renders the prompt injection control on any group (including subgroups) where the `ai_prompt_scanning` feature flag is enabled for the user and the user has `admin_duo_workflow` ([`settings_helper.rb#L170-171`](https://gitlab.com/gitlab-org/gitlab/-/blob/e10463251c9bfe089caa42985e36fb0a6ab3c17d/ee/app/helpers/ee/groups/settings_helper.rb#L170-171)), creating the expectation of inheritance. The network access controls render for subgroups as well. ## Proposed direction Decide on one consistent model for `Ai::NamespaceSetting` fields, for example: 1. Integrate them with the cascading settings framework (inherit-with-override plus lock columns), or 1. Resolve the effective value by walking ancestors at read time (most restrictive wins for security fields), or 1. Restrict these settings to top-level groups only (as already done for `web_search_enabled` and `ai_catalog_restricted_to_group_hierarchy` via model validations) so the UI matches the actual scope. Options 1 and 2 preserve mid-hierarchy control; option 3 is the smallest fix but removes subgroup-level configuration. ## Related - #607615 (closed Won't do) — the availability-cascading consolidation issue; the closing discussion identified "settings outside the cascading framework" as the remaining gap. This issue is that gap for `Ai::NamespaceSetting`. - #591889 — same pattern for flow execution settings. - &22346 — Prompt Injection Protection for DAP (feature epic). - gitlab-org/ai-powered/custom-models/custom-models#168 — audit of Duo settings and their cascade behavior.