Docker Sandboxes 实测系列共 5 篇Docker Sandboxes 上手从安装到第一次跑 AgentDocker Sandboxes 工作区怎么接Direct、Clone 和它们的边界Docker Sandboxes 的隔离例外共享 Skills 与宿主机 MCPDocker Sandboxes 的凭证host 代理转发不进 microVM本篇Docker Sandboxes 的网络策略balanced 挡住了什么怎么放行一条例外TL;DRsbx secret存的 API Key 从不进 microVM。Agent 环境变量里看到的是固定占位符proxy-managed真实请求由宿主机侧代理转发签名GitHub token 也是同样套路的假字符串。手动写进/etc/sandbox-persistent.sh的值是例外——那是真值直接躺在 VM 里不走代理。SSH 走另一条路SSH_AUTH_SOCK被转发进 sandboxssh-add -l能列出宿主机上真实的私钥指纹和路径Agent 能拿它签名——但~/.ssh目录本身读不到私钥文件从没进过 microVM。能用摸不到。上一篇留的口子上一篇 讲完共享 Skills 和宿主机 MCP留了一句没展开SSH_AUTH_SOCK会转发进 sandbox。这是官方五层隔离里最后一层——凭证隔离——具体怎么做的这篇补上顺带把 API Key 那条也讲清楚。API KeyAgent 看到的是假的起一个干净的 sandbox看它环境变量里的凭证长什么样$ sbx exec my-sandbox bash -c env | grep -E API_KEY|GH_TOKEN ANTHROPIC_API_KEYproxy-managed OPENAI_API_KEYproxy-managed GOOGLE_API_KEYproxy-managed XAI_API_KEYproxy-managed GH_TOKENredacted:gho_...proxy-managed是固定哨兵值不是真 Key 的一部分。真实凭证留在宿主机上Agent 发起的模型请求经过一个宿主机侧代理代理拿真 Key 签好再转发出去——Agent 进程本身包括它能读到的环境变量从头到尾看不到明文。GH_TOKEN也是同一套redacted:gho_...这种占位符不是真的 GitHub token。SBX_CRED_PROVIDER_MODE这组变量能看出每个 provider 当前走的是哪种注入方式我这台机器上配过的几个都是apikey没存过 Key 的 provider 会显示别的值代表这条凭证根本没注入。手动塞进去的值是真的不是代理这条例外容易被忽略sbx secret管的是官方支持的那几个 provider如果 Agent 需要一个不在名单里的环境变量比如自定义的内部 token官方给的路径是写进/etc/sandbox-persistent.shsbx exec my-sandbox bash -c echo export MY_TOKENreal-secret-value /etc/sandbox-persistent.sh这条路径不经过代理real-secret-value是明文直接躺在 VM 文件系统里。我测了一下它到底在什么条件下能读到$ sbx exec my-sandbox env | grep MY_TOKEN # 什么都没有 $ sbx exec my-sandbox bash -c echo $MY_TOKEN real-secret-valuesbx exec name command不经过 shellsandbox-persistent.sh不会被 source环境变量读不到包一层bash -c才会读到。这条不是 bug是sbx exec本来就不保证起一个登录 shell。用sbx secret的凭证全程不进 VM写进sandbox-persistent.sh的值一旦落地就是明文Agent 进程能直接读——这是两种完全不同的信任模型别把后者当成前者的替代品用。SSH agent能签名读不到私钥Agent 要用 Git 走 SSH 免密最短路径是转发宿主机的 SSH agent而不是把私钥文件拷进 sandbox$ sbx exec my-sandbox bash -c echo $SSH_AUTH_SOCK; ssh-add -l /run/ssh-agent.sock 4096 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /Users/你的用户名/.ssh/id_rsa (RSA)这行输出看着矛盾其实很说明问题ssh-add -l报告的密钥路径是宿主机上的真实路径/Users/你的用户名/.ssh/id_rsa但 sandbox 里既没有/Users这个目录~/.ssh也读不到$ sbx exec my-sandbox bash -c ls ~/.ssh; ls /Users ls: cannot access /home/agent/.ssh: No such file or directory ls: cannot access /Users: No such file or directorySSH_AUTH_SOCK转发的是一个到宿主机 ssh-agent 的 socket 连接签名请求经这条 socket 发回宿主机由真正持有私钥的进程处理私钥文件本身从没进过 microVM。Agent 能借这把钥匙开门签 commit、连 SSH 服务器拿不走钥匙——指纹和声明路径能看到文件字节看不到。删除 sandbox清的是 VM不是宿主机侧状态凭证隔离还有一条容易忽略的边界sbx rm之后VM 内部状态清空但宿主机侧配置原地不动——sbx secret存的凭证、上一篇 注册过的 MCP Server、共享 Skills store都不会因为删掉某个 sandbox 而跟着清掉。这些是宿主机侧持久化的状态跟单个 sandbox 的生命周期是两回事清理凭证要单独sbx secret rm清理 MCP 注册要单独sbx mcp rm。小结五层官方隔离里凭证这一层做得最干净Agent 摸到的自始至终是代理和占位符真 Key 不下发。SSH 走的是同一个思路——转发一个能用的连接不转发底层材料。这条边界唯一会被打穿的地方是你自己手动写进sandbox-persistent.sh的东西那不是代理是明文进了 VM 就是进了 VM。四篇写下来装、连、挂工作区、共享 Skills 和 MCP、凭证Docker Sandboxes 的隔离边界基本摸完了。剩下没验证的是 Kimaki、omp 这类非官方 Agent 能不能接进这套体系——上一篇也提过产品级支持只有官方那份 Agent 列表这是另一个问题留着以后有机会再测。 Docker Sandboxes 的凭证：host 代理转发，不进 microVM
Docker Sandboxes 实测系列共 5 篇Docker Sandboxes 上手从安装到第一次跑 AgentDocker Sandboxes 工作区怎么接Direct、Clone 和它们的边界Docker Sandboxes 的隔离例外共享 Skills 与宿主机 MCPDocker Sandboxes 的凭证host 代理转发不进 microVM本篇Docker Sandboxes 的网络策略balanced 挡住了什么怎么放行一条例外TL;DRsbx secret存的 API Key 从不进 microVM。Agent 环境变量里看到的是固定占位符proxy-managed真实请求由宿主机侧代理转发签名GitHub token 也是同样套路的假字符串。手动写进/etc/sandbox-persistent.sh的值是例外——那是真值直接躺在 VM 里不走代理。SSH 走另一条路SSH_AUTH_SOCK被转发进 sandboxssh-add -l能列出宿主机上真实的私钥指纹和路径Agent 能拿它签名——但~/.ssh目录本身读不到私钥文件从没进过 microVM。能用摸不到。上一篇留的口子上一篇 讲完共享 Skills 和宿主机 MCP留了一句没展开SSH_AUTH_SOCK会转发进 sandbox。这是官方五层隔离里最后一层——凭证隔离——具体怎么做的这篇补上顺带把 API Key 那条也讲清楚。API KeyAgent 看到的是假的起一个干净的 sandbox看它环境变量里的凭证长什么样$ sbx exec my-sandbox bash -c env | grep -E API_KEY|GH_TOKEN ANTHROPIC_API_KEYproxy-managed OPENAI_API_KEYproxy-managed GOOGLE_API_KEYproxy-managed XAI_API_KEYproxy-managed GH_TOKENredacted:gho_...proxy-managed是固定哨兵值不是真 Key 的一部分。真实凭证留在宿主机上Agent 发起的模型请求经过一个宿主机侧代理代理拿真 Key 签好再转发出去——Agent 进程本身包括它能读到的环境变量从头到尾看不到明文。GH_TOKEN也是同一套redacted:gho_...这种占位符不是真的 GitHub token。SBX_CRED_PROVIDER_MODE这组变量能看出每个 provider 当前走的是哪种注入方式我这台机器上配过的几个都是apikey没存过 Key 的 provider 会显示别的值代表这条凭证根本没注入。手动塞进去的值是真的不是代理这条例外容易被忽略sbx secret管的是官方支持的那几个 provider如果 Agent 需要一个不在名单里的环境变量比如自定义的内部 token官方给的路径是写进/etc/sandbox-persistent.shsbx exec my-sandbox bash -c echo export MY_TOKENreal-secret-value /etc/sandbox-persistent.sh这条路径不经过代理real-secret-value是明文直接躺在 VM 文件系统里。我测了一下它到底在什么条件下能读到$ sbx exec my-sandbox env | grep MY_TOKEN # 什么都没有 $ sbx exec my-sandbox bash -c echo $MY_TOKEN real-secret-valuesbx exec name command不经过 shellsandbox-persistent.sh不会被 source环境变量读不到包一层bash -c才会读到。这条不是 bug是sbx exec本来就不保证起一个登录 shell。用sbx secret的凭证全程不进 VM写进sandbox-persistent.sh的值一旦落地就是明文Agent 进程能直接读——这是两种完全不同的信任模型别把后者当成前者的替代品用。SSH agent能签名读不到私钥Agent 要用 Git 走 SSH 免密最短路径是转发宿主机的 SSH agent而不是把私钥文件拷进 sandbox$ sbx exec my-sandbox bash -c echo $SSH_AUTH_SOCK; ssh-add -l /run/ssh-agent.sock 4096 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /Users/你的用户名/.ssh/id_rsa (RSA)这行输出看着矛盾其实很说明问题ssh-add -l报告的密钥路径是宿主机上的真实路径/Users/你的用户名/.ssh/id_rsa但 sandbox 里既没有/Users这个目录~/.ssh也读不到$ sbx exec my-sandbox bash -c ls ~/.ssh; ls /Users ls: cannot access /home/agent/.ssh: No such file or directory ls: cannot access /Users: No such file or directorySSH_AUTH_SOCK转发的是一个到宿主机 ssh-agent 的 socket 连接签名请求经这条 socket 发回宿主机由真正持有私钥的进程处理私钥文件本身从没进过 microVM。Agent 能借这把钥匙开门签 commit、连 SSH 服务器拿不走钥匙——指纹和声明路径能看到文件字节看不到。删除 sandbox清的是 VM不是宿主机侧状态凭证隔离还有一条容易忽略的边界sbx rm之后VM 内部状态清空但宿主机侧配置原地不动——sbx secret存的凭证、上一篇 注册过的 MCP Server、共享 Skills store都不会因为删掉某个 sandbox 而跟着清掉。这些是宿主机侧持久化的状态跟单个 sandbox 的生命周期是两回事清理凭证要单独sbx secret rm清理 MCP 注册要单独sbx mcp rm。小结五层官方隔离里凭证这一层做得最干净Agent 摸到的自始至终是代理和占位符真 Key 不下发。SSH 走的是同一个思路——转发一个能用的连接不转发底层材料。这条边界唯一会被打穿的地方是你自己手动写进sandbox-persistent.sh的东西那不是代理是明文进了 VM 就是进了 VM。四篇写下来装、连、挂工作区、共享 Skills 和 MCP、凭证Docker Sandboxes 的隔离边界基本摸完了。剩下没验证的是 Kimaki、omp 这类非官方 Agent 能不能接进这套体系——上一篇也提过产品级支持只有官方那份 Agent 列表这是另一个问题留着以后有机会再测。