Agent Vault：面向 AI Agent 的开源凭据代理与密钥管理方案

挑战

今天的计算范式并不是为 agent 设计的，而是为传统工作负载设计的。问题在于，agent 无论是 coding agent 还是 sandboxed execution agent，它们的运行方式都与我们以往见过的任何事物有着根本性的不同；它们是非确定性的，而且很容易被操纵，这打破了传统系统所依赖的许多假设。

以 secrets management 为例，过去十年的做法一直是将 secrets 直接从中心化 vault 下发给工作负载；这对具有固定执行路径的程序非常有效，但当程序可能被诱导以其作者从未预料到的方式使用这些 secrets 时，这种方法就会失效。

考虑这样一种攻击向量：恶意行为者对 agent 进行 prompt injection，指示它扫描并返回 agent 环境中可用的 secrets；agent 会服从并将 secrets 暴露给调用方。无论是在 RAG pipeline 中被投毒的文档，还是通过工具调用拉取的恶意网页，指示 agent 将 secrets 转发到攻击者控制的 endpoint，agent 都可能通过多种方式遭受 prompt injection，使其成为一个高度脆弱的攻击面。不幸的是，即使已经部署了足够的 guardrails，也无法保证 agent 不会被操纵而泄露其 secrets。

这就是凭证外泄（credential exfiltration）的问题；一旦发生，攻击者就获得了执行数据外泄所需的凭证，这是一个相邻问题，他们现在可以利用外泄的凭证访问有价值的数据。正如你可能预料的那样，攻击者如果成功操纵一个具备发送邮件能力的 agent，就能外泄读取和代表用户发送邮件所需的凭证——这很可怕。

早期方案

我们接触过的大多数团队都实现了基本的 guardrails、安全控制以及更传统的变通方案，以缓解凭证外泄风险。此类措施的一个例子是：在可行的地方为 agent 提供短期凭证，例如当某个支持 OAuth2 的 API 可以采用 access/refresh token 模式时；这种短暂性也可以通过自动化的 secrets rotation 和 dynamic secrets 方案来实现。

在这种情况下，如果攻击者拿到了暴露的凭证，那么他们只能在有限时间内使用它。不过这并不理想，因为这些措施并没有改变一个事实：凭证仍然可以被外泄。

最优秀的团队会开发自己的定制基础设施来对抗凭证外泄。例如，Anthropic 的 Managed Agents 架构博客描述了为 agent 构建一个专用代理服务，从 vault 中获取凭证并将其附加到经过它的出站请求上；博客提到，harness 从未感知到这些凭证。

Browser Use 是一家为 AI agent 提供 web browser 的基础设施公司，它采用一种 sandboxed agent to control plane architecture，通过一个专用服务来路由 agent 请求，并在这个代理层注入凭证。最近，我们也看到云服务提供商推出了自己的供应商特定解决方案，例如 Vercel 的 credential brokering 或 Cloudflare 的 outbound workers，它们只能在各自的生态系统内工作。

这强烈表明，向传统工作负载交付 secrets 的旧模型并不适用于 agent。这也强烈表明，这不是每个团队都应该自己单独解决的问题。

解决方案

当你审视最优秀的团队如何构建和使用安全 agent 时，你会发现他们在 agent 和凭证之间划定了一条信任边界。毕竟，如果无法信任 agent 安全地处理凭证，那为什么还要给它任何凭证呢？将凭证放在 agent 与其尝试访问的服务之间的代理层进行中介，在逻辑上可能更合理。这正成为我们这个行业目前正在趋同的主要方法：credential brokering。

简而言之，不应信任 agent 直接访问任何 secrets。相反，应该由其他组件代表 agent 持有 secret，并在 agent 通过它发送请求时在边缘附加上去。

Agent Vault

今天，我们宣布推出 Agent Vault，这是一个处于 research preview 阶段的 open source 项目，其核心理念很简单：agent 从一开始就不应该看到底层的 secret。

通过 Agent Vault，我们正在重新思考 secrets 应该如何被 agent 使用，并以一种兼顾 human 的方式走向 agent first。我们相信 vault 和/或 secret store 会一直存在，但为了适配 agent 的工作方式，secrets 的交付方式将会发生巨大变化。

至少在当前状态下，agent 不能被信任直接持有 secrets，因此必须在每个 agent 旁边部署一个专用的 forward HTTP proxy，无论是通过专用服务、sidecar 还是 egress layer；以便为其安全地中介凭证，让它能够访问外部世界。有了这个 proxy，你可以检查被代理的请求，并且在未来应用 firewall rules 来限制通过 proxy 流动的流量。

Agent Vault 项目让我们得以一窥一种趋势：我们相信许多人，包括 Anthropic、Brex 以及一些 open source 项目，都已经注意到了这种趋势——将 agent 与其凭证分离。

虽然我们预计 Agent Vault 的形态会在接下来的一年中发生变化，并且在让它更容易为 agentic 环境部署方面还有大量工作要做，但我们相信，它代表了在如何正确思考 AI agent 的 secrets management，尤其是如何为它们设计 ergonomics 方面的一个根本性进步。

工作原理

Agent Vault 以一个可移植 binary 的形式提供，同时充当 server 和 CLI client；它是一个专用服务，也可以作为 Docker container 部署。你可以在本地将 Agent Vault 与 Claude Code 这样的 coding agent 一起使用，或者将其部署到你的 VPS 上，与你的自定义 agent infrastructure 一起运行。

如果你正在运行 sandboxed agents，我们建议你在尽可能靠近 agent 的位置部署一个 Agent Vault 实例，并为 agent 提供对其中特定 vault 的访问权限（更多内容见下文）。

在 Agent Vault 中，我们引入了四个构件：vaults、credentials、services 和 agents。

• vault 是一个用于存放 credentials 的安全逻辑容器，其中的 services 定义了 agent 如何通过它代理请求。
• credential 是存储在 vault 中的敏感值，Agent Vault 会将其附加到被代理的请求上。这可以是 API key、database credential、password 或任何其他敏感材料。
• service 是像 api.stripe.com 这样的 host，agent 可以通过 proxy vault 访问它。向 vault 添加 service 时，你需要指定该 service 的 hostname 以及它的 authentication scheme（例如 Bearer、API Key 等）；你可以指定一个 vault credential 作为 service authentication 的一部分，也可以省略它并将代理视为 passthrough。当 agent 发起一个被代理的请求时，Agent Vault 会将目标 host 与 vault 的 services 相匹配，附加已配置的 credentials，并转发请求。
• agent 代表一个 AI agent，例如 Claude Code、OpenClaw、Hermes，或者一个拥有自己 credential 的自定义 agent；如果你打算通过用户发放的 service token 将 vault access 委托给一个 agentic system，那么这个构件并不总是需要。

为了使用 Agent Vault，你首先创建一个 vault，向其中添加 credentials，并指定哪些 services 可以通过该 vault 访问以及它们应如何进行 authentication。接下来，你创建一个带有 agent token 的 agent，配置你的 sandboxed agent 环境以信任 Agent Vault 的 CA certificate，并将 HTTPS_PROXY environment variable 设置为指向该 vault；其形式为 HTTPS_PROXY=<agent_credential>:vault@agent-vault_url.com。这样一来，HTTP clients、CLI 和大多数语言的 runtimes 都会被指示将流量重定向到 proxy，并在 TLS layer 配置信任，使 agent 将该 vault 视为有效的 upstream。最后，你在 network layer 切断所有出站流量访问，只允许从 sandbox 或受限环境中访问 Agent Vault 实例。

最终效果如下：

1. agent 调用一个 CLI command、SDK method、MCP tool，或者向 LLM 或 API service 发起一个 API call，例如 api.anthropic.com。
2. 请求会在 agent 不知情的情况下自动经由 Agent Vault 路由。
3. Agent Vault 拦截请求，附加 credential，应用任何预定义规则，并将请求转发到目标。
4. 瞧。请求返回给 agent，agent 完成其工作。它从未看到底层 secret，也不需要修改其工作流程。

尽管 Agent Vault 的初步设计使用起来有些笨拙，我们也希望有更多时间来打磨其 developer experience，尤其是在让 agents 开始通过它代理请求的配置方面；但 AI 运动正以 warp speed 向前推进，我们认为最好将这项技术 open source，并与社区合作逐步改进，使其能够在所有 agentic use cases 中无缝工作，因为每种场景都有其自身的细微差别。

设计架构

在设计 Agent Vault 时，我们首先考虑的是 agent 在 sandboxed 环境内外通常如何与外部服务交互；现实是可选项太多了：API、CLI、SDK、MCP。在构建 proxy vault 时，我们本可以再设计一个 “MCP gateway”（剧透：我们确实通过 Agent Sentinel 做了），但那样只会适用于使用 MCP 的 agent，而 agent 也可能使用另外三种方法中的任意一种来调用外部服务。必须有另一种方式，一种与 interface 无关的方案，来为出站流量中介凭证。

我们意识到，无论 agent 是调用 API、通过 CLI shell out、使用 SDK，还是调用 MCP tool，最终每个请求都会变成一个出站 HTTPS connection。接口在 stack 的上层分化；在底层汇合。中介凭证最合理的位置是在接口之下，也就是所有 agent 流量真正共享的那一层：HTTPS 本身。

在接口之下运行

因此，Agent Vault 并没有引入另一个类似 SDK 的、特定于接口的抽象，而是以下一层的形式运行，作为一个本地 forward proxy，agent 通过 HTTPS_PROXY 指向它。这只是一个你设置的 environment variable，而大多数 runtimes 和 tools 本就已经能够识别它。事实上，这与 curl、Python、Node、Go 以及大多数 HTTP clients 多年来一直支持的机制相同。

一旦配置完成，无论 agent 以何种方式发起，每个出站请求都会流经该 vault。请注意，仅仅设置这个 environment variable 并不能保证流量一定会通过 proxy，因为 agent 可以取消设置它，它只是用来引导兼容 clients 的一种措施；在完整部署中，network 必须被锁定，以确保所有出站流量都被强制经过 Agent Vault。

请求实际如何流动

当 agent 尝试访问像 api.stripe.com 这样的 service 时，它的 HTTP client 会使用 HTTP CONNECT 与 Agent Vault 建立一个 tunnel。在传统 proxy 中，这个 tunnel 仍然是 opaque 的，只会简单地转发加密流量。但这种模型不适用于 credential brokering，因为没有办法在看不到请求内容的情况下注入 headers。

为了解决这个问题，Agent Vault 会终止 TLS。借助本地受信任的 certificate authority，它会将自己表现为 upstream service，让 agent 与它完成安全连接，并通过该 tunnel 以明文发送请求。

在这一点上，Agent Vault 可以匹配请求，剥离 agent 附加的任何 credentials，从其加密存储中注入正确的 credential，并与真正的 upstream 建立一个经过正确 verification 的新 TLS connection。MITM architecture 意味着 Agent Vault 未来可以扩展出类似 firewall 的功能，在 parameter 级别分析并对请求采取行动。

response 会沿着相同的路径返回，而从 agent 的角度看什么都没有改变；它发起了一个正常的 HTTPS request，并收到了一个正常的 response。不同之处在于，它从一开始就没有处理过 credential。

为什么这有效

因为这一切发生在 application layer 之下，所以 integration surface 几乎缩减到没有，而 policy 在任何地方都保持一致。allowlisting、rate limiting、audit logging，以及 per-agent credential scoping 可以在 APIs、CLIs、SDKs 和 agent 使用的任何其他 interface 上统一执行，而不需要这些层中的每一层都理解 secrets。

有几个细节使这在实践中成为可能。proxy 在 CONNECT handshake 期间通过 session token 对请求进行 authentication，因此每个请求都被限定到特定的 agent context。upstream destination 在 connection time 就已固定，防止在请求中途重定向，而且 proxy 的所有出站连接都会通过标准 TLS verification 重新建立。用于 interception 的 certificate authority 被视为敏感材料，并按照与 credentials 本身相同的模型加以保护。

所有这一切都回到了一个简单的想法：如果不能信任 agent 持有 credentials，那就不应该把它们交给它。

试试看

Agent Vault 今天以 research preview 的形式发布，并且是 open source。我们在这个阶段发布它，是因为我们很希望得到那些将要长期面对这个问题的工程师们的反馈。

你应该注意到，Agent Vault 是一个 experimental service，我们预计在接下来的几个月里会对 proxy 的形态、ergonomics、安全性和 scalability 做出重大更新。列出近期路线图中的几个项目：我们希望继续降低 self-hosting Agent Vault 以及将其与不同 agent 和 agent orchestration use cases 集成时的摩擦，提升项目的安全性，并增加更多 credential 和 firewall 功能，使其成为 fully featured。

总的来说，我们相信 credential brokering 是 secrets management 在 agent 场景中的正确下一步，并鼓励社区通过探索 repo、阅读 docs，以及为 codebase 做出贡献来参与进来。

• 原文链接： x.com/dangtony98/status/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～