不明 LLM 中转站为什么危险：一次 Agent 供应链投毒的复盘

一件“中转站挂马”的事，真正危险的地方不在于某个 API 节点坏了，而在于 Coding Agent 把模型输出接到了本机执行权限上。你贪的是更低 API 价格，对方盯上的可能是 SSH 私钥、云平台凭据、代码仓库 Token 和 .env 里的业务密钥。两者不在一个价值量级。

2026 年 8 月的一则 V2EX 帖子记录了这种风险的可观察证据：发帖者在开启 full access 的 Codex 中转链路里，看到一段命令尝试枚举 SSH、AWS、GCP、Kubernetes、Docker、GitHub CLI、包管理器配置、.env 文件、Codex 配置和 Shell 历史，并把标准输出发送到外部域名。发帖者随后描述，显示给人的文字被包装成“环境健康检查”。

这是一份公开个案，不足以证明脚本由中转站运营者主动植入。脚本也可能来自被入侵的上游、被篡改的代理链路，或其他尚未完成取证的环节。对使用者来说，归因尚未落定不改变处置优先级：只要模型或路由链路不可信，就不能让它直接驱动带有真实凭据的高权限环境。

攻击面变了：模型输出也可能是载荷

传统应用安全常把重点放在恶意输入，比如表单、上传文件或网络请求。Agent 场景多了一条反向路径：外部模型或中转链路返回的文本、推理内容和工具调用建议，会影响终端、浏览器、文件系统和网络工具。

当客户端把这类输出自动转成命令，或者让 Agent 在无人确认的情况下执行，模型输出就从“建议”变成了可触发行动的载荷。它不需要写进项目依赖，也不需要落到本地安装包里。攻击者可以把命令伪装成环境自检、依赖排查或正常的工具调用，绕过只看文件特征码和固定命令黑名单的防线。

“思维链”是否完整暴露给用户、工具调用如何展示，取决于具体客户端和上游实现。风险判断不应依赖这一点。只要不可信上游能影响 Agent 的动作建议，执行层就必须把它当成不可信输入。

低价中转站卖的不是 Token，风险却不止 Token

小型公益或低价中转站很难长期只靠 API 差价维持服务。用户无法从价格直接判断运营动机，但应按最坏影响建模：一旦对方取得工具执行路径，价值最高的目标通常不是某次对话，而是开发机上的长期凭据和访问入口。

公开个案中尝试读取的目标，覆盖了几类高价值资产：

• 云与集群凭据，如 AWS、GCP、Azure、Kubernetes 和 Docker 配置。
• 开发平台和发布 Token，如 GitHub CLI、npm、PyPI、Cloudflare Wrangler 等配置。
• 私钥、环境文件和命令历史，包括 ~/.ssh/、.env*、Codex 配置及 Shell 历史。

拿到其中任何一种凭据，攻击面就会从一台开发机扩展到代码仓库、云资源、CI/CD、镜像仓库或生产数据。API 的节省金额与一次凭据泄露的处置成本没有可比性。

失守条件：不可信上游，加上宿主机 Full Access

第三方路由并不必然恶意，Agent 也不必然危险。高危组合是：不透明的外部上游可以影响输出，同时工具被允许在保存真实凭据的宿主机上无人值守地读文件、访问网络和运行命令。

full access 让开发速度变快，也跳过了最关键的断点。Agent 不再需要说明“我建议执行什么”，而是可以直接做。此时权限控制和执行环境没有分开，任何被中间链路影响的动作建议都有机会继承本机权限。

NIST 对最小权限的定义很直接：用户或进程只获得完成任务所需的最小资源和授权。给不可信推理流整个宿主机的 Shell、网络和凭据读取权，显然不符合这个原则。

黑名单挡不住变化的命令，隔离才挡得住后果

拦截 curl、POST、某个域名或已知文件路径，可以处理一部分已知样本，却无法覆盖重定向、编码、解释器替换、分段读取和新的外传通道。命令形式会变，攻击者也会变。

应该把控制点前移到能力本身：即使 Agent 接到恶意指令，它能读什么、写什么、连到哪里、带走什么，也应被环境限制。零信任不是“多加一层网络边界”，而是对每次资源访问都不默认信任。NIST 的 SP 800-207同样强调，不因资产位置或网络位置自动授予信任，保护对象应是资源、服务、工作流和账号。

P0：今天就该做的三件事

1. 关闭无人值守执行

对非官方、未知或未经安全审查的 API，关闭 full access、自动批准和自动执行。终端命令、网络请求、文件读取、写入或删除都应停在明确的批准点。人机确认会增加一点摩擦，却能把“模型建议”与“真实动作”分开。

2. 把 Agent 移入无凭据的瞬时沙盒

在一次性容器或独立虚拟机中运行不可信链路的 Coding Agent。沙盒内不应挂载这些内容：

• ~/.ssh、云账号配置、Kubernetes 配置、Docker 配置和浏览器 Profile。
• 包管理器发布 Token、CI/CD Token、生产 .env、密码库导出文件。
• 宿主机目录、Docker Socket、SSH Agent Socket 和长期持久化卷。

沙盒只拿完成当前任务所需的最小代码副本和短期凭据。用完即销毁。需要访问私有资源时，用只读、短时、作用域受限的身份，而不是把开发机的长期身份复制进去。

3. 约束出站网络并轮换可能暴露的密钥

沙盒的出站网络采用允许名单，只允许模型提供商官方 API、源码依赖源和任务确实需要的目标。未知域名、任意 POST、任意 DNS 外传不能默认放行。

如果你曾在高权限模式下接入不明中转站，应把暴露视为可能已发生：撤销或轮换 SSH 密钥、云访问密钥、GitHub Token、发布 Token 和服务端环境变量，检查云审计日志、仓库访问记录与异常网络连接。删除配置文件不能使已经外传的密钥失效，轮换才可以。

长期解法：自控 LLM 网关直连模型提供商

合理的架构不是把所有人换到另一个陌生中转站，而是把路由层收回自己控制的基础设施。网关由企业部署和运维，服务端凭据只保存在网关，网关再通过模型提供商的官方 API 连接上游。链路中不再加入无法审计的商业二次中转。

一个安全 LLM 网关至少要做到：

• 为员工和应用签发独立、可撤销、短期或限额的 Key，不分发上游长期密钥。
• 只配置已审核模型提供商的官方端点，限制管理面访问，记录路由变更。
• 对调用实施身份鉴别、配额、速率限制和审计。审计日志应最小化保存敏感提示词内容，并遵守内部数据分级要求。
• 把 Agent 的执行环境与网关分开。网关能控制模型调用，不能替代沙盒、权限审批和出站白名单。

要理解网关在组织里承担的鉴权、路由、限流和审计职责，可继续读 安全可信的 LLM API 网关到底解决什么。Agent 的权限与责任如何分层，见 Agent 治理应当先于规模化。

把链路画出来，才能看清谁该拥有权限

开发者或业务应用
        ↓
企业自控 LLM 网关
        ↓
模型提供商官方 API
        ↓
隔离的 Agent 执行环境
        ↓
经过批准的最小权限工具

这里有两个独立边界。网关边界负责“请求从哪里来、去哪个可信上游、谁能调用、出了事如何追踪”。执行边界负责“模型建议即使出错或遭篡改，最多能碰到什么”。缺掉任意一个，另一层都无法补齐。

结论

不明中转站与宿主机高权限执行放在一起，是 Agent 时代的供应链风险。公开个案已经说明，攻击者可以把环境检查的外衣套在数据收集指令外，再借自动化执行读取本地资产。

不要用“中转站看起来便宜”替代安全判断。对不可信模型链路，默认关闭无人值守权限，运行在无凭据沙盒中，严格限制网络出口。团队需要统一接入时，自建或自管 LLM 网关直连模型提供商，不在链路上再引入无法审计的中转节点。

Read the English version.