当大语言模型（LLM）被用于代码生成任务时，一个根本性的安全问题随之浮现：模型输出的代码可能是善意的功能实现，也可能是隐含恶意意图的 payload，或者因训练数据缺陷而携带安全漏洞。传统的静态代码审查难以覆盖所有隐式行为，而直接将 LLM 生成的代码投入生产环境更是一种高风险操作。为解决这一问题，研究社区提出了两条互补的技术路径：一是通过可执行预言机（Executable Oracle）验证代码行为是否符合规范，二是构建严格的运行时沙箱以遏制恶意代码的执行后果。
可执行预言机的核心思想是利用 LLM 本身或辅助模型生成可执行的测试预言（Test Oracle），这些预言本质上是基于自然语言需求或 API 文档派生出的可验证断言。以 Javadox 规范验证为例，研究表明可以为每个 JDK 方法的文档注释生成对应的检查函数，然后将其与待验证的客户端代码一起执行，通过对比实际输出与预期行为来判断代码是否符合要求。这种方法的优势在于，它将形式化验证的严谨性与自然语言需求的灵活性相结合，使得即使是非专业 Verification 工程师也能为生成的代码建立质量门禁。然而，预言机本身也可能被恶意模型操纵，因此需要与信任边界机制配合使用。
构建可靠的运行时沙箱是整个安全体系的第二道防线。SandboxEval 项目提供了 51 个精心设计的测试场景，用于评估 LLM 评估框架在执行不受信任代码时的安全表现。这些场景覆盖四大类别：敏感信息暴露（系统信息、目录结构、元数据访问）、文件系统操作（结构变更、内容篡改、权限提升）、外部通信（DNS、HTTP、FTP、SSH、SMTP 等协议的出站连接）以及危险操作（获取 root 权限、持续消耗资源、发起 DDoS 类请求、强制系统重启）。通过对这些场景的测试结果分析，可以量化当前沙箱配置的防御有效性。
在实际部署中，建议采用多层防御架构。容器层应使用 Kubernetes 的 Restricted Pod 安全标准，以非 root 用户身份运行工作负载，并配置 NetworkPolicy 实现 deny-all 出站策略，仅允许到集群内部服务 IP 的必要通信。资源限制方面，需要为每个容器设置 CPU 与内存上限，并通过 Kubernetes Job 机制为长时间运行的任务配置超时策略。文件系统隔离同样关键：建议将用户可写权限限制在 /proc 和 /tmp 目录范围内，对其他系统目录实施只读挂载，并确保 /home/root 等敏感路径不可访问。
针对不同风险等级的场景，可以采用差异化的配置策略。对于高风险场景（如直接执行外部用户提交的代码），建议启用 gVisor 或 firecracker microVM 等轻量级虚拟化方案，实现系统调用的严格过滤。对于中等风险场景（如运行模型生成的单元测试），标准 Docker 容器配合适当的 seccomp 配置文件通常足够。风险评估的核心原则是：任何执行不受信任代码的环境都必须假设代码具有恶意意图，并据此构建防御深度。
配置完成后，必须通过实际的攻击面评估来验证防御效果。建议使用 SandboxEval 提供的测试套件或自行编写探测脚本，逐一验证以下关键项：代码是否能够读取环境变量（尤其是包含密钥和凭证的变量）、是否能够访问宿主机的文件系统路径、是否能够发起出站网络连接、是否能够修改系统时间或重启主机、是否能够生成子进程并进行资源耗尽攻击。每项测试都应记录为 Accessed（成功访问）、Denied（权限拒绝）或 Unknown（无法判定）三种状态之一，以便追踪安全基线的变化。
需要特别注意的是，即使采用了上述所有措施，仍然无法实现绝对安全。模型在对抗性提示下可能生成针对特定沙箱逃逸的代码，某些系统调用可能在配置疏忽中被遗漏，而零日漏洞也可能存在于容器运行时或宿主机内核中。因此，安全配置不是一次性工作，而应建立持续监控与定期审计的运营流程。每次模型版本更新或基础设施变更后，都应重新执行完整的攻击面评估，并在 CI/CD 流水线中集成自动化安全检测环节。
资料来源：本文技术细节主要参考 UL Research Institutes 发布的 SandboxEval 论文（arXiv:2504.00018），该工作系统性地构建了针对 LLM 评估环境的 51 个安全测试场景，并为容器化代码执行环境的防御验证提供了可操作的评估框架。