Tool Poisoning SSRF Chain (Instance-Resolved)
An attacker plants a malicious URL inside data an AI agent trusts, such as a tool's input or its description. Later the agent follows that URL and makes a request to a restricted destination like cloud instance metadata, localhost, or an internal-only network address, potentially leaking secrets or reaching systems that should be unreachable from the agent.
How the attack works
An attacker first poisons a tool's input or its description with a URL pointing at a restricted target: cloud metadata service, loopback, private IP ranges, cluster-internal hostnames, or a DNS-rebinding domain. Later in the same session, the agent (or a process it spawns) issues an actual network request toward that restricted target. The detection only fires if there's strong evidence this is deliberate abuse: the poisoned payload recorded earlier in the session, an obfuscated address (hex/octal/decimal IP, percent-encoding, @-userinfo tricks) that no legitimate SDK would produce, or a restricted address stuffed into a URL-like parameter (url=, redirect=, webhook=, etc). Plain internal-target parameters need a second confirming step in the same session before they count. All correlation stays within one process lineage and its child processes in one session, so two separate attacks are tracked as two separate chains, never merged.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7f3c1a94-2d68-4b5e-9c07-8a1f6d34be21
- Severity
- High
Why it matters
If successful, an attacker can pull sensitive cloud credentials from instance metadata, probe or attack internal-only services the agent shouldn't be able to reach, or bypass network segmentation entirely - all by hiding malicious instructions in content the agent reads and trusts.
What you can do
- →Restrict which URLs and hosts an agent's tools are allowed to call, and block outbound access to metadata service IPs from agent processes unless explicitly required.
- →Review any tool descriptions or gateway metadata that could be edited by external or untrusted sources, since these can carry hidden malicious URLs.
- →Log and review tool inputs alongside the agent's outbound requests within the same session so a poisoned payload and its resulting request can be traced together.
- →Treat parameters like url=, redirect=, webhook=, or image_url= that accept arbitrary destinations as high-risk, and validate or allowlist their targets before the agent acts on them.
Known benign look-alikes
- Cloud SDKs and agents legitimately reading the instance metadata service (aws cli, boto3, gcloud, kubelet, cloud-init). Excluded - metadata destinations alone never fire; a poisoned-payload, obfuscation or parameter-SSRF anchor is mandatory.
- Agents calling internal APIs, localhost dev servers, or cluster.local services. Excluded by the same mandatory anchor, and an internal-only embedded target additionally requires a second session-scoped stage.
- Legitimate webhook or callback registration where an internal URL is passed as a parameter value to an internal service. This can still report; the kill chain and the named anchor make triage immediate, and the action is report, not block.
- Authorised SSRF or pentest tooling and CI security scans run through a monitored agent.
- Documentation, test fixtures or IaC templates that contain 169.254.169.254 or RFC1918 literals and are read through a tool. These only record a store marker and stay silent unless a matching restricted request actually follows in the same session.
- Truncated process lineage (an unmonitored shell above the agent) yields a short session; the rule stays silent rather than guessing an owner.