AI LLM-Driven SSRF Lab: Push the Agent's Fetch Tool Inward

This article examines a hands-on lab demonstrating Server-Side Request Forgery (SSRF) attacks triggered through an LLM agent with a fetch tool protected only by a natural-language denylist. The lab shows how FetchBot's guard—which blocks URLs containing 'localhost', '127.0.0.1', or 'internal'—fails to prevent access to the cloud metadata endpoint at 169.254.169.254 because that address contains none of the banned substrings. The scenario illustrates a critical gap between prompt-level security controls and actual code enforcement, with real-world parallels to the 2019 Capital One breach.

• Denylist guards always miss alternativesThe article demonstrates that guardrails framed as 'refuse things that look bad' are inherently incomplete: FetchBot's denylist enumerates only three forbidden substrings, but the cloud metadata IP 169.254.169.254 bypasses this list entirely because it contains none of those words. The core lesson is that blocklists fail by design because they cannot anticipate every alternative form of an internal target.
• The metadata endpoint as SSRF vectorCloud metadata endpoints like 169.254.169.254 are high-value targets because they return IAM credentials without authentication when accessed from within the cloud environment. The article cites the 2019 Capital One breach, which exposed data on approximately 100 million people by reaching a metadata endpoint via SSRF—the exact target the lab reconstructs.
• LLM-driven SSRF mechanics in this labThe attack flow is straightforward: a user confirms the guard is a denylist (not an allowlist), identifies an internal target that avoids every banned substring, asks FetchBot to fetch the metadata IP by its numeric address, and surfaces the returned credentials. The LLM merely operates the server-side fetch tool; the classic SSRF vulnerability is enabled by weak access controls, not LLM reasoning.
• Why prompt-level controls failThe guard reasons about surface strings in the URL, not about what the address actually resolves to or where it leads. Because the metadata IP is internal but matches no banned word, the model considers it allowed and the server-side tool—running with full network access—retrieves it without restriction. The LLM's logic-based reasoning cannot substitute for code-enforced boundaries.
• Code-enforced allowlist defense strategyThe article prescribes four concrete defenses: enforce an allowlist in code around the fetch tool permitting only specific external domains, resolve the host and block private, loopback, and link-local ranges at request time, require IMDSv2 so reachable metadata endpoints resist tokenless reads, and run tools with least privilege plus egress filtering. These shift control from the prompt to the application layer and network.
• Real-world classification and scopeThe article maps LLM-driven SSRF to OWASP LLM06 (Excessive Agency) plus classic SSRF (A10 in the web Top 10), establishing it as a serious cloud-security concern. The 2019 Capital One breach is cited as proof that metadata endpoint exploitation via SSRF is not theoretical and results in massive real-world data exposure.
• Evaluating agent fetch tool securityThe article offers a practical heuristic: 'Any agent with a server-side fetch tool is an SSRF vector.' Security should be judged by whether destinations are allowlisted in code; a natural-language denylist is explicitly stated to be not a control. This shifts the burden of proof from the defender explaining why the guard should work to the developer proving destinations are restricted.

Bottom line: LLM-driven SSRF succeeds when fetch tools rely on prompt-level denylists instead of code-enforced allowlists and network controls; defending against this requires allowlisting destinations in code, blocking private and link-local ranges after DNS resolution, requiring IMDSv2, and applying least privilege and egress filtering to the agent's runtime environment.