After you put SSH keys in an Agent prompt, why an LLM relay can still sell the logs as-is

An LLM relay — also sold as an OpenAI-compatible proxy, an API router, or a “model gateway” — sits between your editor and the upstream model. Teams use one to dodge a region block, share a pooled account, or buy tokens at a discount. When your request arrives, the relay has to check your quota, swap in its own upstream key, and send the same prompt on to Claude or another model. Those three steps only work if it first terminates TLS on its hop and reads the JSON messages field, or the Agent context stuffed into it. English coverage of Shou’s 11 September post, including ChainCatcher’s write-up and Wccftech’s summary, puts the same fact in plainer words: requests and replies both pass through the relay, so the relay sees full plaintext. A Chinese security brief on the same day called any application-layer proxy without end-to-end encryption “a packet sniffer by design”; see SecRSS, “AI relay data on the black market”.

A coding Agent makes that hop worse. Cursor, Claude Code, and home-grown agents will, with the access you granted, read the workspace, scan a .env, grab terminal output, and splice those fragments into the next prompt. You do not have to paste -----BEGIN OPENSSH PRIVATE KEY----- into a chat box yourself. If the Agent pulled a private key or a deploy script because you asked it to “get onto the staging box,” those bytes are already in the body that is about to leave for the relay. An earlier paper from Shou’s group, Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain, tested 428 routers: nine rewrote the response, seventeen actually called AWS after seeing a planted test key, and one drained ETH from a test wallet. That is a separate claim — “will the relay attack you.” This article checks the quieter one: with a global log left on, the relay does not have to be malicious to keep the key you put in.

That is not the same path as “paste a ticket into a web chat.” On a chat page you at least see yourself hit paste. On a relayed Agent, the context is often assembled by tools. What you should check on this machine is not “did I type the key,” but “does this hop have a middle box that must read the body, and does that body now hold a credential you can use as-is.”

The cheapest way for a relay to debug, bill, or harvest fine-tune text is to write the unwrapped request into a database. The prompt, the system instructions, file snippets the Agent read, and tool results all stay as text fields. Selling 6TB of call data is selling that already-unwrapped history. Shou said the dump held SSH keys that could reach an intranet and glpat- tokens; public write-ups showed redacted enterprise GitLab hosts. UsePwd did not buy that dump, and this page will not treat “enough to take over company X” as a verified finding. What you can check is the mechanism: if the log stores the request body, a key that went in does not turn into stars on its own.

Neither a padlock in the address bar nor a vendor line that says “we do not train on your chats” stops this layer. When your browser or editor sends the request to the relay, TLS ends on that hop. The relay then opens a new TLS session with its own upstream account. Each wire is encrypted. The process on the machine in the middle still sees plaintext JSON. Even if the upstream model never trains on the conversation, it cannot see the copy the relay kept for itself. Whether that copy exists, and whether it is sold, is the relay’s storage policy — not a “temporary chat” toggle you flipped in the editor.

A billing log and a call body are also not the same file. Token counts, model names, and status codes cannot sell an SSH key. Once ops keep the full messages array so they can “replay that failed Agent step,” the same file is useful for debugging and useful on a black market. The reason Shou’s post spread in Chinese engineering circles is that buyers were not sold a digest. They were sold credentials that still worked. The question to ask is not “does the relay log,” but “does the log contain the prompt body.”

UsePwd Privacy Cleanup recognizes six field types in the current tab: phone, ID number, bank card, email, common tokens, and IP. The token class matches prefixes you can check, including sk-, sk-ant-, sk-proj-, AKIA, ghp_, github_pat_, glpat-, xoxb-, and Bearer . Open it and use it — no sign-up. Source text is not uploaded and is not written to analytics. Paste a sample that contains glpat- and the page keeps the prefix, masks the middle, and leaves the last four, or, in Full mask, leaves only the prefix plus stars. That step is enough to prove, on this machine, that common cloud and git-host tokens can be caught by a format rule.

An SSH private key is usually not that kind of prefix. An OpenSSH key is a PEM block that starts with -----BEGIN OPENSSH PRIVATE KEY-----, continues as Base64, and ends on a matching END line. VPN configs, kubeconfigs, database URLs, and Alibaba Cloud AccessKeys that do not look like AKIA… also slip past. Starring a phone number on a ticket does not help if the Agent already read id_ed25519 into context. Why format redaction can still point back to the same customer before you paste a ticket into a chat AI is a different article: Why format redaction still points to the same customer. That piece is about the identity layer that remains. This one is about a login that remains — and a credential in a relay log can often be used as-is.

Even a token masked as glpat-***wQ4x can, with a repo host, still narrow the search to one project. Full mask drops the last four. It still cannot drop “this chat is about that box, that cluster.” The move that actually removes a layer is to keep private keys and cloud tokens out of the prompt: write the runbook as “the secret travels on a separate one-time link,” and let the Agent see steps, not material. When a passphrase has to reach a coworker, use Burn-Link: this tab encrypts with AES-256-GCM, plaintext is capped at 32 KB, the key rides after # in s.html?id={id}#{key}, and the server only stores ciphertext. Create and read both work immediately — no sign-up.

When a ticket is pasted into a chat AI, the first risk is “can we still join this back to one person.” The phone is starred; the name, the street, and the ticket ID stay. When a relay sells Agent call logs, the first risk is “can someone still log into someone else’s system.” A GitLab token, an SSH key, and a cloud key are the login. Folding both into “we pasted something into AI” hides the order of work: on a ticket, ask whether the identity layer is still there; on a key, ask whether the body holds a credential you can use, and whether this hop has a middle box that must read that body.

After a cloud env-var leak, the rotated key should not go back into a chat window; see After a cloud env-var leak, why the new key should not go back into chat. That article is the second leak: Slack, WeChat, a ticket, or a screenshot leaves a searchable plaintext copy. This article is the first leak, and it can happen on the model-call path: you never “sent the key to a coworker.” You only let an Agent take the workspace and finish a deploy. Chat history and a relay log are not the same archive. The fix is the same — do not put a new key on a channel that keeps the body.

A URL # fragment never enters an HTTP request; see Why URL hash fragments never reach the server. Burn-Link puts the decryption key in that fragment so the machine that stores ciphertext cannot see the key. A relay is the opposite: its job is to read the body. Do not read “the burn server cannot see the key” as “no middle box can see the prompt.” The two paths have different visibility. You can check both in the Network panel.

If an Agent is allowed to read the workspace, it can splice a key into the request without you opening a chat box. YOLO mode, auto-approved shell commands, and “treat the whole repo as context” all widen that surface. The paper’s finding that some relays injected extra instructions into the response is a second, active path: the same hop can keep the key you sent and rewrite the code you get back. This site cannot check whether a given relay tampers with packets. It can only remind you that the hop you do not see may log, and it may rewrite.

A 6TB dump that already sold does not vanish because you changed prompt habits today. Shou said some of those credentials may still work. The order of work is revoke first — cloud console, GitLab, hosts, VPN — then issue new material. The new key should not re-enter Agent context, and it should not re-enter a chat window. Long-term storage or multi-device sync belongs in a dedicated password manager. UsePwd has no accounts and no vault, and it cannot recover a lost link by user. Identity is on About.

Format redaction is an aid, not a promise that nothing slips through. Review important outbound text yourself. Generate a passphrase between 6 and 128 characters in the Password Generator, then use Password Audit for local strength and the public weak-password list shipped with the page — not a web-wide Have I Been Pwned lookup. Those pages, like this article, work immediately. Do not read an HTTPS padlock, or a “temporary” label on a chat, as “there is no plaintext inside the relay process.” Wire encryption and an in-process body are not the same layer.