这篇主要解决一个实际问题生产级 AI Agent 为什么需要 Sandbox本文从 AI 安全与沙箱隔离角度比较 Hosted 与 Self-hosted覆盖文件、Secret、网络、持久化、多租户隔离与运维责任。先给结论Sandbox 不是“给 Agent 一台机器”而是划清它能碰什么当 Agent 只能生成文字时最坏的问题通常是回答错误当 Agent 可以运行 Shell、安装包、写文件、启动浏览器、访问 API风险就从“内容错误”变成了执行边界错误。生产环境里的 Sandbox 要解决的不是“让代码能跑”而是同时回答五个问题Agent 能读写哪些文件Agent 能访问哪些网络目标Agent 什么时候、以什么权限拿到 Secret工作目录和生成文件需要保留多久不同用户、项目或任务之间是否真正隔离如果这五个问题没有独立于 Prompt 之外的确定性答案那么“请不要读取别人的文件”“不要访问生产接口”只是文字约束不是安全边界。OpenAI 当前把 Sandbox 定义为带文件系统、Shell、Packages、Ports、Snapshots 和受控外部访问的隔离执行环境并同时提供 Hosted 与 Self-hosted 两种环境模型。Anthropic 对 Claude Code 的 Sandbox 也把边界收敛到两个核心面文件系统和网络。它们的产品实现不同但背后的生产问题高度一致。Hosted vs Self-hosted先看责任边界不要先看品牌最容易犯的错是把 Hosted 和 Self-hosted 理解成“云上”和“本地”两个部署地点。真正影响架构的是谁负责创建、隔离、更新、销毁执行环境以及你的业务必须控制到哪一层。维度Hosted SandboxSelf-hosted Sandbox环境创建与生命周期平台负责你负责基础镜像与常用运行时平台预置或模板化完全自定义私有网络/VPC通常受平台能力限制最灵活特殊硬件/GPU/内部工具取决于平台最可控网络策略平台策略/allowlist你负责网络层强制Secret 接入优先用平台 Vault/Secret自建 Secret Manager/Proxy持久化平台文件/快照/挂载能力Volume/Object Storage/快照自管隔离补丁和底层运维平台承担更多团队自行承担供应商可移植性较低较高上线速度快慢基础设施控制权中高因此没有“Hosted 一定更安全”或“Self-hosted 一定更专业”的简单答案。Hosted 更适合任务主要需要标准 Linux、Python/Node、常用 CLI文件和依赖可以在任务启动时注入不需要进入公司私网希望减少镜像、调度、回收和安全补丁运维能接受平台提供的网络和环境能力边界。Self-hosted 更适合Agent 必须访问私有网络、内网数据库或自建 MCP需要公司自定义镜像、系统包或合规基线需要 GPU、特殊硬件或长期常驻工具链环境必须与现有 Kubernetes、VM、IAM、SIEM、Secret Manager 接入对数据驻留和执行审计有更严格要求。第一条硬边界不要让多个不可信工作负载天然共享同一个文件世界OpenAI 的 Self-hosted 文档明确提醒共享同一环境的 Agent 能接触相同的文件、凭证和其他资源因此应按用户或工作负载隔离。这条原则比“容器还是 VM”更基础。在多用户系统里可以先按风险从低到高设计隔离粒度per-task每个任务一个短生命周期 Sandboxper-chat / per-session一段持续工作保持同一工作区per-project同一项目共享持久文件但不同项目隔离per-user个人工作空间长期存在shared worker只有在文件、身份、Secret 和工具都能再次强隔离时才考虑。如果一个 Agent 可以执行任意命令那么 Unix 用户名、工作目录名称或 Prompt 中的“请不要访问”都不能替代真正的权限边界。第二条硬边界Secret 不应该成为 Agent 的“知识”Secret 管理是 Agent Sandbox 最容易被低估的部分。OpenAI 当前文档明确区分了“Sandbox 进程启动所需环境值”和“第三方长期凭证”。对于 Hosted Sandbox官方建议使用 Vault 方式让 Sandbox 代码看到占位值由网络代理只在批准的目标请求上注入真实凭证Self-hosted 则需要团队自己提供可信代理或服务端注入层。核心原则可以压缩成一句话模型可以决定“我要调用哪个被允许的服务”但不应该因此自动获得那个服务的长期明文凭证。原因很直接只要凭证作为普通环境变量进入执行环境Agent 生成的代码通常就有机会读取它。Prompt Injection、恶意依赖、调试日志、错误堆栈或误写 Artifact 都可能把它带出去。因此生产环境更推荐Agent → 请求意图 → Policy Gate → Secret/Network Broker → 目标服务而不是Agent → 读取长期 API Key → 任意发请求这也正好和 XBSTACK 已有的 AI Agent Policy Gate 形成上下游关系Policy Gate 判断这次调用是否被授权Sandbox/Secret Broker 决定即使模型想越界底层是否真的给它凭证和网络路径。第三条硬边界网络不要默认“全开”Hosted Sandbox 的一个重要生产能力是把网络访问做成明确策略。OpenAI 当前支持 enabled、disabled 和 restricted 三种模式restricted 模式按允许域名控制出站访问。这给出了一个非常实用的默认值纯本地代码处理网络关闭只访问固定 APIrestricted allowlist真正需要通用浏览/安装依赖临时开启更宽权限并缩短 Sandbox 生命周期。Self-hosted 也应该实现同样的语义只是执行手段可能是容器网络、NetworkPolicy、iptables/eBPF、出口代理或云防火墙。尤其要警惕“安装依赖所以必须全网开放”这种偷懒设计。包管理器下载、业务 API、浏览器访问和内部服务访问应该尽量拆成不同策略而不是共享一张无限制出口网络。第四条硬边界把“工作区持久化”和“业务数据持久化”分开很多 Agent 产品做着做着会把 Sandbox 目录直接当数据库用。短期看很方便文件都在下一轮继续读。长期问题是Sandbox 被回收以后数据是否还在Snapshot 能不能跨版本恢复哪些文件应该随环境销毁哪些 Artifact 应该长期保存谁能读历史工作区删除用户账号时哪些副本必须跟着删除更稳妥的设计是把三类东西分开1. Ephemeral Workspace临时 clone、解压目录、缓存、编译产物、可重建依赖。任务结束后可以删除。2. Resumable Workspace长任务需要继续工作的目录。可以通过 Snapshot、Volume 或受控持久目录恢复但仍然属于“执行状态”。3. Durable Business Data / Artifacts最终文档、数据集、代码补丁、用户上传原件、正式报告等应进入独立的对象存储、数据库、Git 或文档系统具备权限、版本、备份和删除策略。这能避免把“Sandbox 还活着”误当成“业务数据已经可靠保存”。第五条硬边界Artifact 离开 Sandbox 前仍要过一次出口检查Sandbox 隔离主要控制“执行环境能碰什么”并不自动保证 Agent 生成的结果安全。如果 Agent 能读取私有资料再生成一个 ZIP、CSV、PDF、Patch 或日志那么最终 Artifact 可能包含API Key 或 Token用户隐私数据环境配置和内部 URL不应该外发的源代码Prompt Injection 留下的恶意脚本过大的中间文件或缓存。因此 Artifact Export 最好也是一个显式动作Sandbox → Artifact Scanner / Policy → Durable Storage / User Download至少检查文件类型、大小、路径、敏感信息和来源。高风险场景还应记录 hash、生成任务、用户、时间和审批人。Sandbox 和 Policy Gate 不是同一个东西这两个概念很容易被混在一起。Policy Gate回答当前用户、当前任务、当前参数是否允许调用这个工具Sandbox回答即使工具被调用、代码开始执行它实际能够访问哪些计算、文件、网络和凭证Human-in-the-loop回答哪些高风险动作必须由人再次确认Audit回答最后谁、在什么上下文、通过什么 Agent做了什么生产系统通常需要把四层同时存在而不是选四选一。选择 Hosted 还是 Self-hosted一个更实用的决策树1. 是否需要访问私有网络或内部系统需要优先评估 Self-hosted或者确认 Hosted 平台是否有真正符合要求的私网连接方案。不需要继续。2. 是否需要特殊镜像、内核能力、GPU 或系统级工具需要Self-hosted 通常更合适。不需要继续。3. 团队是否愿意自己承担环境补丁、调度、回收、隔离和容量管理不愿意Hosted 更有优势。愿意而且基础设施已经标准化Self-hosted 的控制价值会上升。4. Secret 能否通过 Vault / Broker / Function Tool 留在 Sandbox 外无论 Hosted 还是 Self-hosted如果答案是“不行只能把长期生产 Key 全部塞进环境变量”架构都应该先停下来重新设计。5. 任务状态必须跨小时/跨天恢复吗如果需要必须额外设计 Snapshot/Volume/Artifact Store而不是默认依赖某个运行中的容器永远不死。OpenAI Hosted / Self-hosted 当前能说明什么截至 2026 年 9 月OpenAI 官方文档已经把两条路线的责任边界写得很清楚。OpenAI-hosted Sandbox 提供 Linux 工作区、Python/Node/CLI、文件、环境配置和网络策略当你需要自己的镜像、计算资源或私有网络时官方直接建议考虑 Self-hosted。Self-hosted 模式下Agent harness 仍由 OpenAI 运行而 executor 在你的环境里运行可以是 laptop、container 或 remote sandbox。连接是由 executor 向外建立官方同时建议把应用级 API Key 留在 Sandbox 外只把受限的环境连接凭证交给 executor。这里最值得迁移到其他平台的不是某个 API 名称而是这套责任划分托管平台管理什么你的基础设施管理什么Agent 代码实际能读到什么哪些凭证永远不进入工作区网络和文件权限由谁强制。Anthropic 的实现给了另一个重要信号减少审批不等于放松边界Anthropic 的 Claude Code Sandbox 重点强调文件系统隔离和网络隔离。它想解决的一个现实问题是如果每条 Shell 命令都让用户点击“允许”很容易出现审批疲劳。更合理的模式是先建立可验证边界再允许 Agent 在边界内更自主地工作。这意味着 Sandbox 的价值不仅是“出事时挡住攻击”还包括把大量细碎的人类审批转换成少量、稳定、机器可执行的环境策略。这对 Coding Agent、数据分析 Agent、Research Agent 和后台自动化都成立。生产环境最低 Checklist隔离是否按用户、项目或工作负载定义了明确的 Sandbox 隔离粒度一个租户是否可能读取另一个租户的文件、缓存或凭证Agent 是否能访问宿主机 Home、SSH Key、浏览器 Cookie、云 CLI 配置文件默认可写目录是否最小化上传文件是否只挂载到当前任务需要的位置临时文件、快照和最终 Artifact 是否有不同生命周期Secret长期第三方凭证是否尽量留在 Sandbox 外是否使用 Secret Manager、Vault、Broker 或服务端 Function ToolSandbox 内使用的凭证是否短期、最小权限、可撤销网络不需要联网的任务是否默认断网固定 API 是否使用域名/IP allowlist是否阻止访问云 Metadata、内网管理接口和不必要的内部服务执行是否限制 CPU、内存、磁盘、进程数和最大运行时间安装系统包、启动服务、开放端口是否需要更高权限高风险命令是否需要 Policy Gate 或人工确认持久化Sandbox 销毁后哪些状态必须能恢复最终业务数据是否已经离开临时文件系统Snapshot、Volume、Artifact 的删除和保留规则是否清楚审计能否追踪用户 → Agent → Tool → Sandbox → Artifact 的完整链路是否记录了权限决策而不仅是模型文本出现泄露或误操作后能否撤销 Secret、隔离环境并定位影响范围最后怎么选如果团队现在只是想让 Agent 安全地执行 Python、Node、Shell、处理上传文件并返回 ArtifactHosted Sandbox 通常是更快的起点。如果 Agent 必须深入私有基础设施、定制系统镜像、使用特殊硬件或者公司已经有成熟的 Kubernetes/VM/IAM/Secret/Audit 平台Self-hosted 往往更符合长期控制需求。但无论选择哪条路线真正决定生产安全性的不是“Sandbox 是谁家的”而是有没有把下面四件事做成机器强制边界文件最小权限、Secret 外置、网络最小开放、持久化与执行状态分离。这四项做好以后模型、Agent Framework 和具体 Sandbox Provider 都可以继续替换这也是为什么这个问题比某个 SDK 版本或某个 Sandbox Bug 更值得长期维护。相关内容AI Agent 工具授权怎么做Policy Gate、HITL 与逐调用权限控制AI Agent Security生产环境中的权限、提示词注入与工具风险OpenAI Agents API vs Agents SDK vs Responses APIOpenClaw 安全沙箱架构参考资料OpenAI: Sandbox AgentsOpenAI: OpenAI-hosted sandboxesOpenAI: Self-hosted sandboxesOpenAI: Sandbox securityAnthropic: Making Claude Code more secure and autonomous with sandboxing原文链接https://www.xbstack.com/ai/ai-agent-sandbox-hosted-vs-self-hosted/?utm_sourcecsdnutm_mediumreferralutm_campaignai-agent-sandbox-hosted-vs-self-hostedutm_contentoriginalrefcsdn标签#AI #实战 #问题排查 #AI Agent #Sandbox #Hosted Sandbox
