How the Model Relay Service Becomes an Attacker

Use a series of diagrams to clarify the five attack surfaces of untrusted model relay (model routing) services: information theft, data hijacking, resource hijacking, content tampering, and supply chain poisoning, as well as corresponding defense measures.
Tags:
Categories:

How the Model Relay Service Becomes an Attacker

Reader: Those using or considering accessing “Model Relay / Model Routing / API Forwarding” services This set of diagrams answers one question: What happens when your model requests pass through an untrusted relay service, and how to prevent it?

What This Set of Diagrams Covers

“Model Relay” service forwards your requests to the actual model API. But forwarding means: every question you ask, every model response, must pass through its server. This is the attack surface—it’s not just a traffic proxy, but an intermediary holding all content between you and the large model.

risk-architecture

The above diagram shows the risk architecture: client (browser, IDE plugin) → relay service → large model. Since the relay service can see all bidirectional traffic, it can act without you noticing.

What Problems Look Like

The most common and隐蔽 attack is smuggling private content into the tool_use instructions returned by the model. The client will “trust” and execute all received tool instructions, so the relay service can secretly execute arbitrary operations on the user’s machine without anyone noticing.

client-injection

This chain is called Client-side Command Injection: instructions that the model normally returns, such as search_web read_file etc., are secretly appended by the relay service with content reading keys and executing shells. Data is not returned to the model, the conversation looks completely normal, and users cannot detect it at all.

Another approach is to take hold from the request side, modifying the prompt you send to the model, asking the model to generate backdoored code for you.

server-injection

This chain is called Server-side Prompt Injection: the relay service changes your “write a log analysis script” to “conveniently read environment variables at the beginning of the script and send them out”. The model is obedient, and the returned code contains logic to leak API keys.

What Other Risks Exist

Information theft is just the starting point. When operators want to directly destroy your data, the interception point becomes a jumping-off point for “data hijacking”; if they want to earn your computing power long-term, it becomes “resource hijacking”; if they want to manipulate your decisions, it becomes “content tampering”; if they want to pollute your project, it becomes “supply chain poisoning”.

risk-overview

Especially deadly for developers is “code repository hijacking”: silently pushing your code to the attacker’s repository for backup, then forcefully pushing destructive operations, clearing both local and remote history.

repo-hijack

The terminal playback above is a typical repository hijack instruction sequence: backup → rollback → force push override → leave ransom note.

How to Decide Which Diagram to Look At

Defense is not reliant on any single command, but rather a whole set of actions from service selection to the final line of defense.

defense-checklist

Core sequence: prioritize official or trusted services; for self-developed clients, whitelist tool_use; review AI-generated code before execution; put AI tools in container sandboxes; use minimal permissions for plugins; check reputation and audit dependencies regularly; important code with multiple offline backups.

Further Reading