北京
Modal近期发布了一份AI智能体代码执行沙箱的对比报告，覆盖了包括自家产品在内的七家服务商。这七家分别是Modal、E2B、Northflank、Daytona、Blaxel、Vercel Sandbox和Cloudflare Sandboxes。报告结果指向一个共同特征：每一家都采用云端托管模式，每一家都用容器或微虚拟机做隔离。但在权限控制这件事上，没有一家产品使用基于能力的许可模型，也没有一家产品直接在开发者的本地机器上运行。
这不算是对这些产品的批评。对于大多数智能体工作负载来说，云端执行确实是合理选择。问题在于，这件事的另一半——也就是本地化、精细化的权限控制——至今没有出现一个像样的解决方案。而这被忽略的那一半，可能比表面看起来重要得多。
所有这些工具的基本前提是一样的：不信任的代码应该跑在远离用户的地方，放在一个随时可以被销毁的环境里。这个前提在规模化场景下是对的。但对于一大类正在增长的本地工作来说，它是错的。因为智能体真正要做的那些有意思的事，往往都和你的东西有关——你的文件、你的本地数据库、你的凭证、你正在构建的应用。把这些工作扔到远程微虚拟机，意味着你必须同步上下文信息一起丢过去。这要么变成安全问题，要么变成同步协作问题，而且通常是两者同时爆发。
于是开发者面前只剩下两个都很糟糕的选项。选项一：让智能体生成的代码跑在云端，代价是失去让它真正发挥价值的本地上下文。选项二：让代码直接在本地运行，沿用操作系统默认的“环境权限”——也就是脚本被要求重命名几个文件时，它同时也能读取你的SSH密钥。因为市面上所有主流操作系统中，一个进程天然继承用户能做的一切。
隔离技术解决了第一个问题。第二个问题至今无人接招，因为它压根不是一个隔离问题，而是一个权限问题。容器回答的问题是：这段代码跑在哪台机器上？能力模型回答的问题则是：这段特定的代码现在被允许触碰哪些资源？以及，这个许可是谁做出的决定？
优秀的隔离完全可能配上一塌糊涂的权限分配。一个装着各种凭证的容器，就像一堵坚固的高墙圈住了一个什么都没上锁的房间。墙能阻止代码逃逸到宿主机，但对于已经在里面的东西被代码拿来做什么，它毫无办法。
能力模型的逻辑恰恰相反。代码启动时什么都没有——不是受限文件系统，不是只读挂载点，而是真正的零起点。随后由人或者策略，针对特定资源做一次明确授权。比如说，你可以在执行时这样指定：
krate run --grant fs.read:./secrets.txt --manifest app.toml cat.wasm -- ./secrets.txt
如果没有这个授权，同一个二进制运行同一段代码，也无法打开目标文件。它不会埋在某次系统调用深处悄然抛出一个权限错误，而是会收到一个结构化的拒止信息：某个能力被请求了，它未被授权，这里告知被拒的主体身份。
最后这个细节点，对智能体来说，价值恰恰被低估了。一个通用化的“拒绝访问”错误，只能告诉智能体“出了点问题”。而结构化的拒止信息，可以直接告诉它缺的究竟是哪种权限，这让智能体能够从拒止中恢复，或者在执行前就请求所需权限。能力模型把权限从环境的固有属性，变成了编程可见的一等公民，这才是让本地智能体安全运行的关键拼图——而它目前不在任何主流沙箱产品的路线图上。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
