[FF] dap_allow_client_injected_mcp_tools -- skip the approval gate for client-supplied MCP tools

Summary

Roll out the feature currently behind the dap_allow_client_injected_mcp_tools feature flag.

Note

Process and guidance live in the docs — this issue is just the commands and a place to track the rollout. "Rolling out" means incrementally enabling the flag on GitLab.com to validate stability — it is not the same as releasing the feature, which happens when the flag is removed. Feature flag controls · Feature flag lifecycle

Prerequisites

  • The Workhorse build that stamps client_injected is deployed to the instance being enabled. An older Workhorse re-sends the start request with unknown protobuf fields preserved, so a client's own client_injected: true passes through untouched. The Duo Workflow Service refuses names GitLab owns regardless of claimed origin, and derives origin from the token issuer where nothing stamped the request, so the residual is a caller self-declaring for its own tool names — but enabling after the deploy avoids relying on that.
  • The root namespace that the affected proxy's requests resolve to is identified. The flag is checked against the root namespace, not the user, so enabling for the wrong actor has no effect.

What could go wrong?

The flag lets MCP tools supplied by the client skip the tool call approval gate. Blast radius is limited to those tools: tools from servers GitLab configured keep their approval behaviour, including admin Always ask and Always deny rules, and a client-supplied entry cannot take a name GitLab owns. An unrecognised MCP tool call is routed back to the client, so execution stays in the caller's environment. No data-loss risk.

Removal is tracked by https://gitlab.com/gitlab-org/gitlab/-/work_items/628575 — once external MCP servers can be registered and governed, both this flag and the carve-out come out.

Events

Feature Flag events are only logged by default for feature flags marked for the current or future milestones. To enable while the feature flag is active, see https://docs.gitlab.com/development/feature_flags/#logging

Rollout

Run all production /chatops in #production and cross-post the results to #g_ai_control_plane . Background: incremental rollout process, feature actors.

Non-production

/chatops gitlab run feature set dap_allow_client_injected_mcp_tools 50 --actors --dev --pre --staging --staging-ref
/chatops gitlab run feature set dap_allow_client_injected_mcp_tools true --dev --pre --staging --staging-ref

Production — percentage rollout (wait ≥15 min between steps, watch dashboards):

/chatops gitlab run feature set dap_allow_client_injected_mcp_tools <percentage> --actors

Or target specific actors instead:

/chatops gitlab run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss dap_allow_client_injected_mcp_tools true
/chatops gitlab run feature set --group=gitlab-org,gitlab-com dap_allow_client_injected_mcp_tools true
/chatops gitlab run feature set --user=<gitlab-username-of-dri> dap_allow_client_injected_mcp_tools true

Before global rollout

Confirm the relevant gotchas before going to 100% — see enabling a feature for GitLab.com:

Cleanup

Remove the flag once deemed stable — see cleaning up. Track it here, or open a follow-up Feature Flag Cleanup issue. Remove the flag and its YAML definition from the codebase, then:

/chatops gitlab run release check <merge-request-url> <milestone>
/chatops gitlab run feature delete dap_allow_client_injected_mcp_tools --dev --pre --staging --staging-ref --production

Rollback

/chatops gitlab run feature set dap_allow_client_injected_mcp_tools false                                         # production
/chatops gitlab run feature set dap_allow_client_injected_mcp_tools false --dev --pre --staging --staging-ref     # non-production
/chatops gitlab run feature delete dap_allow_client_injected_mcp_tools --dev --pre --staging --staging-ref --production  # remove entirely