在 AI 代理系统设计中，安全执行由大语言模型生成的代码始终是一个核心挑战。传统的实现方式依赖操作系统级进程隔离（如 Docker 容器）或直接通过 subprocess 执行命令 —— 前者需要复杂的基础设施管理，后者则存在严重的安全风险。AMLA Sandbox 采用了一种更为轻量级的方案：基于 WebAssembly 和 WASI 的沙盒架构，通过精细的系统调用拦截与虚拟文件系统隔离，实现无需 Docker 的代码执行安全隔离。本文将深入剖析这一实现的技术细节，特别是系统调用拦截机制与虚拟文件系统权限控制的核心设计。
WebAssembly 与 WASI 的安全基础
AMLA Sandbox 的安全模型建立在 WebAssembly 的内存隔离机制之上。WebAssembly 采用线性内存模型，运行时通过严格的边界检查确保程序无法访问超出其分配范围的内存区域。这种设计从根本上消除了传统内存安全漏洞（如缓冲区溢出）的可能性。与传统进程隔离不同，WebAssembly 程序无法直接访问宿主进程的地址空间，任何跨边界的交互都必须通过明确定义的接口进行。
WebAssembly System Interface（WASI）则定义了 WebAssembly 模块与操作系统交互的标准接口。与传统的系统调用不同，WASI 采用基于能力的安全模型：WebAssembly 模块不会获得隐式的环境访问权限，而是必须显式地获得对特定资源的访问令牌。在 AMLA Sandbox 中，这意味着沙盒内的代码无法直接调用底层的 Linux 系统调用（如 open、read、write 等），而是通过 WASI 提供的抽象层进行所有 I/O 操作。这一设计使得运行时可以在系统调用到达宿主操作系统之前进行拦截和审计。
系统调用拦截的实现机制
AMLA Sandbox 的系统调用拦截机制是其安全架构的核心组件。当沙盒内的代码尝试执行任何需要与外部环境交互的操作时，实际的调用路径如下：首先，代码通过 QuickJS 运行时发起 I/O 请求；该请求被转换为 WASI 的标准接口调用；随后，WASI 运行时捕获这些调用并将其转化为对宿主 Python 进程的请求；最后，宿主进程在执行实际操作之前进行能力验证和参数审计。
这种设计的关键优势在于，所有系统调用都必须经过一个明确的拦截点。在传统的安全模型中，攻击者可能通过未预期到的代码路径绕过安全检查；而在 AMLA 的架构中，由于 WebAssembly 模块只能通过 WASI 接口与外部交互，任何尝试进行文件操作、网络请求或其他 I/O 活动的代码都必须经过能力验证。运行时维护了一个异步调度器来管理这些拦截的系统调用：沙盒代码在遇到工具调用时会产生（yield），宿主执行验证逻辑后恢复（resume）沙盒的运行。这种协作式调度不仅实现了安全隔离，还保持了良好的性能特性。
值得注意的是，AMLA 当前的实现在无限循环防护方面存在一个工程权衡。由于步进限制（step limit）只计算 WebAssembly 的产生次数，而不计算 JavaScript 指令的执行次数，一个包含 while(true){} 的 JavaScript 代码会导致沙盒永久挂起而非被强制终止。对于需要更强隔离保证的场景，可能需要结合进程级别的超时机制或其他补充措施。
虚拟文件系统的隔离设计
虚拟文件系统（VFS）是 AMLA Sandbox 隔离策略的另一关键组成部分。与传统的类 Unix 文件系统不同，AMLA 的 VFS 采用显式的权限分层设计：根目录及其大多数子目录是只读的，只有 /workspace 和 /tmp 两个特定路径被标记为可读写。这种设计反映了能力安全的基本原则 —— 默认情况下所有访问都是被禁止的，只有明确授予的能力才会被激活。
在工程实现层面，VFS 的权限控制与系统调用拦截紧密协作。当沙盒内的代码尝试执行 fs.writeFile('/workspace/data.json', '{}') 时，该操作首先被 WASI 层捕获并路由到文件系统的处理逻辑；运行时检查目标路径是否位于允许的读写目录内，如果不是，则返回一个明确的权限拒绝错误（EACCES）。这种细粒度的路径控制确保了即使攻击者能够在沙盒内执行任意代码，也无法访问宿主系统的敏感文件或目录。
VFS 的另一个重要特性是其完全在内存中实现，不产生任何实际的磁盘 I/O。这意味着沙盒内的文件系统操作完全与宿主环境隔离，不会在磁盘上留下任何痕迹。对于需要处理敏感数据或临时文件的 AI 代理应用，这一特性提供了额外的安全保障。同时，由于所有文件操作都在内存中完成，VFS 的性能表现也相当优异，完全能够满足代理工作流的实时性需求。
能力验证与约束系统
在系统调用拦截和 VFS 隔离的基础之上，AMLA Sandbox 还提供了一套完整的能力验证和约束系统。这套系统超越了基本的文件系统权限，扩展到对工具调用参数的细粒度控制。开发者可以通过 MethodCapability 和 ConstraintSet 定义精确的能力边界：例如，允许调用 stripe/charges/* 但限制单次金额不超过 10000 美元，或者限制 search_db 工具只能执行以 SELECT 开头的查询。
约束系统的 DSL 支持多种验证模式，包括数值比较（<=、>=）、集合成员检查（.is_in()）、前缀匹配（.starts_with()）以及通配符模式匹配（* 表示单个路径段，** 表示零个或多个路径段）。这些约束在系统调用拦截点被求值，任何不满足约束的调用都会被立即拒绝并返回详细的错误信息。这种设计将安全策略从代码逻辑中分离出来，使得安全配置的审计和修改更加清晰可控。
综合来看，AMLA Sandbox 通过 WebAssembly 和 WASI 的底层隔离、WASI 接口层的系统调用拦截、虚拟文件系统的路径权限控制，以及上层的细粒度能力验证，构建了一个多层次的安全执行环境。这一架构在不依赖 Docker 或虚拟机的前提下，实现了 AI 代理代码的安全隔离，同时保持了良好的性能和易用性。对于需要在应用中执行不可信代码的场景，AMLA 的设计思路提供了一种值得参考的工程实践。
资料来源：AMLA Labs GitHub 仓库（https://github.com/amlalabs/amla-sandbox）、Hacker News 讨论（https://news.ycombinator.com/item?id=46824877）