## User problem to solve Duo Chat can only draw on the model's training data and GitLab context. When developers need current information, like up-to-date package versions, vulnerability advisories, framework migration guides, or deprecation notices, Duo either gives outdated answers or can't help at all. Developers end up leaving GitLab to search manually or falling back to ChatGPT and Perplexity. Enterprise customers and the field consistently describe web search in agentic tools as a "must have." The gap is real: developers comparing Duo to tools with web search see little reason to stay in Duo for technical research questions. Outdated dependency recommendations directly affect security and code quality. ## Personas - **Sasha (Software Developer):** "I need current technical information, like package versions, vulnerability fixes, and framework changes, while I'm working, without leaving GitLab to search manually." - **Priyanka (Platform Engineer):** "I need to control whether my teams can use web search in Duo Chat, and restrict which external domains it can reach, so I can meet our compliance requirements." ## Proposal Web search as a capability in Duo Chat, giving the model access to current external information when it needs it. Governed by a two-layer control model: an admin toggle for intent ("do we want this capability?") and network domain allowlists for enforcement ("which domains can it reach?"). ### Expected behavior ``` Scenario 1: Developer asks a question that needs current information Given a developer has web search enabled for their conversation And their group admin has enabled web search for the group When they ask Duo Chat a question that requires information beyond the model's training data Then Duo Chat searches the web for current information And returns an answer with clear source attribution and links And displays a "Searched the web" indicator Scenario 2: Admin enables web search for a group Given a group admin navigates to Duo settings When they enable the web search toggle Then developers in that group can use web search in Duo Chat And the toggle is off by default Scenario 3: Web search respects network access controls Given a group admin has enabled web search And the instance has network access domain allowlists configured When Duo Chat attempts a web search Then the search only reaches domains permitted by the allowlist And blocked attempts are surfaced for debugging Scenario 4: Developer opts in to web search Given web search is enabled at the group level When a developer starts a Duo Chat conversation Then web search is not active until the developer opts in And the opt-in mechanism is clear and low-friction Scenario 5: Web search is disabled at the group level Given a group admin has not enabled web search When a developer asks Duo Chat a question Then Duo Chat does not make any external search requests And answers using only the model's training data and GitLab context ``` ### Worked Example Sasha is reviewing a dependency bump MR and asks Duo: `Has CVE-2025-50182 in urllib3 been patched? Which versions are safe?` **Given** - Web search is enabled at her group's instance settings - Network allowlist permits the model vendor's search endpoint - Sasha has toggled "Search the web" on in the chat input **Expected, observable outputs:** - The conversation thread emits exactly one web_search tool call - The response body contains at least one URL in markdown link format pointing to a permitted source domain (e.g. nvd.nist.gov, github.com/advisories, urllib3 changelog) - A "Searched the web" indicator renders above the answer with a "Sources" disclosure expanding to the citation list - An audit event row is inserted with an event name that web search was invoked ### Governance - Admin toggle at the group level, off by default - Respects existing Duo subgroup/project boundaries - Integrates with the Configurable Network Access for Agents and Flows controls (domain allowlists) - Developer opts in per conversation - Clear "Searched the web" indicator with source links on every web-sourced answer ### Implementation approaches to evaluate The epic does not prescribe an implementation path. Discovery should evaluate: 1. **Vendor-native search.** Leverage model providers' built-in search capabilities (e.g., Claude web search). GitLab adds the governance and UX layer. Fastest path to value, lowest maintenance. Open question: how do network allowlists apply when the vendor is doing the searching? 2. **MCP-based search tool.** Build or adopt a web search MCP server that Duo Chat's agent can invoke. GitLab controls the full pipeline. Clean fit with existing tool architecture and network allowlists apply directly. More to build and maintain. 3. **Hybrid.** Start with vendor-native for speed, add MCP later for more control or to support models without native search. ### Not in scope - General-purpose web browsing or non-development use cases - Building and maintaining our own search infrastructure ## What we need to figure out - How do users trigger/control web search? Per-conversation toggle, explicit command (like `/` command to toggle web on/off) or model-initiated with consent? - How do the admin toggle and network access allowlists interact technically, especially when the vendor does the searching? - Which model vendors' native search capabilities meet our needs and at what cost? - How does this integrate with the AI Gateway routing layer? - What does the "searched the web" UX look like across surfaces (web, IDE, CLI)? ## Dependencies - Configurable Network Access for Agents and Flows epic (network allowlists, domain controls) - AI Gateway (routing to model providers with search capabilities) - Model vendor search capabilities and pricing