Remove tool approval settings check, default to ask

What does this MR do and why?

Closes #605706.

When a namespace has no ai_tool_rules configured, the effective tool-approval default resolved to Always Allow for every category, including Write and Destroy. Registry.default_permission_for coupled the fallback to the tool_approval_for_session_availability setting, whose default (:default_off) resolves to allow. As flagged in the AppSec review, a namespace with no rules could therefore run Write/Destroy tools without an approval prompt (a fail-open default).

This MR makes the no-rule default a pure function of the privilege group:

• Only read-only GitLab reads (read_only_gitlab) default to allow — this is data the user already has access to.
• Everything else defaults to ask: read-only file tools (read_only_files: read_file, grep, list_dir, …) and every Write and Destroy group. Nothing runs without a human prompt unless it only reads GitLab data (principle of least privilege).

DEFAULT_PREAPPROVED_GROUPS is now an explicit read-only allowlist (%i[read_only_gitlab]) instead of being derived from the pre_approved_agent_privileges column default ({1,2} = read_write_files + read_only_gitlab). The namespace argument is dropped from default_permission_for (the default no longer depends on namespace settings), and ResolutionService resolves the fallback per privilege group.

Least privilege for local file reads: read-only file tools access the local filesystem (which can expose local secrets/source), so they default to ask rather than allow, unlike read-only GitLab reads.

References

• AppSec review finding: gitlab-com/gl-security/product-security/appsec/appsec-reviews#301
• Epic: &20466

Screenshots or screen recordings

No UI changes to the page itself. The recording below shows the effect on the existing GitLab Duo → Governance → Tool management page — before (master): Write/Destroy tools show Always allow; after (this MR): they show Always ask. Read-only GitLab tools stay Always allow; read-only file tools now default to Always ask.

Before/after recording: 📹 (attaching)

How to set up and validate locally

The governance page is gated on a SaaS instance with a valid GitLab Duo subscription, so on a local GDK:

1. Simulate SaaS: add export GITLAB_SIMULATE_SAAS=1 to <gdk-root>/env.runit, then gdk restart.

2. Give a top-level group a Duo add-on + license — for example rake "gitlab:duo:setup[duo_enterprise]" seeds the gitlab-duo group with the add-on, subscription, and usage quotas.

3. Enable the feature flag for that group:

   Feature.enable(:gitlab_duo_governance_settings, Group.find_by_full_path('gitlab-duo'))

Use a top-level group with no ai_tool_rules so the table shows the defaults.

Open Group → Settings → GitLab Duo → Governance → Tool management (/groups/<group>/-/settings/gitlab_duo/governance), filter by Action, and confirm the default (no-rule) values:

Action	Example tools	Expected with this MR
Read (GitLab)	list_issues, get_issue	Always allow
Read (files)	read_file, grep, list_dir	Always ask
Write	create_issue, edit_file, run_tests	Always ask
Destroy	run_command, run_git_command	Always ask

Before this change, the same Write and Destroy tools showed Always allow (notably read_write_files — edit_file, mkdir, run_tests — was still auto-approved via the {1,2} column default).

Quick backend check (no SaaS setup needed)

In the Rails console, on a group with no rules:

Ai::ToolRules::Registry.default_permission_for(tool_name: 'list_issues') # => "allow" (read-only GitLab)
Ai::ToolRules::Registry.default_permission_for(tool_name: 'read_file')   # => "ask"   (read-only files, local FS)
Ai::ToolRules::Registry.default_permission_for(tool_name: 'run_command') # => "ask"   (destroy)

group = Group.find_by_full_path('gitlab-duo')
payload = Ai::ToolRules::ResolutionService.new(namespace: group, surface: :web).execute.payload
payload[:pre_approved_agent_privileges] # => [READ_ONLY_GITLAB, START_FLOWS]
payload[:denied_tools]                  # => []

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.