Consider a fictional research agent asked to summarize a public document. It calls a URL-reading tool. The URL redirects to an address reachable only from the tool server's network.
From the user's perspective, the agent is still reading a document. From the infrastructure's perspective, a privileged server has been instructed to connect to a new destination.
Follow the connection
In server-side request forgery, or SSRF, an attacker influences where the server makes a request. The value of the bug depends heavily on where that server sits and which credentials accompany the request.
The Grafana MCP advisory describes a concrete chain involving session spoofing and a caller-controlled destination override. That chain illustrates why URL tools need controls beyond an apparently sensible hostname check.
Use the fictional request above to trace those controls:
| Point in the request | What to inspect | What a hostname check alone misses |
|---|---|---|
| URL parsing | Scheme, port, user-info, canonical host | Alternate representations and parser disagreement |
| DNS resolution | Every resolved address | A public-looking name resolving to a private address |
| Connection | The address actually used | DNS changing between validation and connection |
| Redirect | The new destination and credentials | A safe first hop pointing to a forbidden second hop |
| Response | Byte budget and duration | A permitted destination returning unbounded data |
Try the redirect case first
In a test environment, let an approved test endpoint redirect to a destination your policy denies. The tool should stop before making the second connection.
Inspect the destination's access logs as well as the tool's response. A clean-looking error message is insufficient if the forbidden request already happened.
Repeat the exercise with IPv6, loopback, link-local addresses, and DNS answers that change. Use controlled endpoints rather than probing unrelated infrastructure.
Credentials need their own rule
A server may add an authorization header automatically because it normally calls one trusted backend. If the caller can change the destination while retaining that header, a fetch feature can become a credential-disclosure path.
Bind credentials to approved destinations. Re-evaluate whether any header or cookie should survive a redirect. Do not log raw credential values while investigating.
Finish at the network boundary
Application validation should be reinforced by a narrow egress policy. A general research tool usually has no reason to contact cloud metadata or internal administration services.
Give legitimate private-network use cases their own approved destinations and credentials. This lets operators distinguish intended access from an agent following an unexpected link. The egress design article shows how to make that distinction operational.