Agent Vault 是一个开源的 HTTP 凭证代理和保险库，解决 AI Agent 时代的凭证安全问题。
为什么传统方案失效
传统 workload 的凭证管理：vault 直接把密钥交付给程序，程序有固定执行路径，不会被诱导用意外方式使用凭证。
但 AI Agent 是非确定性的，容易被操纵——这个假设失效了。
攻击向量：凭证泄露
恶意 actor 可以通过 prompt injection 操纵 agent：
- 告诉 agent「扫描并返回环境中的所有密钥」
- 在 RAG pipeline 里注入毒化文档
- 在 tool call 里注入指令让 agent 把凭证转发到攻击者控制的端点
即使有足够的 guardrails，也无法保证 agent 不会被操纵泄露凭证。而且攻击者一旦拿到有邮件访问权限的 agent 的凭证，就可以代表用户读写邮件。
行业收敛的方向：凭证代理（Credential Brokering）
Anthropic 的 architecture blog 描述了他们的方案：给 agent 建专用代理服务，从 vault 获取凭证并附加到出站请求上，agent 的 harness 永远不知道凭证内容。
Browser Use 用的是同向代理服务，在代理层注入凭证。Vercel 和 Cloudflare 也推出了 provider-specific 方案。
核心原则：如果不能信任 agent 安全处理凭证，为什么要给 agent 任何凭证？ 在 agent 和它要访问的服务之间加一个代理层来 broker 凭证，才是正确方向。
Agent Vault 的设计
四个核心构造：
- Vault：凭证的安全逻辑容器，带定义 agent 如何通过它代理请求的服务
- Credential：存储在 vault 中的敏感值（API key、数据库凭证、密码等）
- Service：agent 可以通过代理访问的主机（如 GitHub），定义认证 scheme（Bearer、API Key 等）
- Agent：AI agent（Claude Code、OpenClaw、Hermes 等）获得自己的凭证 token
技术实现
关键洞察：interface 在栈顶分歧，在栈底汇聚。
无论 agent 调用 API、shell out 到 CLI、用 SDK、还是调用 MCP 工具——每个请求最终都变成出站 HTTPS 连接。最干净的凭证注入点在 interface 层之下，在 HTTPS 层——这是每个 agent 流量实际共享的层。
工作流程：
Agent 发起请求（API/CLI/SDK/MCP）
↓
请求自动路由到 Agent Vault（通过 HTTPS_PROXY 环境变量）
↓
Agent Vault 用本地受信任 CA 终止 TLS，以明文接收请求
↓
匹配目标主机，注入 vault 中的正确凭证
↓
建立新的 TLS 连接到真实上游
↓
响应沿原路返回，agent 视角：正常 HTTPS 请求+响应
部署方式：
设置 HTTPS_PROXY=<agent_credential>:vault@agent-vault_url.com，大多数运行时和工具（curl、Python、Node、Go）都识别这个环境变量。同时在网络层切断所有出站流量，只允许 Agent Vault 实例可达。
为什么是 MITM 架构
传统代理里， HTTP CONNECT 建立的隧道是不透明的，无法注入 header 因为看不到请求内容。
Agent Vault 终止 TLS，用本地受信任 CA 把自己呈现为上游服务，agent 完成到它的安全连接并发发明文请求。这时 Agent Vault 可以：
- 匹配请求
- 剥离 agent 可能附加的任何凭证
- 从加密存储注入正确凭证
- 建立到真实上游的新 TLS 连接
MITM 架构还意味着未来可以扩展防火墙功能：在参数级别分析和操作请求。
安全细节
- CONNECT 握手期间用 session token 认证请求，每个请求 scope 到特定 agent 上下文
- 上游目标在连接时固定，防止中途重定向
- 所有从代理到上游的出站连接都用标准 TLS 验证重新建立
- 用于拦截的 CA 被当作敏感材料，在和凭证相同的模型下保护
核心原则
如果 agent 不能被信任持有凭证，它就不应该持有凭证。
Agent Vault 今天以研究预览版发布开源，地址：agent-vault（相关链接在原推文）。
原文：Agent Vault: The Open Source Credential Proxy and Vault for Agents — Tony Dang