LLM Agent URL Exfiltration - Secret or Bulk Payload Carried in Outbound Request URL
An AI agent that can browse or fetch URLs can be manipulated by malicious instructions hidden in content it reads into sending a web request where the sensitive data itself is embedded in the URL. This lets an attacker steal secrets, credentials, or private conversation text just by looking at the destination the agent contacted, without needing to inspect the request body.
How the attack works
An attacker plants hidden instructions in text, a webpage, a document, or other content that the AI agent is likely to process. When the agent reads this content, the injected instructions cause it to construct and send an outbound web request. Instead of putting stolen data in the request body, the attacker's instructions cause the agent to encode a credential, private key, chat excerpt, or other data directly into the URL itself, as part of a query parameter or path segment. The attacker's server, or a logging proxy, receives that URL and simply reads the embedded data off it, completing the theft even though no file was uploaded and no body was sent.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 4e1a7b62-9c3d-4f58-8a17-2b6d0f9e5c41
- Severity
- High
Why it matters
An organization can lose credentials, API keys, or private conversation content without any file transfer or unusual payload showing up in a request body, because the theft happens through the URL used for what looks like a normal web fetch.
What you can do
- →Restrict which domains AI agents are allowed to send outbound requests to, using an allowlist rather than blocking known-bad domains.
- →Log and review full outbound URLs from agent tooling, not just request bodies, since data can be smuggled in query strings and paths.
- →Strip or validate content the agent ingests from untrusted sources before it can influence tool calls or URL construction.
- →Set length and entropy limits on URL parameters generated by agent actions, with exceptions tuned for known auth flows like OAuth, SAML, and presigned storage URLs to avoid false alarms.
Known benign look-alikes
- OAuth2 / OIDC authorization-code and token-exchange round trips, and SAML POST-binding redirects, where code / state / id_token / SAMLRequest carry long opaque blobs - suppressed by filter_auth_params on the bulk-payload branches.
- Presigned S3 / GCS / Azure Blob URLs and CDN signed URLs (X-Amz-Signature, sig, sv, se, X-Goog-Signature) - suppressed by filter_auth_params.
- Paginated API traversal where a continuation token, cursor or pageToken exceeds 256 characters - suppressed by filter_auth_params.
- Telemetry / analytics beacons that batch-encode a payload into a single query parameter (Sentry envelopes, product-analytics collectors). These will report; they are genuinely an agent shipping local state to a third party and are worth one review.
- An agent calling a poorly designed internal API that accepts a bearer token or API key as a query parameter. This is a real credential-hygiene defect rather than an attack, but it is indistinguishable from exfiltration at the URL layer and is reported, not blocked, for exactly that reason.
- Security research, red-team fixtures and documentation URLs containing example keys or template placeholders - suppressed by filter_noise.
- Content-addressed asset paths with unusually long single segments (some build tools emit 200+ character hashed filenames) - reported by the path-blob branch only.