LLM API Endpoint or Auth Header Redirection

How the attack works

An attacker gains the ability to set or change the base URL environment variable an AI agent uses to reach its LLM provider, or otherwise intercepts the traffic path. The agent starts sending its normal API requests — including its authentication key and all prompt/response content — to the attacker-controlled relay instead of the real provider. The relay can forward requests to the real provider so the agent keeps working with no visible failure, while quietly capturing everything that passes through. This gives the attacker full visibility into the agent's conversations and a copy of a working API key.

Netzilo detection

Why it matters

An attacker gets a live copy of the API key and every prompt and response the agent processes, which can include confidential data, credentials, or business logic embedded in the agent's instructions — all without the agent or its operator noticing anything wrong.

What you can do

• →Pin the expected LLM provider hostname and reject or alert on any outbound LLM request to a different host.
• →Treat changes to LLM base-URL environment variables or config as a security event, not routine configuration.
• →If you use an approved LLM gateway or proxy (LiteLLM, Portkey, Helicone, internal relay), explicitly allowlist its host rather than allowing arbitrary redirection.
• →Rotate the provider API key if you find requests going to an unexpected host, since the key must be treated as exposed.

Known benign look-alikes

• An approved LLM gateway or proxy (LiteLLM, Portkey, Helicone, an internal relay) — add its host to the three filter selections before enabling, or this rule will fire on every request
• Self-hosted inference on a LAN address rather than loopback
• A provider adding a new API domain not yet in the allowlists
• Developers testing against a mock LLM server on a non-loopback interface

References

• https://attack.mitre.org/techniques/T1556/
• https://attack.mitre.org/techniques/T1090/

Related threats