The LLM Router Attack Surface

When you call the OpenAI or Anthropic API directly, your request is encrypted via TLS. The provider authenticates you, you authenticate them. Standard security.

But many developers don't call providers directly.

They use LLM API routers. Cheaper tokens, multi-provider access, unified API. These routers sit between you and the model provider.

And that changes the security model completely.

A router is an application-layer proxy. It terminates your TLS connection, reads the full JSON payload in plaintext. Your prompts, your tool calls, your function arguments. Then forwards it to the upstream provider. The provider sees the router as the client, not you.

This means: the router can read everything. And it can modify anything.

How often does this actually happen? More than you'd think.

A recent study tested 428 LLM routers, paid and free.

→ 9 were actively injecting code into the model's responses → 17 were accessing credentials found in the prompt context → 1 exploited a private key that a user had passed in a prompt, and drained the crypto wallet → 2 used adaptive triggers. Normal behavior for most requests, injection only when a specific pattern is detected

That last point is worth understanding. Standard testing (send a few requests, check the responses) won't catch conditional injection. The router behaves perfectly until it detects a specific framework in your code, or a credential pattern in the request.

And this isn't theoretical. Earlier this year, a widely-used open-source LLM proxy library had malicious code injected into two of its PyPI releases. The community caught it, but the window of exposure was real.

The attack surface breaks down into a few categories:

Payload injection. The router rewrites your tool-calling arguments before forwarding. Your agent executes a rewritten function without knowing it.

Secret exfiltration. Your request contains credentials in the context. The router reads them. In one case, leaked credentials gave access to 100M tokens on a major provider.

Adaptive evasion. The router only injects when it detects a specific dependency or pattern. Standard testing doesn't catch it because the trigger condition isn't met during testing.

Important caveat: the study focused on gray-market sources, not established commercial providers who have explicit privacy policies and no-logging defaults. The signal is real, but the scope matters.

If you use any LLM intermediary, three practical checks:

1/ Response validation. Compare what your agent requested vs what came back. Flag discrepancies.

2/ Append-only logging. Store raw request/response pairs. If something is modified in transit, you need the trace.

3/ Treat the router like a dependency. It has more access to your data than most packages in your stack. Vet it accordingly.