AI 代理系统的核心痛点之一是执行不可信代码的安全性。传统的 subprocess 调用或 exec () 方法直接让代理生成的代码在主机进程上运行，一旦出现提示注入攻击，整个系统就面临被攻陷的风险。虽然 Docker 等容器方案提供了进程隔离，但其需要运行 Docker 守护进程、管理镜像和网络配置，开销较大且部署复杂。amla-sandbox 项目提出了一种基于 WebAssembly 的轻量级沙箱方案，通过 WASM 的内存隔离特性和 WASI 的受限系统接口，实现了无需 Docker 的代码执行隔离。其核心设计目标是让 AI 代理只能调用明确提供的工具，并在参数层面进行约束，从而在保证代码执行效率的同时建立严格的安全边界。
amla-sandbox 的隔离机制建立在 WebAssembly 的三层安全模型之上。首先是内存隔离：WASM 采用线性内存模型，所有内存访问都必须经过边界检查，任何试图读写线性内存边界之外的字节都会触发运行时异常，这从根本上阻止了内存越界访问和地址空间布局随机化绕过。运行时环境 wasmtime 采用了纵深防御的设计，并通过了形式化验证，从编译器和运行时两个层面保证了内存安全性。其次是能力边界：WebAssembly 模块默认没有任何与外部环境交互的能力，所有对文件、网络、设备等资源的访问都必须通过显式的导入（imports）实现，这种设计源自能力安全（capability-based security）的理念，遵循了 seL4 等安全微内核的访问控制原则。最后是系统调用约束：项目使用 WASI（WebAssembly System Interface）作为唯一的系统调用接口，WASI 只暴露了经过筛选的文件系统、时钟、环境变量等有限 API，拒绝提供原始网络套接字、进程管理等高危系统调用，从而将攻击面压缩到最小。
在进程隔离层面，amla-sandbox 并未采用传统操作系统的进程模型，而是在 WASM 运行时内部实现了协作式多任务调度。沙箱代码运行在同一个主机进程内的 WASM 实例中，无法创建子进程或执行外部命令。所有需要与外部资源交互的操作（如调用工具、读写网络）都会触发一个「yield」操作，将控制权交还给 Python 主机。主机在收到暂停信号后，会进行能力验证：检查调用者是否被授权调用该工具、参数是否符合约束（如金额上限、SQL 查询前缀检查等），验证通过后才会代为执行操作并返回结果。这种设计将进程隔离从内核级别下移到语言运行时级别，虽然隔离强度不如独立进程，但完全消除了进程创建和上下文切换的开销，首次编译仅需约 300 毫秒，后续加载缩短至 0.5 毫秒。对于 AI 代理工具调用的场景 —— 通常是执行一段脚本完成多个 API 调用或数据处理 —— 这种轻量级隔离在安全性和性能之间取得了良好的平衡。
文件系统虚拟化是 amla-sandbox 隔离模型的另一个关键组件。项目实现了一个虚拟文件系统（VFS），其目录结构遵循严格的权限分层设计。根目录及其大多数子目录被标记为只读，沙箱内的代码无法创建新目录或修改现有文件。只有两个区域开放了写权限：/workspace 目录用于存放用户数据，/tmp 目录用于临时缓存。这种设计是通过 WASI 的预打开（preopens）机制实现的，主机在初始化沙箱时会将这两个目录映射到 WASM 实例中，并设置相应的访问标志位。任何尝试在根目录创建文件或修改配置文件的操作都会触发 EACCES 权限错误，有效防止了代理代码篡改系统文件或植入后门。对于需要持久化的场景，项目推荐通过工具 handler 在主机层面处理，或利用只读目录中预置的配置文件模板。
与系统调用拦截相比，amla-sandbox 的方案更加激进：它不是过滤允许哪些系统调用，而是完全替换了系统调用层。传统的 seccomp-bpf 方案在内核层面拦截系统调用，根据预定义的规则白名单决定放行或终止进程，这种方式需要维护复杂的规则集，且内核漏洞可能导致沙箱突破。amla-sandbox 则从根本上拒绝让沙箱代码直接接触 Linux 系统调用表，所有可能的「系统调用」都通过 WASI 翻译为主机进程的普通函数调用。例如，沙箱内的 fopen () 不会触发内核的 openat 系统调用，而是调用 wasmtime 运行时封装的文件访问函数，这些函数在进入内核之前就会接受能力检查和参数验证。这种设计将安全策略的执行点从内核移到了用户空间，虽然牺牲了部分灵活性，但显著降低了攻击面并简化了审计流程。
工程化落地时，需要注意 amla-sandbox 的适用边界。它不提供完整的 Linux 环境，不支持原生模块加载，无法访问 GPU，且对于无限循环的保护机制依赖于步进限制（step limit），该限制只统计 WASM yield 点而不计算 JavaScript 指令计数，因此纯计算循环仍可能导致沙箱挂起。对于需要持久化状态、复杂依赖或高性能计算的场景，e2b 或 Modal 等基于 microVM 的方案更为合适。amla-sandbox 的设计哲学是针对 AI 代理工具调用的常见模式：在受限环境下执行生成的脚本代码，调用少量受控 API 处理数据，最终返回结果。其配置示例如下：创建 Sandbox 实例时传入 capabilities 列表，使用 MethodCapability 定义方法模式（如 stripe/charges/*），通过 ConstraintSet 设置参数约束（如 amount <= 10000，currency 仅限 USD 或 EUR），并通过 max_calls 限制调用频率。主机侧的 tool handler 只需实现业务逻辑，所有安全检查由沙箱层自动完成。
综合来看，amla-sandbox 代表了一种新型的代码执行隔离范式：利用 WebAssembly 的语言级别隔离替代传统的进程隔离，利用 WASI 的受限接口替代系统调用过滤，利用协作式调度替代内核调度器。这种设计在轻量级、可移植性和安全可控性之间找到了独特的平衡点，特别适合 AI 代理场景下频繁、小粒度的代码执行需求。
资料来源：GitHub - amlalabs/amla-sandbox (https://github.com/amlalabs/amla-sandbox), Hacker News 讨论 (https://news.ycombinator.com/item?id=46824877)