智能体执行沙箱怎么建：隔离代码、文件与网络访问

智能体生成的代码不能因为“只是完成一个任务”就直接在应用服务器上运行。可行的做法是把每次执行视为不可信作业：先限定它能用多少计算资源，再限定它能读写哪些文件、连接哪些网络目标，最后销毁执行环境并检查结果。智能体沙箱限制的是执行时的能力，不能替代调用工具前的权限审批，也不能替代对高风险操作的人工复核。

先划清沙箱的边界

设想一个智能体需要读取用户上传的表格、运行脚本并生成报告。它应当能读取这份表格、写出报告，却不应看到其他用户的文件、应用密钥或企业内网服务。风险不只来自“恶意代码”：模型可能误解任务，上传内容也可能诱导它调用不该用的工具。只约束模型提示词，无法保证最终执行的程序守规矩。

因此，设计沙箱时要分别回答四个问题：代码在哪里运行？文件从哪里来、写到哪里去？请求能发往何处？任务结束后还会留下什么？任何一项没有边界，其他隔离措施都可能被绕过。

沿执行链路设置防护

运行前：选择隔离强度并收紧权限

不同方案的取舍，关键在于代码可信度和租户之间的隔离要求，而不是单看启动速度。

无论选哪一种，都不要让执行作业继承应用服务账号的权限。使用非特权身份，限制 CPU、内存、进程数和运行时长；只提供任务必需的工具与短期凭据。尤其不能把宿主机管理接口、容器管理套接字或长期密钥交给作业。容器是隔离手段，不是“启动一个容器就安全”的保证。

运行中：把文件和网络都改成“按需提供”

文件系统宜采用一次性根环境：输入文件由服务端筛选后放入指定只读目录，输出只允许写入单独目录，并限制大小、数量和类型。不要把宿主机工作目录、用户资料库整体挂进去。服务端收取结果时，还要检查符号链接、路径跳转和异常文件类型；“只允许写某个路径”不能仅靠检查字符串前缀实现。

网络出口控制应默认拒绝，再为确有需要的任务开放明确目标。若代码需要访问外部 API，可通过受控代理转发，并在代理处校验目标、记录请求及限制流量。校验不能只看最初输入的域名：还要处理 DNS 解析结果、重定向，以及对内网地址和云环境元数据地址的访问。若任务根本不需要联网，关闭网络出口比维护一份宽泛的允许名单更容易验收。

这些限制必须在代码运行的环境或其外侧网络边界执行，而不是只写在智能体的工具说明里。智能体可以决定“想做什么”，但不应自行决定“被允许做什么”。AWS 的智能体沙盒实践说明也将独立文件系统、资源限制和任务结束后的清理列为执行环境的组成部分；具体产品能力与配置方式仍应以部署时的官方文档为准。

运行后：销毁环境，谨慎接收产物

任务完成、超时或被取消，都应走同一套收尾流程：停止作业及其子进程，撤销临时凭据，销毁临时文件系统，回收网络规则和资源配额。输出文件应先进入待检查区，验证格式、大小及归属后再交给用户或后续系统。日志只保留排障和审计所需的信息，避免把输入数据、令牌或完整敏感文件写入日志。

环境清理不能只依赖智能体主动“退出”。执行服务还需要独立的超时与回收机制，处理进程卡住、控制服务重启等情况。

用越权测试完成安全验收

验收的重点不是证明正常脚本能跑，而是证明越界请求会失败，并且失败可被观察到。可在不使用真实密钥和生产数据的测试环境中，准备以下用例：

• 进程与资源：脚本持续运行或大量创建子进程时，能否按配额终止？终止后是否仍有残留进程？
• 文件：尝试读取未授权目录、通过符号链接访问目录外文件、写入非输出目录时，是否被拦截？其他任务能否看到本次临时文件？
• 网络：访问未授权公网目标、内网地址和元数据地址，以及经重定向到这些目标时，是否均被拒绝？拒绝记录能否对应到任务？
• 凭据与产物：作业能否读取应用服务的环境变量或长期密钥？输出目录中的异常文件是否会被直接发布？
• 生命周期：正常结束、超时、取消和异常退出后，环境与临时授权是否都能回收？

开发测试阶段可以先用最小权限的进程或容器跑通这些用例，再逐步增加真实工具；生产环境则要结合多租户风险选择隔离强度，并把上述测试纳入版本变更验收。通过一次测试不代表永久安全：基础镜像、运行时、网络策略或挂载配置变化，都可能改变实际边界。

软盟资讯观察

智能体开始承担写代码、处理文件和调用外部服务等任务后，执行环境会从辅助组件变成部署的基本条件。机会在于把隔离、配额、出口策略和审计做成统一能力，让业务团队不必为每个智能体重复搭建；但它的价值应由越权测试和故障处理能力证明，而不是由“沙箱”名称证明。

需要警惕的风险是边界错位：代码被关进容器，容器却拿到了生产密钥；网络配置了允许名单，代理却放行重定向；任务结束删除了工作目录，子进程仍在运行。隔离失效往往发生在这些连接处。技术负责人应明确由谁批准高风险工具调用、谁维护出口规则、谁检查执行日志。沙箱负责把越权行为挡在执行层，权限审批与人工复核仍负责判断任务本身该不该做。