本文作者靳文祥前言OpenSandbox 是一个阿里巴巴开源的面向 AI Agent 的通用沙箱平台提供多语言 SDK、CLI、MCP Server以及 Docker / Kubernetes 运行时在阿里内部广泛应用于 Coding Agent、GUI Agent、代码执行、Agent 评测、RL 训练等场景。OpenSandbox 正在成为 AI Agent 基础设施领域里一个重要的开源项目。随着 AI Agent 从 Demo 走向生产环境沙箱要解决的问题也不再只是“代码在哪里执行”还包括“真实凭据应该如何安全使用”。这就是 Credential Vault 要解决的问题让工具照常工作但让真实密钥不再进入沙箱。01在过去想让 Agent 在沙箱里调用外部服务最直接的方式往往是把 API Key、Git Token、Registry 凭据等塞进环境变量、命令行参数或配置文件里。这种方式虽然简单不过风险也很直接沙箱本来是用来隔离不可信代码和工具执行的一旦真实密钥进入沙箱Prompt Injection、恶意依赖、日志泄露、文件读取等风险都会被放大。例如一个 Coding Agent 可能需要这些操作都可能需要凭据。如果凭据直接暴露在沙箱环境变量、命令参数、配置文件或日志里那么只要沙箱内的任意工具链环节失控真实密钥就可能被读取、打印或转发。02Credential Vault 是 OpenSandbox 的出站凭据代理能力。它把真实凭据保存在沙箱外由 OpenSandbox 的 egress sidecar 在出站请求经过时按规则注入认证信息。整体流程可以理解为宿主侧 SDK 创建 sandbox并启用 Credential ProxySDK 将真实凭据和绑定规则写入 egress sidecar 的 Credential Vault沙箱进程只拿到假值或空值例如一个假的 API Key 当沙箱内工具发起HTTPS 出站请求时egress sidecar 检查请求的 scheme、host、port、method 和 path如果请求精确匹配某条 Credential Vault bindingsidecar 就在出站时注入对应的认证 Header真实凭据不会返回给沙箱也不会出现在沙箱环境变量、命令行、文件系统和日志里。换句话说沙箱仍然可以运行 Claude Code、Git、curl、包管理器或模型 API 客户端但真实密钥不再交给这些工具所在的运行环境。03我们以 Claude Code 调用 Anthropic API 为例。传统做法通常是在沙箱里设置真实的 ANTHROPIC_API_KEY让 CLI 读取这个环境变量后访问 api.anthropic.com。使用 Credential Vault 后沙箱里可以只设置一个假的 ANTHROPIC_API_KEY例如ANTHROPIC_API_KEYfake-key-inside-sandbox这个假值只是为了让 CLI 正常启动。真正的 Anthropic API Key 由宿主侧 SDK 写入 Credential Vault并绑定到明确的出站请求范围例如schemehttpshostapi.anthropic.comport443methodGET、POSTpath/v1/* auth headerx-api-key当 Claude Code 在沙箱里访问 https://api.anthropic.com/v1/* 时egress sidecar 会在请求离开沙箱前注入真实的 x-api-key Header。对 Claude Code 来说请求可以正常完成对沙箱进程来说它从未见过真实密钥。04Credential Vault 也适用于更多常见开发者工具场景。私有 Git 仓库 clone 可以使用 Basic Auth binding。真实的 username:token 先在宿主侧编码后写入 Vault沙箱里执行的仍然是普通无密钥 URLGIT_TERMINAL_PROMPT0 git clone https://api.github.com/org/private-repo.git访问内部 API 时也可以把 Token 绑定到明确的 Header、Host、Path 和 Method 上。沙箱命令保持干净curl -fsS https://api.github.com/v1/projects/真正的认证信息由 egress sidecar 在出站链路上补齐。这种设计的价值在于凭据不再是一个进入沙箱后任意可读、任意可复制的字符串而变成一条受控的出站授权规则。05Credential Vault 通常应该和默认拒绝的出站网络策略一起使用。这也就意味着沙箱默认不能访问任意外部地址只允许访问工具真正需要的服务 Host再通过 Credential Vault 将凭据绑定到更窄的请求范围。例如对模型 API 可以只允许 /v1/*对 Git 仓库可以只绑定某个私有仓库路径对内部 API 可以限制到具体 Method 和 Path。这带来以下几项直接收益1.真实密钥不进入沙箱环境2.密钥不会自然残留在命令行、文件和日志中3.凭据只能在匹配的出站请求上被使用4.不同服务、不同路径可以绑定不同凭据5.平台可以更容易审计和收敛凭据使用边界。需要注意的是Credential Vault 依赖 egress sidecar 的透明出站拦截和 MITM路径。如果 sandbox pod 同时注入 Istio / Envoy 这类透明 service mesh sidecar两层拦截会在同一个网络命名空间内冲突。OpenSandbox 当前不支持 Credential Vault 与这类透明 service mesh sidecar 同时工作在同一个 sandbox pod 内。06沙箱平台过去关注的重点通常是进程隔离、文件系统隔离、网络隔离和资源隔离。Credential Vault 进一步补上了 AI Agent 生产化过程中的关键一环凭据隔离。AI Agent 的执行链路往往更长也更难完全预测。它可能会调用外部 CLI安装依赖执行仓库脚本访问模型 API甚至被用户输入或网页内容间接影响。如果真实密钥直接暴露给这条链路风险很难收敛。Credential Vault 给出的答案是真实密钥应该留在沙箱外由平台在受控的出站链路上按规则注入。沙箱负责执行Vault 负责授权egress policy 负责边界。这让 OpenSandbox 不只是一个“能运行 Agent 的地方”而是向生产级 Agent Runtime 又推进了一步。一句话总结Credential Vault 不是让沙箱更方便地保存密钥而是让沙箱不再需要保存真实密钥。References[1]OpenSandbox GitHubhttps://github.com/opensandbox-group/OpenSandbox[2]Credential Vault 文档https://github.com/opensandbox-group/OpenSandbox/blob/main/docs/guides/credential-vault.md