Threats & safeguards

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

Working governance definitionAlso: Server-side request forgery · URL fetching security2 primary references

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.

  1. Treat the new destination as untrusted.
  2. Enforce the allowed network and protocol boundaries.
  3. Return a clear blocked-destination result without exposing protected response content.
Illustrative scenario, not a reported deployment.

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?

References

Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.

  1. OWASP: Server Side Request Forgery Prevention Cheat Sheet ↗Accessed October 15, 2026
  2. OWASP: Authorization Cheat Sheet ↗Accessed October 15, 2026