Limit MCP Authorization SSRF

OAuth discovery can make an MCP client fetch metadata from a URL it did not choose directly. If an untrusted server supplies that URL, the client might reach a private network service or cloud metadata endpoint. The MCP security guidance treats authorization-server SSRF as a distinct risk. The fix belongs in URL validation and egress policy, not in a warning shown to the model.

Map every network request in the discovery chain: protected resource metadata, authorization server metadata, key set, token endpoint, and redirects. Decide which hosts are expected for the product. A user-approved MCP server is not permission to fetch arbitrary hosts named by that server.

Discovery fetch policy

A regex on the original URL is not enough. DNS answers can change, and redirects can move to a different host. Validate both the parsed URL and the actual connection target. Store a trusted issuer binding before following its endpoints. Do not let an error response introduce a new arbitrary metadata URL.

Test without outside targets

Run a local owned fixture with a benign metadata server and controlled redirect responses. Try an HTTPS-looking URL that redirects to a private address, a hostname resolving to loopback, an oversized metadata body, and a chain longer than the limit. Require denial before the disallowed connection. Then complete a valid discovery flow as a positive control.

Capture the URL class, resolved address class, policy decision, and whether a request was attempted. Avoid recording tokens or authorization codes. If your runtime cannot prove the destination after DNS resolution, keep discovery behind a controlled proxy or an explicit host allowlist. The server can still return a valid-looking OAuth page while the discovery path is unsafe, so test the network behavior separately from token validation.