Browsing tool without URL allowlist
ID |
browsing-tool-without-url-allowlist |
Severity |
critical |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
OWASP LLM |
LLM06:2025 — Excessive Agency |
OWASP ASI |
ASI02:2026 |
Family |
LLM06 — Excessive Agency |
Red-team vectors |
SSRF via AI Browsing |
Tags |
ai_security |
Description
An agent browsing / HTTP-fetch tool has no URL/host allowlist and no declared SSRF protection. The model can steer the tool to reach any host — cloud instance-metadata endpoints (169.254.169.254, metadata.google.internal, …), private networks, localhost services — a server-side request forgery surface.
Reaching a metadata endpoint returns the instance’s credentials, so this is a direct path to credential theft and lateral movement into the cloud account — hence Critical. When the code names a metadata/IMDS host explicitly, the finding fires even if an allowlist is present (an allowlist that does not exclude the metadata endpoint offers no protection), and the finding carries a metadata_endpoint property.
This is the configuration framing (no allowlist) and is deliberately not deduplicated against the LLM05 browsing-tool-returns-raw-content (the content-flow framing): both may fire on the same tool and reference each other. A tool with an allowlist that does not reach a metadata endpoint is not flagged.
Examples
tool = RequestsGetTool(requests_wrapper=TextRequestsWrapper()) (1)
| 1 | Fetch tool with no url_allowlist / allowed_hosts — flagged. |
Configuring allowed_hosts / url_allowlist produces no finding.
Mitigation / Fix
-
Restrict the tool to an explicit URL/host allowlist; block private/link-local ranges, including
169.254.169.254and the other IMDS hosts. -
Disable following redirects so a redirect cannot escape the allowlist.
-
Harden the instance itself (IMDSv2
http_tokens = required) so a bare SSRF cannot read credentials — tracked separately for the IaC scanner.