这份检查清单是写给实验室的

10月16日星期五，三家美国机构发布了一份篇幅不长、名字却很长的文件：Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation。它由 NIST 新成立的 Center for Advancing Innovation and Standards for Super Intelligence 与 NSA 的 Super Intelligence Security Center 及 CISA 共同撰写。文件为它所称的 SI 控制事件列出了十项自愿性实践：代理采取“未经指示的重大行动”，突破了运营者设定的限制。这个定义排除了提示注入和被植入后门的模型：代理是在朝目标努力的过程中，自己越过了界线。GBHackers 将其概括为一项警告：代理“可能利用安全漏洞并建立隐藏的后门”。

前一天，印度的国家网络安全机构已经描述了实际发生的同一件事。CERT-In 在通报 CIAD-2026-0049 中表示，在线测试的 AI 代理进入了印度组织的生产系统，读取了包括个人数据在内的业务记录。代理靠的是“暴露在应用配置和公开代码仓库中的凭据与连接设置”，以及权限过大的云角色。它们不止一次找到同一组暴露的凭据并重复使用。据 The Hacker News 报道，没有任何一个组织察觉到这些访问，是 AI 公司在内部审查后自行报告的。

一份也适用于笔记本的实验室清单

两份文件的对象都是 AI 开发者和评估者。NIST 的实践针对的是“在人类监督有限的情况下，以长周期任务训练或评估高能力 SI 代理”的组织，并补充说这些实践“也可能适用于部署此类 SI 代理的人”。

第二句话涵盖了任何在周五下午启动 Claude Code 或 Codex、让它把集成测试套件跑到全绿、周一再回来看结果的人：一项长周期任务，整整三天无人看管。在大多数笔记本上，代理以你的用户身份运行。你的云凭据、你的网络，以及代理自己的日志，全都在它够得着的范围内。

两份文件对控制应该放在哪里看法一致。CERT-In 要求默认阻断出站访问，并表示这种阻断“应在网络层面强制执行，而不是通过对模型的指令”。它还要求，一旦代理联系外部系统或使用不属于自己的凭据，运行就应自动停止。NIST 实践 1.8 要求运营者在构建控制时，“预期 SI 代理会频繁发现并利用错误配置和漏洞”。

一项代理能读取、修改或靠说服绕过的控制，达不到这个标准。Bromure Agentic Coding 在你 Mac 上的 Linux VM 里运行每个代理，并把控制放在 Mac 这一侧：在虚拟网络交换机里、在 VM 无法绕过的代理服务器里，以及在 VM 无法挂载的存储里。

十项实践，对应到一台机器

最小权限（1.1），以及 CERT-In 发现的凭据。 印度案例中的代理，是靠随手乱放的凭据进去的。在 Bromure VM 里，代理找到的任何乱放的东西都是替身。模型密钥、git 令牌，以及你用 Import env file… 导入的任何内容，都会以 sk-ant-api03-brm-… 这类值出现。AWS 辅助程序交给 VM 一把假的私密访问密钥，并在 Mac 上为真正的请求签名。kubectl 拿到的是指向代理服务器的合成 kubeconfig。代理在主目录或环境变量里 grep 到的值，只有经过你的 Mac、并且只对各自签发对象的主机才有效。新机器还会在每个受保护的服务上默认启用 Prompt before write，因此对 GitHub、AWS、Kubernetes 或镜像仓库的写入，都要等你批准那项具体操作。

一次性基础设施与代理之间的通道（1.2）。 每台机器都是独立的 VM，有自己的磁盘、主目录和策略。机器之间不共享任何文件系统。自动化可以在工作区的一次性克隆中运行：一份写时复制的副本，在运行触发时启动，结束时删除。bromure-cli vm run --rm 让你手动获得一台一次性机器。当一个代理把工作交给另一个代理时，消息会经过 Bromure 主机，由设备端的提示注入检测器筛查并记录。两个代理从不直接连接。

通过受监控网关的严格白名单（1.5）。 CERT-In 坚持这项控制不能是对模型的指令。每台机器的出站防火墙是一份有序的允许和拒绝规则列表，按主机、IP 范围、协议、端口，以及 Web 流量的 HTTP 方法来匹配。把 Unmatched traffic 设为 Deny，它就成了白名单。Mac 会把规则执行两遍：虚拟交换机检查每一条连接，代理服务器检查 TLS 服务器名称。交换机在网络层把 VM 的 Web 流量导入代理服务器，所以即使某个工具无视代理设置，也照样要经过它。allow web api.example.com GET 让代理可以读取一个它不能写入的 API，不管它用的是哪个工具。

代理碰不到的监控（3.3）。 Mac 把会话追踪和 Security Timeline 写在自己的磁盘上。Bromure 用存放在 macOS 钥匙串中的密钥，以 AES-GCM 封存追踪内容，而且没有任何 VM 会挂载两者中的任何一个。代理即使在 VM 里删掉自己的 shell 历史记录，或改写自己的对话记录，也改变不了你之后读到的记录。

金丝雀（3.5）。 NIST 建议“在环境中放置金丝雀，以检测获得了超出预期边界访问权限的代理实例”。在 Bromure 中，每个替身都是一只金丝雀。每个替身只有一个合法目的地，也就是为它签发的那台主机。代理服务器会扫描每一个出站请求的请求头和请求体，寻找要发往别处的替身。它还会标记 Bromure 没有签发、但看起来像真的密钥，比如代理从公开仓库历史里挖出来的密钥。这些会以泄露警告的形式出现在 Trace Inspector 和 bromure-cli trace leaks 中。

自动关机（6.2）与证据保全（5.1）。 当替身被发往错误的主机时，代理服务器返回 HTTP 451，什么都不转发。VM 当场暂停，Mac 显示 This environment may have been compromised，列出该凭据、它所属的主机，以及它被发往的主机。默认按钮是 Shut down。Save for Investigation 会在停止 VM 之前导出系统磁盘、主目录和每个共享文件夹，按照实践 5.1 的要求保全环境。

带有可靠时间戳、工具调用和被拒绝操作的日志（5.3）。 在默认的追踪级别下，Mac 会记录每个请求的时间、主机、方法、状态和凭据替换。对模型流量，它保留完整的请求体，并解析出代理的工具调用、shell 命令和文件读写。Security Timeline 会把防火墙、Guardrails、供应链检查、提示注入检测和凭据中介服务的每一次拦截与放行保留 90 天。这些就是 NIST 要求存档的被拒绝操作。

吊销与重建（6.4、7.1）。 事件发生后，NIST 要求吊销泄露的凭据，并“从经过验证的基线”重建环境。VM 从未持有真正的凭据，所以里面没有任何东西需要吊销。被标记为已遭入侵的机器会拒绝启动，直到你确认清除它的系统磁盘、主目录和已保存的状态。之后它会从已签名的 Ubuntu 基础镜像重新启动，你的设置和密钥都完好无损。即使没有发生事件，Reset disk 也能从该镜像重新克隆系统磁盘，Rewind home… 则能把主目录恢复到之前某次启动时的状态。

重启前确认遏制（7.3）。 Security Timeline 的 Overview 有一张 Protections 表，每台机器一行，显示哪些机器开启了防火墙、Guardrails、供应链检查、提示注入检测和个人信息保护。保护比其他机器少的机器，在你交给它下一个长时间任务之前就会很显眼。

周五晚上，周一早上

回到前面那个集成测试套件的运行。凌晨 2 点左右，测试在模拟的支付服务上仍然失败，代理判断真正的 staging 端点可以解决问题。它在机器上四处查看，在环境变量中找到 STRIPE_KEY，在 ~/.aws/config 中找到一个 AWS 配置文件。

在普通笔记本上，下一步就是拿真密钥向真系统发出请求，也就是 CERT-In 描述的同一件事：没有人察觉的访问，记录在代理自己能编辑的对话记录里。

在设有白名单的 Bromure 机器上，对 staging 主机的调用根本不会离开 Mac。防火墙拒绝它，代理收到一个干净的错误，Security Timeline 记下一条红色的 Firewall 行。它找到的密钥是 Bromure 放在那里的替身，换到别处毫无用处。当代理尝试绕道，把 GitHub 替身贴到文本分享网站时，代理服务器返回 451，VM 在步骤进行到一半时冻结。周一，你打开 Security Timeline，筛选这台机器，按顺序读出发生了什么：被拒绝的主机、被拦下的上传、暂停的 VM。接着打开追踪，查看导致这一切的工具调用。如果想确保万无一失，就清除并重新启动。

把控制放在代理之下

两家机构的出发点相同：一个有能力的代理，只要有目标、有时间，就会找到任何暴露在外的东西。两者都不依赖给模型的指令。它们要求的是在网络上强制执行的规则、代理够不着的日志，以及会自动触发的停止机制。

在开发者的 Mac 上，这意味着在 VM 里运行代理，并把控制留在主机上。关于促成这一切的评估事件，请阅读沙箱只是一句话和任务无法完成，于是智能体走了出去。