When Your LLM Router Turns On You: Tool-Call Injection and Credential Theft

There is a claim circulating that a batch of LLM routers were quietly injecting malicious tool calls and harvesting credentials — with assertions of a drained crypto wallet and rapid takeover of hundreds of hosts. Treat the specifics as unverified claims, not established fact: PlayCISO has not confirmed them, and dramatic numbers attached to a link are exactly the kind of thing that gets repeated before it is checked. But the underlying risk class is real, it is growing, and it deserves a clear-eyed defensive look. This post is about that risk class — malicious or compromised LLM routers and tool-call injection — and what actually contains it.

What an LLM router actually is — and why it is a soft target

As teams moved from single API calls to agents, a new component appeared in the middle: the LLM router or gateway. It might be LiteLLM, an MCP server or aggregator, a commercial AI gateway, or a homegrown proxy. Its job is to sit between your agents and the models and tools they use — load-balancing across providers, adding retries and caching, enforcing rate limits, and centralizing keys.

That convenience comes with a property attackers love: the router is a man-in-the-middle by design. Everything flows through it — system prompts, user data, the definitions of every tool the agent can call, the arguments and results of each tool call, and frequently the provider API keys themselves. A component that can see and rewrite all of that is a component whose compromise is catastrophic. And because one router usually sits in front of many agents and hosts, compromising it once has downstream reach — the same supply-chain amplification that makes a single file-transfer flaw turn into thousands of victims.

What a hostile router can do

• Inject or rewrite tool calls. The model asks to call read_file; the router adds — or swaps in — a call to move money, read a secret, or run a command. The agent, trusting its own router, executes it. The user never sees the injected step.
• Harvest credentials in transit. Provider keys, OAuth tokens, and any secret embedded in a prompt or tool argument pass through the router in plaintext at the application layer, even under TLS, because the router terminates the connection. A malicious build or poisoned config can quietly log them.
• Tamper with responses. By altering what the model appears to say, a router can steer the agent's next actions — approving a transaction, disabling a check, or following an attacker's plan while looking normal.
• Pivot on forwarded traffic. A router positioned in your network can fingerprint and reach internal services, using the trust it already holds to move laterally.

The closely related vector is indirect prompt injection: malicious content returned by a legitimate tool — a web page, a document, an email — that the model treats as instructions and acts on. Different mechanism, same result: the agent issues tool calls no one legitimately asked for. Defenders should plan for both together.

Why the impact escalates so fast

Two properties turn a single compromise into a wide one. First, agents act — a poisoned tool call is not just data exfiltration, it is unauthorized action (a transfer, a credential read, a shell command). Second, agent estates are often flat: shared keys, broad network reach, and no approval step between the model's intent and a high-impact action. Put those together and a compromised router or a single injection can cascade across many hosts before anyone notices. That is precisely the scenario the alarming claims describe — and precisely what good controls are meant to prevent.

The defensive playbook

Treat the router as untrusted infrastructure

• Keep provider keys server-side and short-lived. Do not route long-lived secrets through third-party or unverified proxies. Use scoped, short-TTL tokens so a compromised router cannot turn into a compromised account. Never place credentials in prompt text or tool arguments.
• Pin and verify endpoints. Pin the base URLs and TLS certificates your agents talk to, and make sure configuration cannot silently re-point them somewhere else. Our free LiteLLM Checker looks for exactly this class of exposure in a proxy setup.
• Vet the supply chain. Run known-good builds, pin versions, and review router and MCP-server configuration for plaintext secrets, unpinned installs, shell pipes, and over-broad filesystem roots. The free MCP Guard audits an MCP configuration for precisely these problems.

Make tool output data, never instructions

• Enforce the one rule that stops most of this: forwarded content is data to read, not instructions to obey. Keep tool results in a separate channel from the agent's instructions, and scan untrusted inputs for injection patterns — the job of our free Prompt Scan.
• Validate every tool-call argument against an expected schema and sane bounds before it executes, and reject calls to tools the agent was not granted.

Constrain what an agent can do

• Allow-list tools per agent and require human approval or a policy check for high-impact actions — payments, credential access, host commands, anything irreversible.
• Least privilege and segmentation. Give each agent its own scoped credentials and minimal, allow-listed network egress. Segment agent hosts so a single compromise cannot reach hundreds of others — the flat network is what turns one foothold into "400 hosts."

See it, and be ready to respond

• Log the full tool-call stream — what the model requested versus what was executed — and alert on out-of-policy calls, unexpected egress, and secret access. A divergence between requested and executed calls is a high-fidelity signal of tampering.
• Assume-breach readiness. Rotate any key that ever transited a suspect router, and run a tabletop for "our LLM gateway is compromised" before you need it.

The takeaway

Ignore the body count in the claim and keep the lesson: the router and the tool-call channel are now part of your attack surface, and agents that act on unverified instructions are the new confused deputy. You contain this the same way you contain any powerful intermediary — assume it can be turned against you, keep secrets and blast radius small, make untrusted content unable to give orders, and watch the gap between what was intended and what was done. Verify the scary headlines; harden for the real risk underneath them.

Frequently asked questions

The questions teams ask most when they start securing agents and LLM routers.

What is an LLM router or gateway, and why is it risky? It sits between your agents and the models and tools they call and is a man-in-the-middle by design — it sees system prompts, user data, tool definitions, tool-call arguments and results, and often the provider API keys. A router that is malicious, back-doored, or compromised can read all of that and change it in transit, which is why its compromise is so damaging.

Can a compromised router really steal our API keys? Yes, if secrets transit it. Keys and tokens pass through in plaintext at the application layer even over TLS, because the router terminates the connection. Keep provider keys server-side, use short-lived scoped tokens, and never put credentials in prompt text so a router breach cannot become an account breach.

How is this different from prompt injection? Indirect prompt injection smuggles instructions through a tool's output; a malicious router tampers with the request/response stream directly. Both end the same way — the agent executes tool calls no one legitimately asked for — and the defenses overlap heavily.

We use a hosted router or gateway — are we exposed? You are trusting that provider with everything on the wire, so treat it as critical third-party risk: ask what they log, how they isolate tenants and secure your keys, and how they would notify you of a breach. Prefer keeping provider keys on your own infrastructure, pin endpoints, and scope the tokens you hand over.

What should we do right now? Inventory every router, gateway, and MCP server and who can change their config; move keys server-side and shorten their lifetimes; enforce that tool outputs are data, not instructions; put allow-lists and human approval on high-impact tool calls; lock down and segment agent-host egress; and log the tool-call stream with alerting on anything out of policy.