Error, stated plainly: a security researcher tested 428 LLM API relay stations. Nine injected malicious code. Seventeen used researcher-planted test keys to call AWS. One moved ETH it was never authorized to touch. Those are not theoretical risks. Those are observed behaviors, logged in a paper submitted for review.
The same researcher — Shu Chaofan, co-founder of blockchain security firm Fuzzland — now claims to have purchased 6TB of relay-station logs containing SSH keys, VPN configurations, Alibaba Cloud credentials, and GitLab tokens. He says the data provides access to 19 enterprises and 7 government-affiliated institutions. Huawei, Xiaomi, NIO, and MiniMax are named.
I have not independently verified the 6TB figure. Neither has anyone else. That distinction matters more than the headline.
An LLM API relay station is a middleman. A developer who cannot reach Claude, GPT, or a comparable model directly — for reasons of region, payment friction, or cost — routes requests through a proxy. The proxy terminates the connection, forwards the prompt, receives the response, returns it. Cheap. Convenient. Structurally identical to a man-in-the-middle attack, except the user consents.
This architecture is not new. What is new is what users put inside the request. In 2020, I simulated Compound's liquidation mechanics against historical Ethereum block data and found an oracle latency edge case that arbitrageurs could exploit during volatility. The lesson was not that oracles fail. The lesson was that any system assuming a clean external input is running on an assumption, not a guarantee. The relay station is that assumption wearing a business model.
Here is the mechanical failure. When a developer wires an agent — a coding assistant, a deployment bot, an autonomous workflow — the agent's context window frequently carries operational credentials. This is not sloppiness at the margins. It is standard practice. The agent needs to push to GitLab, so the GitLab token sits in the context. It needs to provision infrastructure, so the Alibaba Cloud key sits in the context. It needs to reach an internal host, so the SSH key sits in the context.
The relay station sees the plaintext. Not because it cracked anything. Because the user handed it over.
If the relay retains logs — and retention is the default in most proxy infrastructure, not the exception — the credentials are captured. If the relay sells those logs, the credentials are transferred. The chain from "developer typed a prompt" to "third party holds a valid SSH key" requires no exploit. It requires only that two events occur on the same server: a request passes through, and a log is stored.
The paper's numbers convert this from abstraction to evidence. Of 428 relays tested, 9 actively injected code. That means the relay altered the response before returning it — the user asked one thing, received another, and had no integrity check to detect the substitution. Seventeen relays used keys the researchers planted, reaching out to AWS they were never provisioned to touch. One drained ETH. At a 9-of-428 injection rate, the base rate of malicious behavior is roughly one in fifty.
Apply that to the claimed 6TB. The researcher asserts the logs grant access to 19 enterprises and 7 government-linked bodies. I flag the claim as unverified. But I also flag the arithmetic it implies: if a single relay can log one developer's SSH key, then 6TB of aggregated logs across hundreds of relays is a credential corpus, not a dataset. The unit of risk is not the enterprise; it is the individual key still inside its validity window.
The bullish read — the angle most analysts missed — is that the relay ecosystem is not a fringe. It exists because legitimate access is priced and gated out of reach for small teams. Relay stations are a market response to friction, and markets correct friction before regulators do. That is real. Dismissing the entire category as criminal ignores why developers chose it.
But the researcher's framing has a blind spot he did not address. "Can access" is not "has accessed." Possessing a valid key and using it against a live system are different legal and technical events. A 40-page report I drafted on Compound's oracle risk was dismissed as theoretical — until it wasn't. I learned to separate the mechanism from the claim. The mechanism here is sound: MITM architecture captures plaintext, agent contexts carry credentials, logs persist. The claim — 19 enterprises, 7 agencies — rests on one party's assertion, with no disclosed sample, no named relay, and no enterprise response. Code is law, but logic is the jury.
There is a second blind spot. Purchasing that 6TB may itself violate data security statutes and computer crime provisions. The researcher may hold evidence gathered through a legally ambiguous transaction. And naming companies like Huawei and NIO before verification carries reputational cost no retraction fully reverses. Protocol integrity is binary; trust is a variable. The claim, right now, is a variable.
The immediate action is not debate. It is rotation. Any team that has passed credentials through a third-party relay should assume exposure and rotate SSH, cloud, and source-control keys now. Audit which agents carry long-lived secrets in context — that is the actual vulnerability, and it predates this story.
The forward question is whether the industry treats relay trust as a configuration problem or a structural one. Recovery is not a phase; it is a reconstruction. The relay model cannot be patched into safety while it retains plaintext by design. What changes is whether enterprises stop relying on design.
