Duo Workflow Flows should gracefully skip repo-level MCP configuration in sandbox mode

Release notes

Duo Workflow Flows now gracefully skip external MCP server configurations defined in repository mcp.json files when running in network-isolated sandbox mode, improving user experience by eliminating connection retry errors in job logs.

Problem to solve

As a developer using Duo Agent Platform Flows, I want Flows to gracefully handle blocked MCP connections when running in the SRT sandbox, so I can avoid confusing error messages and wasted execution time.

Current behavior:

1. Repository contains mcp.json configuring external MCP servers (e.g., Jira, Memory, custom servers)
2. Flow executes in SRT sandbox which enforces network isolation (only allows gitlab.com, *.gitlab.com)
3. Flow attempts to connect to external MCP servers configured in mcp.json
4. Connections are blocked by network isolation (expected)
5. Flow retries connections ~20 times over 60 seconds
6. Job logs are filled with error messages like:
   • Jira MCP 403 Proxy Error
   • Memory MCP connection timeout
7. User sees confusing errors despite Flow ultimately completing

Impact:

• Poor user experience (error spam in logs)
• Wasted execution time on retries
• Confusion about whether Flow succeeded
• Difficult to distinguish real errors from expected blocked connections

Intended users

• Sasha (Software Developer) - Using Foundational Flows (Software Development, Resolve Vulnerability, etc.)
• Priyanka (Platform Engineer) - Configuring DAP for teams

User experience goal

The user should be able to use Duo Workflow Flows with repositories that have mcp.json configurations without seeing connection error spam when running in sandbox mode. The Flow should detect sandbox mode and gracefully skip unavailable external MCP servers.

Proposal

1. Detect sandbox mode - Flow executor should detect when running in network-isolated SRT sandbox
2. Skip external MCPs - When in sandbox mode, skip attempting connections to MCP servers configured in repo-level mcp.json that are outside the allowlist
3. Log gracefully - Instead of error spam, log a single informational message: "Skipping external MCP servers configured in mcp.json (network isolation active)"
4. Continue execution - Flow proceeds with available tools (GitLab MCP, built-in tools)

Alternative approaches:

• A. Validate MCP server URLs against allowlist before attempting connection
• B. Add a single retry with immediate fail-fast for blocked connections
• C. Add sandbox_mode: ignore_external_mcp configuration option

Further details

Observed in: Foundational Flows (Software Development Flow, Resolve Vulnerability Flow) running on gitlab.com

Example job log showing retry spam:

[warn]: Failed to connect to MCP server "jira" - 403 Proxy Error
[warn]: Retrying connection to MCP server "jira" (attempt 2/20)
[warn]: Failed to connect to MCP server "jira" - 403 Proxy Error
... (repeats 20 times over 60 seconds)
[warn]: Failed to connect to MCP server "memory" - connection timeout
[warn]: Retrying connection to MCP server "memory" (attempt 2/20)
... (repeats 20 times)
[info]: [GitLabBackend] Workflow completed successfully

SRT sandbox allowlist (per #578048):

• gitlab.com
• *.gitlab.com
• duo-workflow-svc.runway.gitlab.net
• localhost
• host.docker.internal

Permissions and Security

No permission changes required. This is about graceful degradation of functionality when network isolation is active.

Security consideration: This change should NOT weaken network isolation - it should simply improve the user experience when isolation is working as intended.

Documentation

• Update Foundational Flows documentation to note that repo-level MCP configurations are skipped in sandbox mode
• Update MCP Client documentation to clarify sandbox behavior

Availability & Testing

• Unit test: Verify Flow executor detects sandbox mode correctly
• Unit test: Verify external MCP URLs are validated against allowlist
• Integration test: Flow with mcp.json executes without error spam in sandbox
• End-to-end test: Software Development Flow completes gracefully with external MCPs configured

Available Tier

• Ultimate (Duo Agent Platform tier)

Related Issues

• Epic &20247 (closed) - Configurable network isolation and user notifications for Duo Agent platform
• #578048 - Application-level network isolation for Duo Agent platform (closed, implemented)
• #585459 - Docs: Add information about support for MCP Clients to Foundational & Custom Flows
• #572113 (closed) - [Investigation] Add MCP support to remote execution flows