SSRF in AI Agents: Why a Tool Call Is All It Takes (and How to Block It at Egress)

An ssrf ai agent attack happens when an agent is tricked into fetching an attacker-chosen URL, letting it reach internal services or the cloud metadata endpoint at 169.254.169.254 . Because the agent runs with real network access and credentials, one poisoned tool call can exfiltrate IAM tokens. The reliable fix is default-deny egress enforcement, not prompt filtering.

Server-side request forgery predates AI, but agents make it far worse. A traditional web app has a fixed set of outbound calls a developer wrote by hand. An agent decides its own URLs at runtime, driven by model output that may be shaped by untrusted content it just read.

Why a tool call is all it takes to trigger SSRF

Most agents ship with a generic HTTP or fetch tool. The model supplies the URL as a plain string argument. Nothing in the tool definition constrains where that request can go.

An attacker does not need shell access. They need to influence one argument. A poisoned web page, a malicious document in a RAG index, or a crafted email can all instruct the model to call an internal address.

The classic target is the cloud metadata service. On AWS, GCP, and Azure, a request to the link-local address 169.254.169.254 returns instance identity and, often, temporary credentials. If the agent fetches that URL and returns the body to the model, those secrets can flow straight into the next outbound call.

server side request forgery ai agent: the attack chain

• Untrusted content instructs the model to summarize a URL.

• The model calls the fetch tool with http://169.254.169.254/latest/meta-data/iam/security-credentials/ .

• The metadata service returns short-lived IAM credentials.

• The model, still following injected instructions, sends those credentials to an attacker webhook.

Every step uses a legitimate tool doing exactly what it was built to do. The agent never crashed and no exploit fired. The abuse lives entirely in the choice of destination.

Why prompt filters do not stop metadata service theft

Input classifiers try to catch injection before it reaches the model. They help, but they are probabilistic and operate at the wrong layer for this problem.

The dangerous event is not the prompt. It is the outbound request to a private or link-local address. By the time that request is on the wire, no amount of prompt inspection matters. You need something watching the network path itself.

This is the difference between the inference boundary and the network boundary. A guardrail that reads text cannot see a TCP connection to a metadata endpoint. Agent G sits on that network boundary as an egress proxy and evaluates the actual destination of every call. More on that split is at https://agentg.dev/.

How to prevent ssrf llm attacks at the egress layer

The core control is simple to state and hard to bypass: the agent may only reach destinations you explicitly allow, and dangerous internal ranges are blocked before the connection completes.

Agent G enforces this as a drop-in proxy. Instead of trusting the model to pick safe URLs, you route agent traffic through a policy engine that inspects the resolved destination, not just the string the model typed.

Control | What it blocks | Where it runs |

Default-deny allowlist | Any destination not explicitly approved | Egress proxy |

Link-local and RFC 1918 blocking | 169.254.169.254 , private ranges, loopback | Egress proxy |

DNS rebinding protection | Hostnames that resolve to internal IPs | Resolver plus proxy |

Deep argument inspection | URLs embedded in tool call arguments | Policy engine |

Two details matter for real coverage. First, the proxy must evaluate the post-resolution IP, because evil.example.com can resolve to 169.254.169.254 in a DNS rebinding attack. Second, it must inspect the tool argument itself, so an internal URL is caught even inside a nested JSON payload.

metadata service theft agent: a concrete lockdown

Start by blocking the metadata range for every agent by default. Almost no legitimate agent workflow needs to fetch instance credentials over HTTP. The dedicated walkthrough for that endpoint is at https://agentg.dev/blog/how-to-block-metadata-endpoint-169-254-agents.

Then build a positive allowlist of the external APIs your agent actually uses. Everything else, including private ranges and unknown hosts, is denied and logged. The full playbook for this posture is at https://agentg.dev/blog/default-deny-egress-allowlist-ai-agents.

What good SSRF enforcement looks like in production

A production-ready egress control for agents should do more than drop packets. It should give you evidence and control at the moment of the request.

• Block by resolved IP , not by hostname string, to defeat rebinding.

• Deny all private, loopback, and link-local ranges unless a rule explicitly permits them.

• Inspect tool call arguments so a URL hidden in a payload still gets evaluated.

• Log every allowed and denied destination as an out-of-band audit record.

• Escalate ambiguous internal requests to a human before the connection opens.

That last point matters for legitimate internal traffic. Some agents genuinely need to reach an internal service. The answer is a narrow, named allow rule for that specific host, not a blanket permission to roam the internal network.

Because Agent G runs inline and writes signed records of each decision, an SSRF attempt becomes a logged, blocked event you can alert on rather than a silent credential theft you discover weeks later.

Frequently Asked Questions

Can I fully prevent ssrf ai agent risk with input validation alone?

No. Input validation reduces injection but cannot guarantee the model will never emit an internal URL. The durable control is enforcing allowed destinations at egress, where the actual outbound connection is evaluated against policy regardless of how the URL was chosen.

How do I block the cloud metadata endpoint specifically?

Deny outbound requests to 169.254.169.254 and other link-local ranges by default for every agent, evaluated on the resolved IP to defeat DNS rebinding. See the step-by-step guide at https://agentg.dev/blog/how-to-block-metadata-endpoint-169-254-agents for exact rules.

Does an egress proxy break legitimate agent traffic?

Not when configured with a positive allowlist. You approve the external APIs the agent actually needs, and everything else is denied and logged. Internal services can be permitted with narrow, named rules rather than broad network access.

Where does this fit with my existing WAF or service mesh?

A WAF inspects inbound HTTP, and a service mesh sees hosts and ports but not tool intent. Agent G adds application-aware egress enforcement for outbound agent actions. Details are at https://agentg.dev/.

SSRF against agents is not an exotic exploit. It is the predictable result of giving a model a fetch tool and trusting it to pick safe URLs. Move that trust to the network boundary, default-deny outbound destinations, and block the metadata range, and a single poisoned tool call stops being a credential breach.

To lock down SSRF and other egress risks across your AI agents, request access to the Agent G private beta at https://agentg.dev/#waitlist.