Authorization of the first URL is not authorization of the final destination. Each redirect is a new request to a potentially different principal. The server may be compromised, the redirect may be user controlled, and a hostname can resolve to different addresses at different times. The risk is both data leaving through a token or URL and the fetcher reaching an internal service that the agent could not call directly. OWASP's SSRF prevention guidance recommends disabling automatic redirects for precisely this bypass class.

I would turn off automatic following and handle each hop in a broker. Parse and normalize the Location against the current URL, reject unsupported schemes, userinfo, odd ports, and more hops than the workflow needs. Evaluate the new origin against an explicit destination policy for this tool and user scope. Resolve the host through the broker's resolver, inspect all returned A and AAAA addresses, and reject private, loopback, link-local, and other forbidden ranges for this policy. The connection must use the vetted address while preserving the intended hostname for TLS verification, rather than doing a second unconstrained DNS lookup after the check. Egress rules should still deny internal ranges if the application logic fails. This is defense in depth, not a claim that a URL parser by itself solves SSRF.

Credentials are scoped per hop. The token for reports.partner.example is not copied to a different origin just because that host appeared in Location. A CDN URL may carry a short-lived signed capability in its query instead. Treat it as sensitive, do not log it, and require that the partner's redirect contract names the approved CDN origin and resource scope. Do not forward the original Authorization header, cookies, or private request body across an origin change by default. A 307 or 308 can preserve the method and body in some clients, which is especially dangerous for an action request. For write tools, I would generally refuse a redirected effect and require a canonical operation endpoint with an effect receipt. A GET report fetch and a POST approval are not the same policy.

A signed redirect is not enough if its signature only says “the partner produced this URL.” The broker still has to decide whether the target host, IP range, resource type, size, and user permission fit the approved action. If the partner uses a changing CDN fleet, approve a documented origin pattern and bind the signed URL to the requested report ID, tenant, short expiry, and read-only method. Test that the CDN never redirects again to a disallowed destination. If their design requires arbitrary hosts, put an isolated proxy with no internal network route in the path or decline the integration for private reports.

There is a subtle race. DNS can change between policy validation and connection, and proxies may resolve names themselves. Test the actual connected peer and keep the resolver, HTTP client, and proxy on one enforced path. TLS checks must not be disabled to make IP pinning work. Record each hop's sanitized origin, resolved address class, authorization decision, final status, and report identity without storing tokens or signed queries.

Now the interviewer asks whether an allowlist of two hostnames is sufficient. It is a useful input, but it does not prove where those names resolve or what credentials cross the boundary. I would run cases for a relative redirect, scheme downgrade, alternate port, IPv6 loopback, DNS rebind, redirect loop, redirect to an internal metadata service, and a cross-origin 307 with a request body. The invariant is that every network hop is an independently authorized fetch with only the authority it needs.