(feat) Harden user-MCP http SSRF guard (DNS rebinding + redirects) for OSS default-on

[mmabrouk]

User MCP servers are now on by default in OSS. An agent author controls the mcpServers[].url in their config, and the runner sends the run's Agenta-resolved named secrets as request headers to that URL. We want a self-hoster to leave user MCP on without an author-controlled config being able to reach an internal host and exfiltrate a credential.

Today the SSRF guard checks only the URL scheme and the host literal. validateUserMcpUrl in services/agent/src/engines/sandbox_agent/mcp.ts requires https and rejects loopback, link-local, cloud-metadata (169.254.169.254), and private-IP host literals, with a AGENTA_AGENT_MCP_HOST_ALLOWLIST opt-out. That is scheme + host only. It does not:

• pin the connection to the host it validated, so a hostname that resolves to a public IP at check time can resolve to 127.0.0.1, 169.254.169.254, or a private IP when the harness actually connects (DNS rebinding); and
• re-validate redirects, so a validated public https URL can 3xx-redirect the credentialed request to an internal host.

The blast radius is bounded: secrets ride headers only to https hosts, and the capability is config-trust. But with OSS default-on this is a real residual.

Proposed hardening:

• Resolve the URL host once, validate the resolved IP(s) against the same internal-range rules, and pin the connection to that IP so no second DNS lookup happens at connect time.
• Set redirect: "manual" (or the equivalent) and re-run the origin/IP validation on each redirect hop before following it.

Reference the guard and its docstring at services/agent/src/engines/sandbox_agent/mcp.ts (validateUserMcpUrl and isInternalHost).

Decision for the default-on PR: harden first, or ship default-on with this residual tracked here.

[linear-code]

AGE-3843

[sumit1kr]

Hi @mmabrouk, I went through the SSRF guard history before commenting — PR #4853 added validateUserMcpUrl (scheme + host-literal blocklist) when user MCP was still flag-gated and off by default, and you flagged in that same PR whether DNS-rebinding pinning was warranted. With #4912 flipping the default to on, that residual stops being a proportionate trade-off and becomes a real gap.

I traced the current guard in mcp.ts and can confirm both gaps from the issue description:

1. DNS rebinding — validateUserMcpUrl only does string/regex checks on the hostname (no DNS lookup happens during validation). The
   actual connection is made later by the harness/sandbox-agent SDK, which does its own fresh DNS resolution at connect time. So a
   hostname that resolves public when validated can resolve to 127.0.0.1 / 169.254.169.254 / a private IP when it's actually dialed —
   nothing pins the two together.

2. Redirects — there's no re-validation step anywhere after the initial check, so a validated public https URL that responds with
   a 3xx to an internal host would just be followed with the credential header still attached.

Side note while I was in there: PR #4853 also has an unresolved CodeRabbit comment about new URL().hostname preserving a trailing
dot (so localhost. / foo.localhost. slip past the blocklist). Not sure if that's in scope here or deserves its own issue, but
flagging since it's the same function.

Proposed fix direction: resolve the hostname once, validate the resolved IP(s) against the same internal-range rules, and pin the
connection to that IP instead of letting it re-resolve at connect time; plus set redirect to manual and re-run the full validation on
each hop before following it (capped at a few redirects).

Happy to take this on and open a PR with tests covering the rebinding and redirect cases — could you assign it to me?

[sumit1kr]

Hi @mmabrouk, checking back in on this — happy to send the PR whenever convenient. No pressure, just wanted to keep it visible.