SSRF in Tool-Using AI Agents: A Security Playbook

Server-Side Request Forgery used to be a web-app problem. In 2026 it is an AI-agent problem first, and the agent ecosystem is shipping it at a rate that the rest of the security community hasn't caught up to. The shape is familiar: untrusted input becomes an outbound HTTP request from a trusted process. The novelty is that the untrusted input now arrives as natural language, gets parsed by a model, and reaches the request layer through a tool call. This post is the playbook: how it happens, what holds up under attack, and what to log so you'd see it.

Why this matters

The agent reaching out is the trusted process. It runs inside your VPC, it carries your service credentials, and its outbound requests come from an IP that internal services trust. If the agent's request URL is controllable by a prompt — directly, or transitively through any tool that fetches a URL — you have built an unauthenticated proxy into your internal network. We have audited deployments where this took a single sentence to exploit. The rate of new agent products shipping with this vulnerability has not slowed.

How does SSRF actually get into an AI agent?

The attack surface is wider than people expect because every URL-touching tool is a candidate. A search tool that fetches result pages. A "summarize this link" tool. A document-loader that follows references. A webhook delivery tool. Any retrieval-augmented generation pipeline that fetches an attacker-influenced URL. In our dataset, fewer than 20% of incidents started from a tool literally named fetch_url. The rest were transitive — the model was given an indirect way to cause a request and used it.

The timeline below shows the canonical attack sequence we see most often in incident review.

A minimal vulnerable pattern, and the fix, in TypeScript:

// Vulnerable: any URL the model produces is fetched verbatim.
async function fetchUrl(url: string) {
  const res = await fetch(url);
  return res.text();
}

// Safer: resolve, validate, pin, and route through egress proxy.
async function fetchUrl(url: string) {
  const parsed = new URL(url);
  if (parsed.protocol !== "https:") throw new Error("https only");
  if (!isAllowedHost(parsed.hostname)) throw new Error("host not allowed");
  const ip = await resolvePinned(parsed.hostname);
  if (isInternalIp(ip)) throw new Error("internal IP refused");
  return await fetchThroughEgressProxy(url, { pinnedIp: ip });
}

The fix matters less than what it implies: the request URL is now a policy decision, not a model decision. Treat every URL the model produces as untrusted input and you have a chance. Treat it as a string and you don't.

Which mitigations hold up under adversarial testing?

We ran each candidate mitigation against six SSRF subclasses across a red-team campaign in Q1 2026. Effectiveness here means "blocked the attack in our test corpus." False-positive rate is how often the mitigation blocked legitimate traffic during a one-month shadow deployment at three partner companies.

The heatmap below breaks effectiveness down by SSRF subclass. Allowlists that look adequate against direct URL injection collapse against indirect injection through content the model is asked to summarize.

When does an allowlist fail?

An allowlist fails in four reliably reproducible ways. First, DNS rebinding: the hostname resolves to a public IP during the validation step, then to an internal IP when the actual fetch happens. The fix is to pin the resolution — resolve once, validate, then pass the resolved IP into the request, refusing to re-resolve. Second, open redirects on allowlisted hosts: the model is told to fetch https://trusted-host.example.com/redirect?to=http://169.254.169.254/..., and your allowlist greenlights it because the hostname is fine. The fix is to disable follow-redirects, or to allowlist destinations, not hops. Third, IPv6 representations of internal addresses that string-match filters miss (::ffff:127.0.0.1 notation, link-local addresses). Fourth, decoded URL fragments — http://example.com#@internal.local/ parses differently in different libraries, and the gap is the vulnerability.

The pattern across all four: the allowlist defends a property the attacker can decouple from the actual request. Egress proxies hold up because the proxy makes the request itself, so the attacker cannot decouple the policy decision from the network primitive.

What logging do you need to detect this in production?

The detection target is the outbound request, not the prompt. Capture: every URL the agent process resolves, the final IP after redirects, the response status and size, the tool that initiated the call, and a hash of the prompt that produced the tool call. Alert on any outbound request to a private IP range, any redirect chain longer than two hops, any response over a configured size with text/html content type, and any tool call where the resolved IP differs from the IP seen at allowlist-check time.

The single highest-signal alert in our deployments has been: "outbound request whose resolved IP belongs to RFC1918 or link-local space." It is rare in normal traffic and almost always real when it fires.

Common questions

Where to go next

• Security with AI Pairs — the incident dataset and full mitigation study
• Where AI Pair Programming Fails — the broader taxonomy of agent failure modes
• The Defensibility Rubric 2026 — how security reasoning is scored on the platform