运行第三方 Agent 前先锁定代码版本

接入一个别人开发的 AI agent，读过代码、把模型密钥留在本机，还不算完成安全审查。开发者下周推送新提交，你运行的还是当初看过的那份代码吗？原文把注意力从模型转向供应链：审批只有绑定到具体代码版本，才有明确的有效边界。

作者参与开发 agent 市场 Druve，这篇也带着产品立场。但它提出的问题值得程序员追问：自动更新、权限授权和人工审核之间，到底由谁承担变化带来的风险？

密钥留在本机，解决了哪一层问题

原文把模型提供商密钥的使用方式分成三种。

第一种，你把自己的密钥交给平台，在对方服务器上运行。此后平台是否记录、复制或妥善保管它，依赖对方的管理和承诺。

第二种，平台使用自己的密钥，再向你收取费用。作者质疑，这种方式下用户难以独立核验实际消耗，也缺少 agent 行为的独立记录。不过，原文没有具体分析平台提供账单、日志或审计接口的情况，这个判断有适用前提。

第三种，代码在你的机器上运行，使用你自己的密钥，平台不接触它。

作者更认可第三种，因为「平台拿不到密钥」可以通过系统的数据流来确认；「平台承诺不记录密钥」则需要持续相信运营方。两者提供的保证不同。

但这里要分清边界：本地执行解决的是密钥是否必须交给平台，并没有自动证明 agent 代码可靠。接下来仍要回答，它运行的代码有没有变化，以及它能访问哪些资源。

读过代码，为什么还要固定到 commit

问题出在审批对象可能会移动。

你看过某份代码并允许它访问仓库，开发者随后更新项目。如果平台自动跟随更新，你运行的代码就可能已经换了。整个过程不需要有人撒谎，也不需要发生入侵，原先批准的标识只是开始指向另一份内容。

这与 npm 依赖更新的供应链问题相似。agent 的特殊之处在于权限范围（scopes）：它可能有理由访问邮箱、代码仓库和账户。代码变化与已有授权叠在一起，影响就不只是一项功能是否正常。

固定到具体 commit，作用是把「我批准过」变成一个能核对的事实：批准的是这次提交对应的代码。

固定 commit 保证审批对象不被悄悄替换，并不保证这份代码没有问题。

它也有维护成本。开发者发布改进后，新版本需要重新审核；审核期间，已经批准的版本继续运行，不自动升级。如果审核依赖人工，就会产生队列，审核吞吐量也会限制新版获得批准的速度。

因此，评估平台时，不能只问「有没有审核」，还要问「开发者下一次提交后会怎样」。是直接更新，还是暂停新版批准？权限是否在连接前展示？有没有版本真正被拒绝过？作者尤其看重最后一个问题，因为从未拒绝任何提交的审核，可能只是一道形式手续。

我的判断

这篇最有价值的地方，是把「安全」拆成了可以追问的执行规则：密钥在哪里使用、审批绑定哪次提交、更新后谁重新确认、授权前能否看到权限。

这些问题比一个笼统的安全标识更容易验证。

但原文属于架构主张和产品经验，没有给出事故统计、审核耗时，也没有提供固定版本与自动更新的对照数据。Druve 当时只有 7 个已上线 agent。作者称，它让 agent 使用雇佣者自己的密钥，条目绑定具体 commit，编辑后暂停其审核标识，直到人工审查新版。这能说明设计意图，还不足以证明它在规模扩大后依然能高效运转。

固定版本也会延迟修复进入用户环境。持续跟随最新版减少了维护操作，却把更新风险交给用户；逐版本审核让变更可控，却要求团队持续投入审查时间。

另一个缺口是，原文没有说明依赖、构建产物和运行时下载内容如何固定。如果这些内容仍会变化，仅固定 agent 仓库的 commit，是否足以复现实际执行内容，还要继续确认。

能拿来做什么

• 给 AI 编程 agent 接入代码仓库前，记录批准的具体 commit 和权限范围，并确认更新后是否会自动沿用旧授权。
• 在 Node 项目中检查 agent 的安装与启动过程，确认是否会拉取可变的远程代码，同时核对依赖锁文件，弄清本次实际运行了什么。
• 评估 agent 平台时，要求它说明一次新版提交如何经过审核，以及被拒绝的版本如何处理，用具体流程判断审核是否有效。
• 团队采用固定版本后，应指定更新负责人，为新版审查和安全修复留出时间，避免长期停留在无人维护的旧版本。