Skip to content

[Workflow] Handle runHttpRequest action from Duo Workflow

Igor Drozdovrequested to merge
id-duo-workflow-handler-https into master

What does this MR do and why?

In Workhorse: Act as a proxy to Duo Workflow (!193149 - merged), we introduced connection to Duo Workflow service. It enabled the implementation of Web Agentic Chat on gitlab.com. The existing approach works fine for gitlab.com instances because we trust these instances and can perform requests directly to them. However, we cannot trust self-managed instances the same way.

Related issue: [Workhorse] Handle runHTTPRequest action in duo... (#553083 - closed)

Overview

Screenshot_2025-07-07_at_22.34.16

If we apply the existing approach to self-managed instances, the following issues are possible:

  • The fact that Gitlab-managed Duo Workflow Service should perform requests to an arbitrary URL may raise security concerns
  • Some customers have networks closed to external incoming requests, which will require allowlisting Duo Workflow Service: it's not always possible, but even if it's possible, it's an extra effort for customers and support team members.

Proposal

  • Duo Workflow Service calls LLM to process user input and when it needs more info about the user's env (read local file, perform Gitlab API request, call an MCP tool), it sends an action.
  • Web Agentic Chat operates only with Gitlab API calls because it doesn't have a local environment. The API requests can be performed directly to gitlab.com, that's why Web Agentic Chat currently works on gitlab.com

For self-managed instances, the idea is to intercept runHttpRequest actions in Workhorse instead of performing the direct calls to those instances. When the action is intercepted, Workhorse performs an API call to the self-managed Gitlab Rails instance. In this case, all the API requests are performed within a single gRPC connection, which allows us to avoid issues with outgoing connections from Duo Workflow Service and incoming connections to closed instances.

Bonus

Web Agentic Chat in Local GDK + Gitlab managed Duo Workflow Service becomes available

Drawbacks

  • Extra responsibility in Workhorse and in this case the logic is coupled to gRPC client interface
  • The oauth token is still used, even though potentially it can be removed or replaced by a longer-living auth token, since Workhorse is a trusted env
Edited by Igor Drozdov

Merge request reports