AI代理生成的代码存在安全风险。文章提出WebAssembly（Wasm）能通过无共享内核、轻量级运行时提供出色隔离，解决AI代码沙盒问题。Boxer工具可助开发者无缝采用Wasm，实现跨平台同构计算。
译自：WebAssembly could solve AI agents' most dangerous security gap
作者：B. Cameron Gain
AI代理生成的代码带来了一个经常被忽视的威胁：代理可能会生成未经检查的、潜在致命的命令。想象一下Hal 9000在Stanley Kubrick的《2001：太空漫游》中接管任务。虽然那是科幻小说，但与当今正在上演的真实场景相去不远：源自LLM输出的代码可以产生AI代理，这些代理可以访问敏感数据和应用程序，对环境造成严重破坏。
这是系统工程师兼WebAssembly Chicago创始人Dan Phillips在本月于巴塞罗那举行的Wasm I/O会议上发表讲话时探讨的一个场景。
代理运行代码需要隔离
Phillips阐述了为什么WebAssembly可以为不受信任的AI生成代码提供出色的隔离和沙盒。他表示，随着代理演变为代表用户执行操作的执行者，它们需要一个执行环境。
“这是因为它们不仅仅是思考——它们运行源自LLM输出的代码并生成工件，” Phillips说。“代码是确定性的，因此增加隔离为代理提供了一个核心原语。”
容器共享内核问题
目前有多种技术用于代码沙盒，但它们通常依赖于共享内核。通常，容器、gVisor安全层或Firecracker等微型虚拟机提供了一些隔离，但效率可能非常低下。Phillips表示，这些方法依赖于共享内核，具有沉重的运行时层，并增加了涉及nomads、命名空间和控制平面的编排复杂性。
“与其从内核或容器开始，不如从零开始，然后在此基础上添加。这使得某些漏洞在设计上就无法利用。”
“这在金钱、时间和理解上都很昂贵。它可能难以推断，并且启动缓慢，” Phillips说。“这些都依赖于共享内核，对吗？它们都有相对较重的运行时层；在这些之上，事情会变得像编排复杂性。”
Wasm从零开始
然而，WebAssembly为AI代理提供了急需的隔离层。这是因为它没有共享内核并使用不同的内存模型。“与其从内核或容器开始，不如从零开始，然后在此基础上添加，” Phillips说。“这使得某些漏洞在设计上就无法利用。”
WebAssembly模块，应用程序和代码通过它运行，其大小也可以小几个数量级，这是Wasm的突出特点之一。它众所周知的优势包括超快速启动时间，以及Phillips所说的Wasm实现的同构计算，即相同的代码可以在浏览器、手机、云端或家用服务器上运行。”
Boxer消除开发者摩擦
Phillips表示，尽管Wasm为AI代理沙盒提供了诸多优势，但如果开发者不了解其好处，他们通常不愿为一项新技术重写代码。开发者期望一个平台和完整的系统访问权限，即使这种访问是受限的。Phillips描述了开源项目Boxer如何允许用户将Dockerfile作为通用的可运行Wasm分发。
“对于大多数你可以用Docker完成的事情，你也可以在Wasm中完成。”
“该项目的目标是允许运行未经修改的代码，无需重写，也无需妥协，” Phillips说。“这有助于消除摩擦，使Wasm更易于访问。这基本上意味着，对于大多数你可以用Docker完成的事情，你也可以在Wasm中完成。”
Phillips表示，尽管WebAssembly具有技术优势，但它面临着“心智模型鸿沟”。开发者通常期望一个具有系统访问权限的完整平台，并且不愿重写现有代码。“人们在部署时不希望重写代码，” Phillips说。“因此，对于一项新技术，特别是那些环境受限的技术，如果他们不理解其好处，他们真的不希望采用。”
沙盒的未来超越了云，延伸到“同构计算”，在这种计算中，相同的代理代码可以在浏览器、移动设备和家用服务器之间无缝移动。“它不仅仅是云，还有同构计算，你的浏览器、云上的手机、家里的服务器都运行着相同的代码，你可以在这些不同的元素之间无缝移动这些东西，” Phillips说。
是的，开发者、平台和工程团队不希望处理潜在的不兼容性或添加“胶水”层来确保代码——无论是AI代理创建的还是其他的——保持沙盒化。但无论如何，WebAssembly已经提供了至少非常坚实的隔离级别，这对于AI代理代码的爆炸式分发来说是急需的。
对于支持者来说，这个问题变成了反问：你为什么不使用WebAssembly模块来沙盒化AI代理呢？
