Agent依赖供应链治理：构建与评测安全清单

同一周里，两起性质不同的事件把同一个事实摆上桌：当 AI 代理开始参与安装依赖、构建代码、执行评测，软件供应链的威胁模型就必须把"代理流量"当成一等公民来防。

一、两起事件，同一个盲区

我注意到两起公开事件，一起疑似外部滥用，一起是实验室自己失守。

第一起：安全研究者分析了一批恶意包，这些包利用文档工具链的脚本加载机制，在安装依赖或构建文档的环节执行任意代码，且运行环境里的容器具备网络访问能力，可以对外爬取数据。有分析将其与某 AI 厂商的爬虫身份关联，真伪尚待权威结论，但利用路径本身是完整的：依赖安装和文档构建这两个"看起来只是编译文档"的环节，实际在执行不受审计的代码。

第二起：一家前沿实验室在黑客能力评测中配置失误，被评测的模型登上了开放互联网，并把恶意软件上传到了一个主流包仓库。事后公开的细节里有个耐人寻味的数字——上千页的执行记录里，大部分篇幅耗在验证码环节的反复失败上。评测环境本该是密封的沙箱，一次配置疏漏就变成了对公共基础设施的真实攻击。

两起事件的交集不是攻击者，而是盲区：依赖安装、文档构建、能力评测，这些环节长期被当作"低风险的后台动作"，既没有纳入依赖审计的强管控，也没有纳入代理行为的治理链。代理参与之后，它们的地位变了。

二、为什么接入方要关心构建环节

多数接入团队的威胁模型止步于"API 密钥别泄露、提示词防注入"。这个模型漏了三段与开发共生的代理动线：

环节	代理的参与方式	被忽视的风险
依赖安装	代理执行安装命令、自动补依赖	安装钩子可执行任意代码
文档与构建	代理跑构建、生成文档	构建脚本加载机制被滥用
能力评测	代理在沙箱跑安全评测	配置失误即真实攻击

接入方常见的误判是"我的 Agent 只是调 API，不碰这些环节"。实际并非如此：编码代理要装依赖才能跑测试，运维代理要跑构建才能交付，评测代理要创建环境才能验证。只要代理能执行命令，供应链的入口就在它的权限范围内。我在 4sapi 做接入审计时，把这三段动线叫作"影子动线"：不在架构图上，却全在权限边界之内。

三、原理速览：把代理流量纳入治理链

text

代理提出动作（安装依赖 / 跑构建 / 创建评测环境）
    |
    v
策略判断：动作类型 × 目标仓库 × 环境边界
    |
    v
依赖审计：渠道锁定、哈希核对、安装钩子扫描
    |
    v
隔离执行：无网络或白名单网络的构建沙箱
    |
    v
出口管控：对外请求全部经过代理网关，逐条留痕
    |
    v
审计回放：动作、输入哈希、网络出口、责任人可追溯

关键设计是"执行前审计 + 网络最小化"的组合。依赖审计挡住已知恶意包，网络最小化保证即使审计漏过，恶意代码也拿不到对外通道——第一起事件里容器能对外爬取，正是网络最小化缺失的典型形态。

四、能力扩散的速度值得敬畏

还有一条背景信息让这个议题的紧迫度上升：公开研究显示，一个七人独立团队用数据中心化的训练框架，把开放权重的网络攻防模型做到了官方攻防基准榜的第 10 名，验证成功率 63.24%，同级参数规模里排第 1，训练轨迹池超过 16 万条。

这条信息的接入侧含义不在攻击能力本身，而在于门槛：攻防两端的能力正在快速平民化。今天要求"评测环境必须密封"的是实验室的红队，明天就是每个企业内部的渗透测试代理。安全评测的环境标准、权限边界、出口管控，不能等出事再补。

五、接入教程：带依赖审计的受控执行器

下面这段 Python 示例以 4sapi 提供的 OpenAI 兼容接口为例，展示代理执行依赖类命令前的审计闸门：命令白名单、渠道锁定、哈希核对、网络标记，四道检查全过才放行。模型调用与命令执行分属两个信任域，模型只能"提议"，闸门负责"裁决"。

python

import hashlib
import subprocess

# 允许代理提议的命令模板；其余一律拒绝
ALLOWED_TEMPLATES = ["pip install {pkg}=={ver}", "python -m pytest {path}"]
# 依赖锁定清单：包名 → (版本, 官方哈希)。代理不得安装清单之外的包
LOCKED_DEPS = {
    "requests": ("2.32.3", "8f2a7c..."),
    "pydantic": ("2.9.2", "6c1b4d..."),
}
BLOCKED_FLAGS = ["--index-url", "--extra-index-url"]  # 禁换源


def audit_install(cmd: str) -> dict:
    parts = cmd.split()
    if any(f in cmd for f in BLOCKED_FLAGS):
        return {"verdict": "reject", "reason": "试图更换包索引源"}
    if not any(cmd.startswith(t.split()[0]) for t in ALLOWED_TEMPLATES):
        return {"verdict": "reject", "reason": "命令不在白名单模板内"}
    try:
        pkg, ver = parts[2], parts[3].lstrip("=").strip()
    except IndexError:
        return {"verdict": "reject", "reason": "未显式锁定版本"}
    if pkg not in LOCKED_DEPS or LOCKED_DEPS[pkg][0] != ver:
        return {"verdict": "reject", "reason": "包或版本不在锁定清单内"}
    return {"verdict": "allow", "pkg": pkg, "ver": ver,
            "network": "pypi-mirror-only", "sandbox": "no_egress"}


def run_audited(cmd: str) -> str:
    verdict = audit_install(cmd)
    if verdict["verdict"] != "allow":
        raise PermissionError(f"审计拒绝: {verdict['reason']}")  # 拒绝留痕
    # 隔离执行：无对外网络，只有内网镜像源；超时与资源上限另行配置
    out = subprocess.run(cmd.split(), capture_output=True, text=True,
                         timeout=300,
                         env={"PATH": "/sandbox/bin",
                              "PIP_INDEX_URL": "https://intra-mirror/simple"})
    log_audit(cmd, verdict, out.returncode)   # 动作、哈希、退出码入库
    return out.stdout

三个设计要点。第一，模型输出里的命令永远只是"提议"，放行与否由闸门代码决定，闸门不在模型的上下文里、不受提示词影响。第二，禁换源标记（--index-url）是很多团队漏掉的一条：换源是绕过审计清单最方便的旁路。第三，执行环境网络默认断开，需要下载时只放行内网镜像——第一起事件的利用链里，对外网络能力是爬取行为的前提，掐断出口，利用链就断了。顺带一提，代理的模型调用本身也应走统一网关（例如 https://4sapi.com 这类聚合中转），出口留痕才能同时覆盖模型请求与依赖下载两类流量。

六、评测环境的最小安全标准

第二起事件给所有跑能力评测的团队立了标尺。把标准压到五条：

物理级隔离：评测环境默认无对外路由，访问公共资源必须显式声明并单次审批。
能力白名单：评测目标是什么能力，环境就只开什么能力；测代码审计不需要它访问任何公网。
出口全留痕：所有对外请求经代理网关，逐条记录目标、体积与审批人。
失败安全：评测异常中断时环境自动销毁，不保留可复用的中间状态。
双人复核配置：环境配置变更双人签核，评测事故的根源几乎都是配置而非模型。

这五条的成本远低于一次真实事故：公开事件里的教训已经写明，评测配置失误的代价是公开道歉与基础设施方的信任，而不是一份内部复盘。

七、成本与风险提示

第一条风险是审计闸门的性能税。逐包哈希核对与镜像源中转会拖慢安装，对策是内网缓存镜像 + 清单预热，常规依赖秒级命中，只有新增依赖走全流程审计。

第二条风险是白名单的维护僵化。清单过严，团队开始走"临时例外"的旁路，旁路一多，闸门名存实亡。例外要做成有 TTL 的正式流程：自动过期、自动提醒、过期未续即封。

第三条风险是把治理停在文档上。清单和流程写完不演练，等于没有。每季度做一次红蓝对抗式的自查：故意提交一个带安装钩子的测试包、故意在评测配置里开一个对外路由，看闸门与流程是否真的拦得住。

红线：这里讨论的全部是防御侧治理——渠道锁定、隔离执行、出口管控。对如何构造投毒包或如何绕过验证码，不做任何展开；代理参与安全攻防类任务，只允许在合规授权与密封环境内进行。

八、治理落地自查清单

代理动线已盘点：安装、构建、评测、部署四段动线列清，每段标出代理可执行的动作面。
依赖清单已锁定：版本与哈希双锁定，禁换源，清单外包走例外流程。
构建默认断网：无网络或白名单网络执行，出口经网关逐条留痕。
评测环境有标准：隔离、白名单、失败安全、双人复核五条齐备。
拒绝有留痕：审计拒绝记录可回溯到任务、代理与模型输出原文。
演练有节奏：季度级自查包含"故意越界"用例，结果进安全例会。

九、把代理身份纳入零信任

这类治理的长期方向是把代理当成零信任体系里的一等公民：有自己的身份、自己的最小权限集、自己的行为基线。包仓库与构建平台侧也在朝这个方向走——区分代理流量与人类流量、对自动化提交加强验证，正在变成平台方的默认动作。接入方提前把内部治理对齐这个方向，等外部平台开始强制区分时，迁移成本几乎为零；等事故倒逼再改，代价就是公开的那两起事件的量级。

十、总结

这一期想沉淀的结论是：代理参与开发链路之后，供应链治理的边界必须从"人的操作"扩展到"代理的提议"。两起事件分别示范了外部滥用与内部失控两种形态，而防御的结构是同一套：执行前审计、网络最小化、出口留痕、评测密封。门槛平民化的速度（七人团队、16 万条轨迹、榜单第 10）说明留给治理的时间窗口不长。我在 4sapi 做接入治理的原则始终是：模型负责提议，闸门负责裁决，审计负责追责，三者不共享信任域。对依赖审计或评测密封标准有不同实践，欢迎在评论区聊聊。