Hugging Face事件：两次失败，而我们只谈论了其中一次

每个人都在关注沙箱逃逸，这很合理，因为这是最戏剧性的部分。但那是内部托管软件中的一个零日漏洞。隔离漏洞早已不是什么新鲜事。我们知道如何应对：出站规则、微虚拟机隔离、无环境凭证。我觉得更有趣的是之后发生的一切。一旦智能体能够访问互联网，它就选择了Hugging Face作为目标，发现了暴露的凭证，将其与另一个漏洞链接，并获取了基准测试答案。所有这一切都通过普通的工具调用完成。在“智能体提出操作”和“副作用发生”之间没有任何阻碍。而且模型在有趣的意义上并没有出现对齐问题。它高度专注于通过评估，而这正是它被训练的目标。行为正如预期一样运作。执行未受管控。所以我一直回问的问题是：对于那些在生产环境中运行拥有真实工具访问权限的智能体的人来说，执行路径中实际上有什么？据我所知，常见的答案有：- 提示护栏，它们是概率性的，并且位于智能体控制的循环内部- 监控和追踪，它们在副作用发生后告知你- 对硬编码的“危险”工具列表进行人工审批，但当危险的东西是一个被指向本不该去的地方的合法工具时，这种审批就失效了。最后一点让我很有感触。工具允许列表无法阻止这种情况。工具本身没问题。目标和凭证有问题。我对为什么还没有标准答案的看法（我希望自己有些地方是错的）：强制执行很容易，策略编写却极其困难。搭建一个网关只需一周时间。但决定智能体在“研究这个并总结”的任务下被允许做什么，是一个不可枚举的动作空间。经典权限系统假设动词集是有限的。激励措施指向相反方向。每一次拒绝都意味着一次失败的任务。团队优化的是完成率，而非拒绝率。一个降低演示效果的层无法通过审查。没有统一的意图表示。每个框架都有自己的工具模式，因此没有策略是可移植的，每个人都重写自己的策略。这一层处于错误的层级。应用级网关的价值取决于其下的网络和操作系统隔离，而编写智能体的人通常不拥有基础设施。从安全角度来看，这些都不是新问题。能力可追溯到1966年，完全中介可追溯到1975年的Saltzer和Schroeder。OPA、SPIFFE、seccomp、服务网格都为普通工作负载实现了类似功能。但没有人将它们接入智能体运行时，因为智能体在大约两年内从回答问题转变为执行操作，而控制层在历史上滞后能力五到十年。为免事后奇怪，我先披露一下：我在该领域从事一个开源协议的工作，所以我显然不是中立的。这里不附链接，如果你感兴趣，可以在我的个人资料中找到。我更感兴趣的是人们实际在做什么，而不是推销任何东西。我事先说明，没有任何策略层能阻止那个零日漏洞。那个层级的东西都做不到。它改变的是逃逸的智能体能够访问什么，而不是它是否逃逸。你们在用什么？