Docker Sandboxes Hands-On Guide – A Safe Space for AI Agents!

Docker Sandboxes 的核心安全理念与 AI 应用背景

Docker Sandboxes 旨在为 AI Agent 提供一个安全且非破坏性的工作沙盒环境。与让 Agent 直接访问宿主机原生系统不同，该工具允许 Agent 在受限环境中执行操作，从而解决当前 AI 安全领域关注的核心问题：如何平衡 AI 的能力与系统访问权限。随着 Claude Mythos 等模型的出现，利用 AI 进行网络安全成为热点话题，但随之而来的是对 Agent 在运行系统中拥有何种访问权限的担忧。Docker Sandboxes 的设计初衷正是为了解决这一矛盾，它赋予 Agent 充分的自主权，同时通过沙盒机制确保这些操作不会危害宿主系统。

"This is designed by nature to actually allow our agents to autonomously perform all of the actions that they otherwise would want to were they in a dangerously skip permission state."

这种架构引入了类似 "YOLO 模式" 的概念，即允许 Agent 在无需人工逐条审批的情况下自主执行任务。对于频繁使用 AI Agent 的用户而言，每次操作都需手动点击批准不仅繁琐，而且降低效率。Docker Sandboxes 通过设定明确的访问边界，让用户成为“护栏”，既解放了人力，又确保了操作的安全性。这种设计特别适用于需要 Agent 自动执行复杂任务，但又不希望其拥有宿主机完全控制权的场景。

Mac 环境下的安装流程与依赖处理

本指南以 Mac 系统为例，演示 Docker Sandboxes 的快速搭建过程。虽然官方文档显示支持 Windows 和 Linux，但 Mac 用户需特别注意 Homebrew (brew) 依赖问题。安装命令非常简单，主要涉及两个步骤：首先确保系统安装了 Homebrew，然后运行 Docker 提供的安装脚本。如果终端提示 brew: command not found，用户需访问 brew.sh 网站，复制并执行单行安装命令以完成前置依赖配置。

值得注意的是，使用 Docker Sandboxes 并不需要预先安装 Docker Desktop，这一设计简化了安装流程，降低了资源占用。在成功安装 Homebrew 后，用户只需从 Docker 官方页面复制安装命令并在终端执行，系统会自动处理剩余的安装过程。安装完成后，终端将显示 SBX was successfully installed 的提示，标志着沙盒环境已就绪。整个过程无需复杂的配置调整，体现了该工具在易用性上的优势，适合希望快速上手 AI 安全沙盒技术的开发者。

身份认证与网络策略配置详解

安装完成后，用户需通过 sbx login 命令进行身份认证。该过程涉及 一次性设备确认码 验证：终端会生成一个代码，用户需在默认浏览器中打开对应页面，输入该代码并登录 Docker 账户，随后终端将显示登录成功状态。认证通过后，系统会引导用户配置 网络策略 (Network Policy)，这是控制沙盒内 Agent 网络行为的关键环节。

Docker Sandboxes 提供了从最开放到最严格锁定的多种网络策略选项，用户可根据需求选择：

"Balanced is default deny, but it has an allow list for a bunch of common things that would be related to what the agent in our sandbox may specifically need."

Balanced 策略是推荐默认选项，它在确保安全的同时，预置了对 AI 代理常用资源（如 API 调用、软件包管理）的访问权限。用户还可以根据具体需求自定义修改策略，通过精细化的网络控制，进一步加固沙盒的安全性。这一配置步骤确保了 Agent 在享受自主执行能力的同时，不会因网络访问失控而引发潜在风险。

安全策略配置与默认选项选择

在构建 Docker 沙箱环境时，首要步骤是确定网络访问的安全策略级别。系统提供了多种选项，包括仅允许特定域名的白名单模式，以及彻底锁定所有出站流量（包括模型提供商 API）的严格模式。后者虽然安全性极高，但会导致无法验证 API 密钥的有效性，因此通常仅适用于特殊用例。在本演示中，为了平衡安全性与功能性，操作者选择了选项二：平衡模式（Balanced）。这一选择允许系统在提供基础防护的同时，保留必要的通信能力。配置完成后，系统会提供反馈，提示用户如果需要调整策略或添加白名单，可以随时进行修改。这种灵活的策略调整机制确保了用户可以根据实际需求动态优化沙箱环境。

代理配置与 API 密钥集成

在启动沙箱之前，必须明确指定要使用的特定代理（Agent）。文档中列出了多种配置，例如针对 Claude Code 的“YOLO 模式”（即危险跳过权限模式）。然而，本次演示选用的是 OpenAI 模型，因此选择了 CodeEx 代理选项。为了启用该代理，首先需要配置 OpenAI 的 API 密钥。用户可以通过终端命令 export OPENAI_KEY=... 或在会话中设置凭证来完成这一操作。出于安全考虑，密钥输入过程被隐藏，但系统确认密钥已成功保存。这一密钥集成步骤是确保代理能够正常调用模型 API 的关键前提。随后，操作者进入专门创建的目录，执行 sbx run codeex 命令，准备启动沙箱实例。

沙箱启动流程与初始连接测试

执行启动命令后，系统首先进行容器镜像的初始下载，并提示用户信任当前目录的内容。一旦启动完成，界面显示代理正在运行 OpenAI 的 GPT-5.5 模型，且处于“YOLO 模式”，即全认证模式。文档指出，沙箱默认在无需批准提示的情况下运行代码，这既保证了快速迭代，又维持了安全性。在发送第一条“Hello”消息以测试连通性时，系统触发了一个看似警告的信息：“falling back from websockets to HTTPS transport stream disconnected before completion attack attempt detected”。这一现象引发了对网络策略的关注。通过运行 sbx policy log 命令，操作者查看了容器的网络尝试日志，发现所有请求均为允许状态，没有拒绝记录。这证明该警告并非由容器内的访问规则触发，而是系统对传输层变化的自动响应，展示了沙箱强大的审计与监控能力。

文件系统隔离与网络策略验证

为了验证沙箱的文件系统隔离性，操作者在沙箱内执行了列出所有文件（包括隐藏文件）的命令，并将结果保存。对比结果显示，在原生主机系统中，该命令会暴露大量系统级隐藏文件和目录；而在沙箱内部，代理仅能看到挂载目录内的内容（如一个测试用的 HTML 文件）。这种严格的访问限制确保了代理无法触及宿主机的敏感数据。随后，为了测试网络访问策略，操作者计划运行一个在主机上 ping 随机 IP 地址的脚本。虽然该行为本身不具恶意，但它是验证沙箱网络边界控制的有效手段。通过对比主机与沙箱的网络行为，可以直观地看到沙箱如何限制代理的网络探索范围，从而防止潜在的数据泄露或未经授权的外部通信。

原生系统与沙箱的Ping行为对比

为了直观展示Docker沙箱的安全机制，我们首先在一个原生主机系统的终端中运行了一个脚本，该脚本试图向特定IP地址发送Ping请求。结果显示，原生系统允许该脚本自由执行，并成功收到了来自目标IP（Hacker News网站）的响应。这一过程没有任何阻碍，充分说明了在缺乏隔离环境的情况下，恶意代码可以轻易访问外部网络资源。相比之下，当我们将相同的可执行脚本放入Docker沙箱环境中运行时，行为发生了显著变化。沙箱内的Shell环境默认不包含ping命令，导致脚本在尝试执行时直接报错“command not found”。这种默认拒绝未授权工具的机制，构成了第一层安全防护，阻止了攻击者直接使用系统内置工具进行网络探测。

"So we see that ping command is not found. So it is not available in the shell environment."

沙箱内的工具安装与网络拦截

尽管沙箱默认限制了工具的使用，但为了测试更深层的防护能力，我们指示沙箱内的智能体自行安装ping工具。由于沙箱配置了允许安装常用包的白名单策略，智能体成功完成了安装。然而，当智能体再次尝试执行Ping命令时，虽然命令本身执行成功，但目标IP并未响应。这表明网络层面的拦截已经生效。通过查看容器的网络日志（Network Logs），我们可以清晰地看到该脚本被列入了阻止列表（Blocked Section）。日志显示，该脚本尝试访问的目标IP被明确拦截，且日志中的计数（Count）为3，这与原生系统中脚本设计为Ping三次完全吻合。这一对比证明，即使攻击者能够突破工具限制，沙箱的网络规则（Network Rules）依然能有效切断其与恶意服务器的通信，从而保护主机免受潜在的数据泄露或远程控制风险。

"As we saw in the sandbox... it was blocked just by our network rules and our sandbox."

本地AI模型与沙箱的集成配置

为了进一步验证沙箱在本地AI代理场景下的实用性，我们演示了如何将Docker沙箱与运行在本地主机上的LM Studio服务相结合。这种配置允许智能体在完全离线、无API成本的情况下运行，同时享受沙箱的安全保护。我们创建了一个新的目录codeex-lms用于构建此特定沙箱。由于LM Studio在主机上运行于127.0.0.1的1234端口，我们需要专门配置防火墙规则，允许沙箱向该本地端口发起出站连接。通过执行spx policy命令，我们添加了允许访问LM Studio服务器的策略。配置完成后，我们使用基于本地MiniMax模型的CodeEx容器进行测试。结果显示，当智能体尝试访问之前测试中的恶意IP时，沙箱再次成功拦截，网络策略日志中记录了新的阻止事件。这证实了本地模型与沙箱网络的结合不仅可行，而且能够保持严格的安全边界，确保本地AI代理在享受灵活性的同时，不会成为主机安全的漏洞。

"The sandbox is still working and is blocking things still. However, it is using an entirely local model."

配置沙箱网络策略与创建环境

在构建安全的 AI 代理运行环境时，首要步骤是配置网络访问策略，以确保沙箱能够与宿主机上的本地服务通信。操作者通过命令行输入 allow network 并指定全局作用域，随后明确允许访问 localhost:11234。这一配置至关重要，因为它赋予了沙箱策略权限，使其能够精准地连接到运行在宿主机原生环境中的 LM Studio 服务器。这种细粒度的网络控制是隔离环境的基础，防止了不必要的网络暴露，同时保留了必要的本地模型调用通道。

"And then we're going to type localhost colon one 123 4. And then we'll press enter. And this will allow that policy for our sandbox to actually be able to reach this specific LM Studio server running natively on our host system."

完成网络策略后，下一步是创建具体的沙箱实例。使用 sbx create 命令，并将沙箱命名为与当前目录一致的结构，例如 codeex-lms。这里特别指定使用 codeex 容器镜像，并挂载当前目录（.）。这一过程不仅建立了隔离的运行空间，还确保了代码执行环境的独立性。当命令执行完毕后，沙箱即刻生成，为后续接入本地大语言模型做好了底层架构准备，整个过程无需复杂的镜像构建，直接复用现有容器配置。

启动沙箱并接入本地模型

沙箱创建完成后，需要执行一条包含多行逻辑的命令来启动沙箱并注入本地模型配置。通过复制粘贴预先准备好的脚本，操作者能够直观地看到命令背后的逻辑：它旨在打开一个新的沙箱会话，使用 CodeEx 工具，并指向本地 LM Studio 中特定的模型 ID。执行该命令后，沙箱界面迅速启动，顶部显示 codeex 标识，并提示用户信任目录内容。与使用云端模型（如 GPT-55）不同，此处界面明确显示正在使用通过 LM Studio 服务的本地模型。

与此同时，LM Studio 服务器底部的开发者日志发生了实时变化，这直接证明了本地模型已被成功触发并响应沙箱内的请求。这种即时反馈机制验证了网络策略配置的有效性。对于希望使用不同本地模型的用户，只需在 LM Studio 的开发工具控制台中找到对应模型的 API Model Identifier（例如 Gemma 431B），并将其替换到启动命令中即可。这种灵活性使得沙箱能够适配多种本地开源模型，而无需重新构建整个基础设施。

性能测试与安全隔离验证

为了验证沙箱的实际效能与安全性，操作者在搭载 Mac Studio M3 Ultra 的设备上进行了测试。该设备拥有 256GB 统一内存，运行的是 MiniMax M2.7 模型的 6-bit 量化版本。尽管本地模型在智能程度上可能不及 GPT-55、Claude Opus 4.7 或 Gemini 31 Pro 等顶级云端模型，但在本地部署场景下，其安全性价值更为突出。测试中，代理被指令列出目录内容并将结果写入文本文件。结果显示，代理成功执行了命令，并在沙箱内生成了包含文件列表的文本文件，证明了基础指令执行能力的可用性。

安全优势与本地 AI 部署价值

沙箱的核心价值在于其强大的安全隔离能力，这对于本地 AI 部署尤为关键。本地模型往往缺乏云端模型那样的安全护栏，更容易执行危险操作（如 rm -rf）或泄露环境变量。在本实验中，沙箱成功阻止了试图 ping 特定 IP 地址的恶意脚本，并严格限制代理只能访问挂载的目录。这种“最小权限原则”确保了即使模型产生幻觉或被恶意利用，也不会对宿主机系统造成实质性损害。

"It's important to be able to have a safe place or safe space for the local model to actually run in a sandbox."

这一机制极大地降低了本地 AI 实验的风险门槛。对于无法负担高端硬件（如最新款 Mac Mini）的用户，沙箱提供了一种低成本、高安全的实验途径。通过简单的配置修改，用户即可在隔离环境中测试 Agent 行为，观察其能力边界与安全漏洞。这种安全性不仅保护了用户数据，也为本地大模型的进一步应用探索提供了可信的执行空间，是本地 AI 生态发展中不可或缺的基础设施。

视频结语与核心议题回顾

本视频在深入探索了Docker沙箱的具体操作后，最终回到了开篇提到的核心页面，即关于Docker沙箱的常见问题解答（Q&A）部分。这部分内容并非简单的补充说明，而是提供了理解该工具设计初衷的关键洞察。通过回顾这些问答，观众可以更清晰地认识到，引入沙箱环境不仅仅是为了技术上的隔离，更是为了解决日益复杂的AI赋能网络安全问题。随着时间推移，这一领域的话题热度持续攀升，无论是黑帽黑客还是白帽安全专家，都在积极探讨如何利用AI技术进行攻击或防御。这种双向的博弈使得安全隔离机制变得尤为重要，而Docker沙箱正是应对这一挑战的基础设施之一。

社区互动与赞助致谢

在视频的最后，作者对今天的主题进行了总结，并强调了Docker沙箱作为安全实验环境的重要性。作者鼓励观众在评论区留下任何疑问，以便进行更深入的交流。同时，作者特别感谢了Docker公司对本频道的赞助，正是由于Docker的支持，才得以制作并呈现这样一部关于安全隔离技术的详细指南。这一环节不仅是对合作伙伴的致谢，也侧面反映了开源社区与商业支持在推动安全技术普及中的重要作用。视频至此圆满结束，旨在为观众提供一个安全的空间来探索AI代理（AI Agents）的潜力与风险。