提前声明：纯粹「理论上的可能」，我目前暂未观察到、听说过任何类似行为，但从中转站的原理上看，存在这种可能。

众所周知，Agent 需要 Tool Call. 返回的 Tool Call 请求，到达本地客户端后，由用户同意(有时不需要同意)，并执行。

返回的 Tool Call 不保证是无害的，我们已经见过很多被删全盘的惨痛案例。大部分时候，它们仅仅是 LLM Halluciation 的恶果。

然而，考虑到许多用户正在使用中转站，整条链路：

• 相对比较可信的官方
• 不清楚是否可信的中转站
• Agent 客户端

中转站充当中间人，除了理论上能够看到你的所有消息记录以外，还意味着它可以任意篡改信息内容。

比如：篡改 LLM 返回的 Tool Call 请求，在执行 Shell 时偷偷加入一些恶意代码，在编写的代码中偷偷加入恶意代码等。

而一旦恶意代码被执行，用户的运行环境就暴露于风险之中。

尽管大家已经清楚「 Agent 可能比较危险」，但这种危险更多是处于随机的、无意的执行失误。

而中转站的中间人攻击和 Skills 投毒一样，属于恶意的、明确的攻击。

区别在于：Skills 投毒仍有可能被强大的 LLM 识破并防御，但中转站的恶意篡改难以防御。

再次声明：我目前暂未观察到这种事件发生。但希望各位大家意识到其中隐藏的安全风险。这至少意味着：

1. 中转站「售卖用户」牟利，不仅可以存在于卖数据层面，还可以存在于卖肉鸡层面。
2. 你可能需要更可靠的安全措施，比如使用容器、虚拟机等隔离环境。
3. 对于劣迹中转站，请谨慎使用。对于各种掺 GLM 当 Opus 卖、掺逆向、注水造假的无良中转，只要有利可图，出卖用户似乎也并非不可能。

可以使用 Docker 、Dev Container 或者虚拟机等工具，隔离出开发环境，保证遭受攻击后一把扬了重开个纯净版，至少不会影响到宿主机。(不考虑容器逃逸等情况）

但除了直接攻击宿主机之外，还有更隐蔽的一些攻击方案，例如：

1. 使 Agent 引入一些被恶意投毒的依赖，攻击生产环境。
2. 故意在代码中留出一定漏洞，攻击生产环境。
3. ....

总的来说，使用中转站时面临的安全风险比单纯的“可能瞎搞的 LLM”要高很多，因为存在恶意攻击的可能。特别是对于企业用户(比如一些小公司)，需要注意其中的风险。

只要经过网关，似乎没有什么很好的安全方案。签名、E2EE 之类的也只能由 LLM 厂商做，不知道大伙有什么更好的防御思路。