缩小智能体的爆炸半径：按会话的工具许可名单 + gVisor 沙箱（开源，诚实的限制）

几天前，我在这里发布了一篇关于我的开源智能体（Chimera）的治理内核的文章。评论比原帖更尖锐——其中两条评论最终转化成了我本周发布的功能。以下介绍这两个功能及其仍存在的不足。按会话的工具许可名单。之前，任何为某次运行注册的工具都是可访问的；内核仅对每次操作进行把关。现在，每次会话都会获得明确的授权：--allow-tools read_file,grep,glob 赋予一个只读的运行权限，其余所有工具都会从注册表中移除——它们永远不会到达模型的模式，因此智能体无法被诱导调用未被授予的工具。该功能与按操作的内核配合使用（先限制授权，再对剩余工具进行把关）；子智能体会继承该设置。用于沙箱的gVisor运行时。Docker沙箱是一个普通容器，而容器并非虚拟机——容器逃逸通常利用主机内核漏洞。现在，CHIMERA_SANDBOX_RUNTIME=runsc 使其在gVisor下运行，gVisor的用户空间内核会拦截容器的系统调用，从而缩小主机内核的暴露面。它是一个即插即用的OCI运行时，只需一个环境变量，无需重写代码。诚实的限制（这个社区的成员很反感过度宣传）：许可名单默认为不受限制，以保持向后兼容——你需要主动选择锁定会话。gVisor是可选功能，需要在主机（Linux）上安装gVisor，并且它仍然不是完整的虚拟机；真正的微虚拟机才是上限。这两者都没有触及实际难题：智能体无法可靠地区分数据和指令，因此一个恶意页面诱骗它删除项目的行为可以绕过所有这些措施。这个问题已被跟踪，仍未解决——这缩小了爆炸半径，但并未关闭大门。采用Apache-2.0许可，约568个测试。仓库链接在评论中（版规要求）。这两个功能都来自上一篇文章的评论者（u/zoharel 贡献了这两个想法）。如果你已经为智能体构建了会话范围的能力授权或系统调用级别的沙箱，我想听听哪些做法在实践中行得通。