内容提要
第三方AI中转站存在严重安全风险,包括窃取API密钥、云凭证和加密钱包私钥,注入恶意代码,偷换模型和篡改命令。主流AI编程框架缺乏响应完整性验证。建议采用白名单、异常检测和日志审计,根本解决需厂商提供加密签名。
延伸解读
中转站风险的真实规模
论文团队测试了28个付费和400个免费中转站,发现9个在AI回答中注入恶意代码,17个尝试使用诱饵AWS凭证,1个清空了蜜罐中的以太坊钱包。这些不是理论推演,而是真实发生的攻击。中转站能完整看到你的请求,包括API密钥、代码和工具调用,这意味着你主动信任的中间层可能随时背叛你。
模型偷换与成本陷阱
许多中转站以远低于官方的价格出售API,背后常通过“多供应商混合调度”将请求转发给更便宜的模型,如用DeepSeek替代Claude Opus,再将结果包装返回。你支付了顶级模型费用,却得到廉价模型的答案,且难以分辨。这种模式要求中转站明文查看所有请求,进一步放大了数据泄露风险。
现有防御的局限性
论文测试了策略门禁、响应异常检测和透明度日志三种客户端防御。策略门禁能100%拦截直接改URL攻击,但无法防御白名单域名上的恶意代码;异常检测在误报率6.7%时能抓89%的直接注入,但对改名攻击和条件触发攻击效果差;日志只能事后追溯。这些方案都无法证明AI返回结果未被篡改,根本解决需厂商提供加密签名。
供应链攻击的隐蔽性
攻击者采用自适应规避,如前50次请求正常,第51次开始注入;或只针对YOLO模式和特定语言项目。LiteLLM投毒事件中,恶意代码自动扫描SSH密钥、云凭证和加密钱包。更隐蔽的是typosquatting包,如将requests改为requests,LLM审阅难以发现。这些手法表明,中转站攻击面是一整条链,而非单点。
Q&A
AI中转站具体有哪些安全风险?
AI中转站可能窃取API密钥、云凭证和加密钱包私钥,注入恶意代码,偷换模型,篡改命令。研究测试发现,9个中转站返回的AI回答中藏有恶意代码,17个中转站试图使用窃取的AWS凭证,1个中转站清空了研究人员蜜罐中的以太坊钱包。
为什么AI中转站能偷换模型?
中转站采用“多供应商混合调度”,即识别任务类型后选择最便宜的模型(如DeepSeek)来回答,然后将结果包装成用户所付费的顶级模型(如Claude Opus)的答案。这需要中转站完整查看用户请求的每一个字,从而能偷换模型并获取所有明文数据。
主流AI编程框架有响应完整性验证吗?
没有。论文测试了OpenClaw、OpenCode、OpenAI的Codex和Anthropic的Claude Code四个主流框架,没有一个内置“响应完整性验证”机制。这意味着AI返回的回答与模型实际生成的回答之间没有加密签名或校验手段来保证一致。
有哪些客户端防御措施可以应对中转站攻击?
论文测试了三种客户端防御:策略门禁(白名单命令,100%拦截直接改URL攻击,误报率1%)、响应异常检测(机器学习打分,误报率6.7%时抓89%直接注入,但对改名和条件触发攻击效果差)、透明度日志(记录请求响应并哈希,用于事后追溯)。这些只能减少暴露,不能根本解决。
如何从根本上解决AI中转站的安全问题?
根本解决方案需要AI厂商在API返回中加入加密签名,让客户端能验证工具调用确实出自声称的模型且未被篡改。论文建议厂商签名一个包含模型名、工具调用、请求随机数和有效时间窗口的JSON对象,客户端在执行前验签。目前OpenAI、Anthropic、Google的API均未提供此机制。
中转站攻击和传统中间人攻击有什么不同?
传统中间人攻击需要伪造TLS证书,而AI中转站攻击中,用户主动配置并信任中转站,自愿将流量送过去。安全从业者指出:“一旦你信任了中间层,你就已经放弃了控制权。”攻击者无需伪造证书,因为用户自己交出了钥匙。