How is SSRF different from prompt injection?

Prompt injection manipulates model instructions. SSRF abuses a server-side fetch path, often through a tool call, so the backend reaches a network location the attacker cannot access directly.

How do you measure SSRF in LLM apps?

Use FutureAGI's SSRFDetector for CWE-918 findings, then track blocked private-network requests, unsafe fetch-tool traces, and regression-fail-rate by route.

What Is SSRF in LLM Apps? FutureAGI Guide (2026)

What Is SSRF in LLM Apps?

SSRF in LLM apps is a security failure where a model-connected tool or server fetches an attacker-controlled URL from a privileged backend context. It shows up at the agent-tool, connector, gateway, and eval pipeline surfaces when user text, retrieved content, or tool output can influence outbound requests. FutureAGI maps the risk to eval:SSRFDetector, the security detector for Server-Side Request Forgery vulnerabilities (CWE-918), so teams can catch unsafe fetch paths before they expose internal services.

Why it matters in production LLM/agent systems

The dangerous failure is not that the model says something wrong. The danger is that the application obeys a network request the attacker chose. A user can ask a research agent to summarize http://169.254.169.254/latest/meta-data/, follow a redirect to an internal admin panel, or fetch a URL from a poisoned document. If the fetch tool runs inside a cloud VPC, the backend may reach metadata services, private APIs, Redis dashboards, internal webhooks, or control-plane endpoints the public internet cannot see.

The first production symptom is often metadata exfiltration: credentials, temporary tokens, instance IDs, or internal hostnames appear in tool output or model context. The second is internal service pivoting, where an agent that should only read public pages becomes a proxy into private infrastructure. Developers see confusing tool results. SREs see outbound requests to link-local, loopback, or RFC1918 ranges. Security teams need proof of which prompt, tool call, redirect, and route created the request.

SSRF is especially relevant for 2026 agentic pipelines because LLM apps no longer just generate text. They browse, retrieve, summarize URLs, call webhooks, inspect files, and invoke MCP-connected tools. Every “fetch this” capability turns model-controlled text into a network action. The risk grows when agents retry automatically, follow redirects, or chain one tool result into the next planner step.

How FutureAGI handles SSRF in LLM apps

FutureAGI anchors this issue to eval:SSRFDetector. In the inventory, SSRFDetector is the security detector for Server-Side Request Forgery vulnerabilities, mapped to CWE-918. In a FutureAGI workflow, engineers run it against model-connected code paths such as URL fetch tools, webhook handlers, connector proxies, crawler utilities, and agent wrappers that pass model-selected URLs into server-side HTTP clients.

A practical example: a LangChain research agent exposes a fetch_url tool. The implementation accepts a URL from the planner and calls the network without validating scheme, host, DNS resolution, redirects, or private address ranges. SSRFDetector flags that as an SSRF risk. The engineer then changes the tool contract: only https is allowed, hosts must match an allowlist, DNS is resolved before request, link-local and private IP ranges are blocked, redirects are rechecked, and the research-fetch route uses an Agent Command Center pre-guardrail before the tool runs.

FutureAGI’s approach is to connect code findings to runtime evidence. Unlike a generic Semgrep rule that stops at source analysis, FutureAGI can tie the SSRFDetector finding to traceAI-langchain traces showing agent.trajectory.step, the route, the tool decision, and the guardrail outcome. If a risky URL is blocked in production, the trace becomes review evidence. If a new prompt version increases blocked fetch attempts, the engineer adds those traces to a regression dataset and fails the release until the route, tool schema, or guardrail threshold is fixed.

How to measure or detect it

Use code, trace, and network signals together:

SSRFDetector findings - detects Server-Side Request Forgery vulnerabilities (CWE-918) in model-connected fetch, webhook, connector, or proxy code.
Trace evidence - inspect agent.trajectory.step, route name, tool call, candidate URL host, redirect chain, guardrail decision, and final fallback status.
Dashboard signal - track SSRF-fail-rate by route, blocked-private-network requests, link-local requests, redirect-block rate, and unsafe fetch-tool attempts per tenant.
Network control signal - alert on egress to loopback, RFC1918, link-local, cloud metadata endpoints, or internal DNS zones from agent workers.
Review proxy - monitor escalations where a model response includes internal hostnames, cloud metadata, service banners, or raw webhook output.

from fi.evals import SSRFDetector

tool_code = "requests.get(user_supplied_url, allow_redirects=True)"
result = SSRFDetector().evaluate(input=tool_code)
print(result.score, result.reason)

Treat any confirmed SSRF path as a release blocker. A single high-severity finding is enough to require a code fix, a regression case, and a production alert on the affected route.

Common mistakes

SSRF defenses fail when teams protect the model but leave the server-side network path open.

Checking only prompt text. The dangerous value may arrive from a retrieved page, tool output, redirect, or parsed file.
Allowing all https URLs. Private hosts, DNS rebinding, and redirects can still route a trusted backend into internal services.
Validating before redirects only. Re-resolve and recheck every redirect target before the request is sent.
Giving agents generic fetch tools. Narrow tools by domain, method, content type, timeout, response size, and credential scope.
Dropping blocked-request context. Incident review needs prompt, trace ID, route, tool name, URL host, detector result, and fallback.