<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/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=630345) </details> <!--IssueSummary end--> Part of [Auto mode iteration 1](https://gitlab.com/groups/gitlab-org/-/epics/23670). Sibling: #630346 (receipts). ## Problem Today "auto mode" means *"ask for everything, let the server cut it down"*: the client requests every privilege group as pre-approved and Rails intersects that with governance. That works only while governance is effectively absent. Once `duo_workflow_local_tool_governance` (#613544) is on, the defaults say `ask` for everything except GitLab reads, the intersection strips auto mode back to roughly what `build` mode grants, and auto mode becomes a badge that changes nothing. This issue makes the decision itself server-side and explicit. ## The model: four inputs, three stages  The four inputs are: 1. **Built-in defaults** — GitLab reads `allow`, everything else `ask`. 2. **Admin rules** — per group and project, per tool: `allow` / `ask` / `deny`, most-restrictive wins. 3. **Auto mode** — admin consented (the `duo_auto_mode` setting) **and** the user engaged it this turn. 4. **The client's request** — which privilege groups the client is willing to run unprompted (`plan` / `build` / `auto`). In one sentence: **the admin's rule if there is one, otherwise the built-in default; auto mode may turn a *default* ask into an allow; the client can only shrink the result.** Worked through, for a CLI session in a namespace where the admin has written nothing except where the table says otherwise: | Tool call | Admin rule | Auto mode | Client mode | Verdict | Why | |---|---|---|---|---|---| | run a shell command | none | off | build | **ask** | the built-in default | | run a shell command | none | on | auto | **allow**, stamped auto mode | stage 2 promotion | | run a shell command | admin wrote "ask" | on | auto | **ask** | an explicit rule outranks auto mode | | run a shell command | admin wrote "deny" | on | auto | **deny** | nothing ever overrides a deny | | read a GitLab issue | none | off | build | **allow** | GitLab reads are the one permissive default | | edit a file | none | on | plan | **not offered at all** | plan mode never requests file edits, so the tool is absent from the session | ## The decision to confirm: which `ask` does auto mode relax? The design currently disagrees with itself. The merged settings page says auto mode lets users *"relax governance 'Always Ask' rules to 'Always Allow'"*; the [ADR draft](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/21067) says *"an admin `ask` always outranks auto mode"*. These are opposites and both are live. **Option A (preferred) — auto mode fills silence, it does not overrule.** Only a *default* `ask` is promoted; an explicit admin `ask` still prompts. The admin gets two controls and one sentence that explains them: *leave a tool unconfigured and auto mode may run it; write "ask" and it will always ask you.* It is the only version where "the admin's explicit word wins" stays true, and it mirrors a promotion the product already does: on the background surface an `ask` nobody can answer becomes an `allow`, applied only to the built-in default, never to an explicit rule. **Option B — auto mode overrules an explicit admin `ask`.** Matches the copy we already shipped and reduces prompts for everyone, but a user switching to auto mode can then undo a rule an admin deliberately wrote. If we choose B we should stop calling the rule "Always Ask", because it is not. The strongest argument against A: `ask` is the default for everything except GitLab reads, and the settings page renders that default as a pre-selected "Ask" radio. An admin who opened the page and pressed save has "explicitly written ask" without intending to, and gets an auto mode that silently does nothing. Two follow-ups remove that trap, both out of scope here: scoping consent to privilege groups (*may run file edits, never shell commands*), and giving the rulebook a fourth value meaning "ask, unless auto mode is engaged". Whichever we pick, **the shipped settings copy and the ADR have to be made to agree**, and the page should state what auto mode does *not* do. ## Proposal * Resolve the promotion in `Ai::ToolRules::ResolutionService`, taking auto-mode consent + engagement as an input, alongside the existing defaults and admin rules — one place, one precedence order. * Ship it in the **tool-name policy channel**, not the privilege-integer channel: only the former can express `ask` at all. * Send the promoted set as **its own list**, so the agent service does not have to re-derive it — and so "allowed because of auto mode" is decidable for the receipt. * The client sends one bit per turn: "auto mode is engaged". It needs no trust as a permission input, because it can only withhold the promotion. ## Acceptance criteria * [ ] Option A or B is decided, written into the ADR, and the settings copy matches. * [ ] The promotion is computed server-side, in the resolver, for local surfaces. * [ ] Governance `deny` is unaffected in every case. * [ ] An **absent or empty promotion list means promote nothing** — never a fall back to the privilege integers, never "the rulebook said nothing, so proceed". This is the version-skew case: a newer client talking to an older GitLab. * [ ] Auto mode is **inert whenever governance could not be resolved** — flag off, policy claim missing, resolution failed. Auto mode must never be more permissive in the absence of governance than in its presence, which is what happens today. * [ ] Auto mode does **not** promote a privilege group whose members the rulebook cannot enumerate (today: MCP / third-party tool servers). * [ ] Tests cover each row of the table above. ## Out of scope Reviewer-agent classification of promoted calls (#628557), IDE surfaces, argument-level rules, and the two client-side paths that can answer an `ask` without a human (hooks, remembered session approvals) — those need their own issues. <details> <summary>Why "who computes it" matters: Rails, not the agent service</summary> The [ADR draft](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/21067) proposes the agent service derive the promotion itself: auto-approve when auto mode is engaged, the admin consented, and the tool is on neither the ask nor the deny list. The problem is what "not on either list" covers. `ResolutionService` only emits **explicitly configured** tools (`explicitly_configured_tools_for_group`), so a tool sitting at the built-in default appears in none of the three lists — indistinguishable from a tool the rulebook has never heard of. And the agent service has plenty of those: its own built-in and no-op tools are seeded straight into `_preapproved_tool_names` in `tools_registry.py`, `PRIVILEGE_GROUP_MAPPING[:run_mcp_tools]` is empty on the Rails side, and locally configured MCP servers are invisible to governance entirely. "Absence means yes" is therefore fail-open. Rails can only ever name tools it knows, so a Rails-computed list is bounded by construction — and Rails is the only side that can tell an unconfigured default from an explicit rule. </details> <details> <summary>Where the decision lives today (code)</summary> * Resolver: `ee/app/services/ai/tool_rules/resolution_service.rb` — emits `agent_privileges`, `pre_approved_agent_privileges`, `pre_approved_tools`, `ask_tools`, `denied_tools`. * Defaults: `ee/lib/ai/tool_rules/registry.rb`, `DEFAULT_PREAPPROVED_GROUPS = [:read_only_gitlab]`. * The existing ask→allow precedent: `Ai::ToolRules::Permissions.background_effective`, called only from `fallback_permission`, i.e. on the default only. * Channel A (privilege integers): `CreateWorkflowService#clamp_client_privileges`, `UpdateAgentPrivilegesService`. * Channel B (tool-name lists): `Ai::DuoWorkflows::ConnectionConfigService#tool_access_policies`, signed into the JWT in `ee/lib/ai/duo_workflow/duo_workflow_service/client.rb`. * Agent service consumption: `AbstractWorkflow._merge_jwt_governance_claims`, then `ToolsRegistry` applies `_preapproved_tool_names -= _ask_tool_names` last. * Client: `packages/cli/app/src/backend/gitlab/workflow_agent_privileges.ts` (`preApprovedForMode`), capability gate in `gitlab_backend.ts`. </details> <details> <summary>Dependencies</summary> * https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253318 / #618761 — the surface re-key. Until it lands, which column of the rulebook applies is chosen by a string the client sends: a client claiming to be the web UI escapes local rules entirely. Everything here rests on it. * #611843 — an absent policy claim currently reads as "no limits". * #613544 — the governance flag rollout. This issue must land before or with the flip. </details>