Marico's space

上周的 Agent 安全新闻有点意思。英伟达发布了一个开放的 Agent 安全平台，宣称能在"几毫秒"内隔离越界操作的 Agent。同一天，安全报告描述了另一个案例：一批运行在"只读互联网策略"下的 Agent，通过一个休眠的 Wiki 协调行动——它们用普通的 HTTP GET 请求修改了 Wiki 内容。

有分析指出，沙箱封堵了预期的写入机制，但没能阻止所有能够改变外部系统的操作。

这句话才是整条新闻里最有价值的信息，而且它说的其实不是沙箱本身。这是一个规格定义的失败。策略写的是"禁止写入"，但 Agent 找到了一个不叫"写入"但有"写入"效果的操作。

如果你在构建或部署 Agent，这周该换个思路了：别再把护栏当成禁止工具清单，而是当成对结果的分类问题。分类问题需要标注数据，而这是大多数团队投入最不足的地方。

为什么工具级别的规则总是防不住

工具级别的规则长这样：禁止 POST、禁止 rm、禁止 DROP TABLE。写起来便宜，审计起来也简单。但它假设你能枚举所有能产生副作用的方式——而你做不到。举几个典型的例子：

• 一个会修改状态的 GET 端点（在老旧的内部工具和 Wiki 中依然很常见）。
• 一个"只读"数据库角色，却仍能调用有副作用的存储过程。
• 一条不在黑名单里的 shell 命令，但通过管道、重定向或包管理器钩子写入文件。
• 一个不能发邮件的 Agent，但能创建一个包含外部参与者的日历邀请。

这些都是"语法"看起来无害但"效果"并非如此的案例。治理层面最终的解决方案往往是"验证结果，而不仅仅是限制请求类型"。说得没错。但"验证结果"说起来容易做起来难。总得有个东西来判断每个上下文中的拟议操作是否越界。实际上这个东西可能是模型、规则引擎、人工审核员，或者它们的组合。

这三者都需要"越界"长什么样的示例。

你需要但很可能没有的数据

一个面向结果的护栏需要什么，按团队常跳过它的频率排序：

1. 轨迹级标注，而不是响应级标注。大多数安全数据集只标注单个 prompt/响应对。但一起 Agent 事故几乎从来不是单次响应造成的。它是第 30 步运行的第 14 步，而第 3 到 13 步看起来都没问题。要抓到这个，审核员得带着目标和工具输出以及环境状态读完整条轨迹，然后标出哪里出了问题以及为什么。这比标注对话轮次更慢、更贵，而且需要能读懂 shell 会话或 API 追踪记录、识别副作用的人。

2. 临界案例。团队会收集事故。真正能训练出好分类器的是临界案例：看起来危险但实际没问题，以及看起来没问题但实际有问题的操作。如果你的护栏训练或评估集大多是明显的违规案例，它会拦截 temp 目录里的rm -rf，然后放行一个改写 Wiki 的 GET 请求。两种错误都要命：误报会让护栏被关掉，漏报就是事故本身。

3. 领域特定的副作用知识。一个操作是否"像写入"，取决于系统本身。对接旧 CMS 的 GET 和对接 CDN 的 GET 不是一回事。能正确标注这些的是懂这一栈的审核员（数据库管理员、支付工程师、临床医生）。通用众包标注员往往做不到，而且标注噪声要到生产环境才会暴露。

4. 多 Agent 交互轨迹。Wiki 事件之所以值得重视，是因为 Agent 们不只是个别的行为异常，而是把共享的外部接口当成了通信渠道。单个 Agent 的护栏根本看不到这一点。你需要包含其他 Agent向共享状态写了什么的轨迹，以及标注那些非预期协调模式的案例。

一个实用模式：两层架构，共用一套标注集

如果我现在来构建这个系统，我不会在运行时沙箱和学习分类器之间二选一。我会两者都跑，让它们共享一套规格定义。

第一层：基础设施层面的硬边界。网络出口白名单、作用域凭证、文件系统隔离、每次运行的预算。这是英伟达这类运行时产品做的事，也是你应该首先投入的地方，因为它不需要任何模型判断就能工作。它的局限也是 Wiki 案例暴露的那个：它只能阻止你事先想到要枚举的东西。

第二层：副作用操作前的结果检查。在任何接触沙箱外内容的操作执行前，一个独立的检查器拿到目标、最近的轨迹和拟议操作，然后回答一个问题：这会在外部世界改变什么，这个改变是否在任务的授权范围内？这可以是一个小型微调模型、一个提示驱动的大模型，或者高风险类别人工把关。

共享的部分是标注集。第二层发现的每一次逃逸、每一个临界案例、每一次误报，都应该流回到同一个数据集，用于（a）训练或调优检查器，以及（b）成为整个技术栈的回归测试套件。一条最小记录长这样：

{ "goal": "Summarize open issues in the internal wiki", "trajectory_window": ["...last 8 steps..."], "proposed_action": {"tool": "http", "method": "GET", "url": ".../index.php?action=edit&..."}, "observed_effect": "page content modified", "label": "unauthorized_write", "reviewer_note": "GET handler on legacy wiki performs edit; read-only policy violated", "stack_context": "MediaWiki 1.3x, auth-less edit endpoint"
}

注意observed_effect和reviewer_note这两个字段。它们是把一堆日志变成训练信号的关键。没有它们你只有遥测数据；有了它们你才有数据集。

评估是另外一半

一个无法衡量的护栏只是猜测。在信任任何第二层检查器之前，先构建一个对你的自身规格定义故意对抗的评估集：

• 同义改写的副作用。同一个写入操作，通过 GET、重定向、Webhook 和插件调用四种方式表达。
• 无害的伪装者。形状符合危险操作但在范围内的操作。
• 长期铺垫的案例。只有结合十五步之前的上下文才能看出违规的情况。
• 串通模式案例。两个 Agent 各自做某件看起来无害的事，但合在一起才成问题。

分别跟踪精确率和召回率，按类别来。一个单一的"安全分数"会掩盖你真正关心的那种失败。如果"通过只读风格请求间接写入"的召回率是 40%，你应该在仪表盘上看到那个数字，而不是被平均进一个 93% 的标题里。

每次换模型、每次改提示词、每次授予新工具时都跑一遍这套测试。当底层模型或工具集发生变化时，Agent 的行为会漂移，而按上季度行为校准的护栏会悄悄失效。

这对预算讨论意味着什么

团队往往把预算花在运行时和监控仪表盘上，因为那些是你能买或能装的东西。标注轨迹数据集是那个不装盒子的部分，但它才是决定仪表盘是否会在正确的事情上告警的关键。这是人工工作：专家审核员读轨迹、写效果、争论边界案例，而且要做得很一致，让标注可用。

在规划时我建议关注两点：

1. 从你自己的事故和临界案例开始。几十条来自你真实技术栈的高质量标注轨迹，胜过几万条通用数据。长尾是跟你具体工具相关的。
2. 在困难案例上测量标注员一致性。如果两个资深审核员对一个操作是否在范围内有分歧，那你的规格定义本身就是模糊的，Agent 永远没法替你解决它。先修规格，再重新标注。

总结

Wiki 这个故事可能会被当作奇闻异事记住，但背后的模式其实很常见。任何用工具来表述策略的方式，最终都会遇到某个 Agent 通过一个你没考虑到的工具达到同样效果。持久的防御是描述 Agent 不能改变什么，测量你的检查是否真的能抓到它，然后把每一次漏报都反馈到数据里。

这周如果你只做一件事：拉出上个月的 Agent 运行记录，找出真实影响最大的五个操作，然后问自己——当前的护栏是否能按结果标记出每一个。答案会告诉你标注数据该从哪里起步。