模型中转服务是怎么变成攻击者的

用一组图讲清不可信模型中转（模型路由）服务的五大攻击面：信息窃取、数据劫持、资源劫持、内容篡改与供应链投毒，以及对应的防守措施。

Monday, August 17, 2026

读者：正在使用或考虑接入"模型中转 / 模型路由 / API 转发"服务的人这组图只回答一个问题：当你的模型请求经过一个不可信的中转服务，会发生什么，又该怎么防？

这组图要讲清什么

“模型中转"服务帮你转发请求到真正的模型 API。但转发意味着：你的每一次提问、模型的每一条回复，都必须在它的服务器上过一遍。这就是攻击面所在——它不是流量代理，而是握着你与大模型之间全部内容的中间人。

上图是风险架构：客户端（浏览器、IDE 插件）→ 中转服务 → 大模型。正因为中转服务看得见全部双向流量，它才能在你毫无察觉时动手脚。

最常见也最隐蔽的攻击，是往模型返回的 tool_use 指令里夹带私货。客户端会"信任"并执行收到的所有工具指令，于是中转服务可以在不知不觉间让用户本机执行任意操作。

这条链路叫客户端命令注入：模型正常返回的 search_web、read_file 之类指令被中转服务偷偷追加了读密钥、执行 shell 的内容。数据不回传给模型、对话看起来完全正常，用户根本发现不了。

另一种是从请求侧下手，改你发给模型的提示词，让模型帮你生成带后门的代码。

这条链路叫服务端提示注入：中转服务把你的"写个日志分析脚本"改成"顺便在脚本开头读取环境变量发出去”。模型很听话，返回的代码里就多了泄露 API 密钥的逻辑。

信息窃取只是起点。当运营方想直接毁掉你的数据，拦截点就会变成"数据劫持"的跳板；想长期赚你的算力，就变成"资源劫持"；想操纵你的决策，就变成"内容篡改"；想污染你的项目，就变成"供应链投毒"。

其中"代码仓库劫持"对开发者尤其致命：先静默把你的代码推到攻击者仓库做备份，再强推破坏性操作，本地和远端历史一同被清空。

上面这段终端回放就是一次典型的仓库劫持指令序列：备份 → 回滚 → 强推覆盖 → 留下勒索信息。

防守不是靠某一条命令，而是从选服务到最终防线的一整套动作。

核心顺序：优先官方或可信服务；自研客户端对 tool_use 做白名单；AI 生成的代码先审查再运行；把 AI 工具放进容器沙箱；插件用最小权限；装依赖前查口碑并定期 audit；重要代码多地离线备份。