Docker Sandboxes 的凭证：host 代理转发，不进 microVM
内容提要
Docker沙箱的凭证隔离机制：API密钥以占位符形式存在，真实凭证由宿主机代理转发，不进入microVM。SSH通过转发SSH_AUTH_SOCK连接，可签名但私钥文件不可读。手动写入持久化脚本的值为明文例外。删除沙箱不会清除宿主机侧配置。
延伸解读
占位符与代理：凭证隔离的核心机制
Docker Sandboxes 的凭证隔离并非简单隐藏，而是通过宿主机侧代理转发实现。Agent 环境变量中的 API Key 和 GitHub token 均为固定占位符（如 proxy-managed、redacted:gho_...），真实凭证仅存于宿主机。当 Agent 发起模型请求时，宿主机代理用真实 Key 签名后转发，Agent 进程全程无法接触明文。这种设计确保了即使沙箱被攻破，攻击者也无法直接窃取凭证。
手动写入的例外：明文凭证的信任模型
通过 sbx secret 管理的凭证不会进入 microVM，但手动写入 /etc/sandbox-persistent.sh 的环境变量是明文，直接暴露在 VM 文件系统中。测试显示，sbx exec 直接执行命令时不会加载该脚本，需通过 bash -c 才能读取。这意味着用户自定义的敏感信息一旦写入，就失去了代理保护，信任模型与官方凭证完全不同，需谨慎使用。
SSH 代理转发：能签名但摸不到私钥
SSH 凭证通过转发 SSH_AUTH_SOCK 实现，Agent 可以列出宿主机上真实的私钥指纹和路径，并能使用该密钥进行签名操作，但私钥文件本身从未进入 microVM。沙箱内无法访问 ~/.ssh 或 /Users 目录，因此即使 Agent 被完全控制，也无法复制私钥。这种机制在可用性与安全性之间取得了平衡。
删除沙箱不等于清理宿主机侧配置
sbx rm 仅清除 VM 内部状态，宿主机侧的凭证、MCP 注册和共享 Skills 存储不会随之删除。这些配置是宿主机级持久化状态，与单个沙箱生命周期无关。清理时需分别使用 sbx secret rm 和 sbx mcp rm 等命令，否则可能留下安全隐患。
Q&A
Docker Sandboxes 中 API 密钥是如何存储的？
API 密钥以占位符形式存在，真实凭证由宿主机侧代理转发，不进入 microVM。Agent 环境变量中看到的是固定占位符 proxy-managed，真实请求由宿主机代理签名后转发。
SSH 在 Docker Sandboxes 中如何工作？
SSH 通过转发 SSH_AUTH_SOCK 连接，Agent 可以列出宿主机上的私钥指纹和路径，并能使用私钥签名，但私钥文件本身不进入 microVM，~/.ssh 目录不可读。
手动写入 /etc/sandbox-persistent.sh 的凭证有什么风险？
手动写入的凭证是明文，直接存放在 VM 文件系统中，不经过代理，Agent 进程可以直接读取，存在泄露风险。
删除 Docker Sandbox 会清除宿主机侧的凭证吗？
不会。删除沙箱只清除 VM 内部状态，宿主机侧配置如 sbx secret 存储的凭证、MCP Server 注册和共享 Skills 不会自动清除，需要单独使用 sbx secret rm 或 sbx mcp rm 清理。
sbx exec 命令为什么无法读取 sandbox-persistent.sh 中的环境变量？
因为 sbx exec 不经过 shell，不会 source sandbox-persistent.sh，所以环境变量不会加载。需要包一层 bash -c 才能读取。
Docker Sandboxes 的凭证隔离机制有哪些例外？
例外是手动写入 /etc/sandbox-persistent.sh 的凭证，这些是明文，直接进入 VM，不经过代理。其他官方支持的凭证均通过代理转发，不进入 microVM。
