SSRF in Agent Fetching Tools
Can a supplied URL make the agent’s server reach a protected network resource?
Reference notes by Min · Reviewed October 15, 2026
Definition
Server-side request forgery occurs when an application is induced to make unintended network requests using its own connectivity. Agent fetching tools are exposed when user or retrieved content controls a destination the server accesses.
A fetching tool can access networks that the user cannot reach directly. This creates a privilege boundary even when the visible task is simply summarizing a web page. The tool must decide where it may connect rather than rely on the apparent intent of the request.
What it covers
- Input
- Where destination values originate.
- Resolution
- How names and redirects become network endpoints.
- Reachability
- What the fetching service can contact.
- Response
- What retrieved information is returned to the agent.
Define whether the tool serves a small set of known services or general public browsing. These cases need different destination policies. Include protocol handling, redirects and network resolution in the review, and examine metadata or administrative endpoints reachable from the runtime.
In practice
Practical design patterns by Min.
- Apply destination controls in the fetching service.
- Restrict network reachability as well as URL input.
- Revalidate redirects and avoid forwarding unrelated credentials.
Evaluate controls at both application and network layers. Test blocked destinations using a controlled environment rather than real sensitive targets. Keep failure responses informative enough for the task but avoid returning internal service details that expand the exposure.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Validate destinations and constrain reachability
OWASP discusses application and network defenses, including the complexities of URLs and redirects. Agent tools should enforce those boundaries independently of generated instructions.
Source: OWASP: Server Side Request Forgery Prevention Cheat Sheet ↗
Working example
A public research task follows an unsafe link
A retrieved page supplies another URL for the agent to inspect.
- Treat the new destination as untrusted.
- Enforce the allowed network and protocol boundaries.
- Return a clear blocked-destination result without exposing protected response content.
Why the controls matter
The research example can cross several links before reaching the problematic destination. Permission to read the initial page does not authorize every subsequent network request. Each relevant transition needs the same boundary enforcement.
Common pitfalls
- Asking the model to identify safe URLs as the only defense.
- Checking a hostname while ignoring where it resolves.
- Allowing a permitted first URL to redirect anywhere.
Network restrictions do not establish that permitted content is trustworthy. A reachable public page can still contain prompt injection or misleading information. Combine network destination controls with content trust handling and limits on what the agent can do with the response.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Which networks can the fetcher reach?
- Are redirects subject to the same controls?
- Can credentials be forwarded beyond their intended recipient?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- OWASP: Server Side Request Forgery Prevention Cheat Sheet ↗Accessed October 15, 2026
- OWASP: Authorization Cheat Sheet ↗Accessed October 15, 2026