Agent Vault：面向 Agent 的开源凭证代理与 Vault

Agent Vault：面向 Agent 的开源 Credential Proxy 和 Vault

在相当长的一段时间里，行业一直在围绕一个大问题苦苦思索：如何在不让 Agent 读取任何 secrets 的情况下，让它们安全地访问服务？今天，我们给出了一个早期答案：Agent Vault，一个开源的 HTTP credential proxy 和 vault。

在 Infisical，我们每个月处理数十亿个 secrets，为团队、CI/CD pipelines 以及需要它们的 servers/applications 提供应用配置和 secrets 数据。我们见过各种方案：从基于身份的中心化 secrets management，到自动化的 secrets rotation 和 dynamic secrets 这类用于动态生成 secrets 的机制。所以，当我们最初思考 Agent 会如何与 secrets 交互时，我们以为传统的 secrets management 技术已经足够了。事实证明，我们大错特错。

这篇文章会介绍我们是如何思考这个问题的，以及为什么我们认为 Agent Vault 以恰当的形态切中了 AI 时代 secrets management 的正确方向。希望这篇文章读起来足够有趣，也能为那些正在为自己的 Agent 设计 secrets management 方案的人提供帮助；你甚至可以考虑亲自上手试试 Agent Vault。

挑战

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

以 secrets management 为例，过去十年的常见做法一直是从 centralized vault 直接向 workloads 交付 secrets；这对执行路径固定的程序很有效，但当程序可能被诱导以其作者从未预料到的方式使用这些 secrets 时，这种做法就会彻底失效。

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

这就是 credential exfiltration 的问题，而一旦发生这种情况，攻击者就拥有了执行 data exfiltration 所需的凭证；后者是一个相邻问题，攻击者现在可以利用被窃取的凭证获取对有价值数据的访问权限。正如你可能预料的那样，一个成功操纵了具备邮件能力的 Agent 的攻击者，可以窃取用于代表用户读取和发送邮件所需的凭证——这非常可怕。

早期方案

我们交流过的大多数团队，都已经实现了基础的 guardrails、安全控制，以及一些更传统的变通方案，以缓解 credential exfiltration 的风险。此类措施的一个例子，是在可行的地方为 Agent 提供短生命周期凭证，例如对于支持 OAuth2 的 API，如果 access/refresh token 模式可行，就可以采用；这种短暂性也可以通过自动化的 secrets rotation 和 dynamic secrets 方案实现。

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

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

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

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

解决方案

当你审视最优秀的团队如何构建和使用安全 Agent 时，你会注意到，他们会在 Agent 和凭证之间划出一条信任边界。毕竟，如果不能信任 Agent 安全地处理凭证，那为什么一开始还要给它任何凭证呢？把凭证交由位于 Agent 和它试图访问的服务之间的 proxy 层来代理，或许更合理。这正成为我们这个行业当前正在趋同的主要方法：credential brokering。

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

Agent Vault

今天，我们宣布 Agent Vault，一个处于 research preview 的开源项目，它有一个简单的想法：Agent 从一开始就不应该看到底层 secret。

借助 Agent Vault，我们正在重新思考 secrets 应该如何被 Agent 使用，并以一种兼顾人类使用体验的方式，优先围绕 Agent 来设计。我们相信，vaults 和/或 secret stores 会长期存在，但为了适配 Agent 的运行方式，secrets 的交付方式将发生巨大变化。

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

Agent Vault 项目让我们得以提前一窥一个趋势：我们相信，包括 Anthropic、Brex 以及一些开源项目在内，许多人都已经注意到了这一点，那就是将 Agent 与其凭证分离。

虽然我们预计 Agent Vault 的形态会在未来一年发生变化，而且在让它更容易为 agentic environment 配置方面还有大量工作要做，但我们相信，它代表着在正确理解 AI agents 的 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 的安全逻辑容器，其中包含定义 Agent 如何通过它代理请求的 services。
• credential 是存储在 vault 中的敏感值，Agent Vault 会将其附加到被代理的请求上。这可以是 API key、数据库凭证、password，或任何其他敏感材料。
• service 是一个 host，例如 api.stripe.com，Agent 可以通过 proxy vault 访问它。在向 vault 添加 service 时，你需要指定该 service 的 hostname 以及它的 authentication scheme（例如 Bearer、API Key 等）；你可以指定一个 vault credential 作为 service authentication 的一部分，也可以省略它并将 proxy 视为 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、CLIs 和 runtimes 将流量重定向到 proxy，并在 TLS 层建立信任，使 Agent 将 vault 视为有效的 upstream。最后，你需要在网络层切断所有出站流量访问，使得 sandbox 或受限环境只能访问 Agent Vault 实例。

最终的结果是这样的流程：

1. Agent 调用一个 CLI command、SDK method、MCP tool，或者向 LLM 或 API service（如 api.anthropic.com）发起一个 API call。
2. 请求会自动通过 Agent Vault 路由，而 Agent 对此一无所知。
3. Agent Vault 拦截该请求，附加 credential，应用任何预定义规则，并将请求转发到目标地址。
4. Voila。请求返回给 Agent，Agent 完成其工作。它从未看到底层 secret，也无需修改其工作流。

虽然 Agent Vault 的初步设计在使用上还有些笨重，而且我们本希望有更多时间来打磨围绕它的 developer experience，尤其是 Agent 开始通过它代理请求时的配置体验；但 AI 发展的速度实在太快，我们认为最好先将这项技术开源，并与社区一起逐步改进，让它能够在所有 agentic use case 中无缝工作，因为每一种场景都有自己的细微差别。

设计架构

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

我们意识到，无论 Agent 是调用 API、通过 CLI shell out、使用 SDK，还是调用 MCP tool，最终每个请求都会变成一个出站 HTTPS connection。接口在技术栈顶部是分散的；在底部则是汇合的。代理凭证最合适的位置，是接口之下，也就是每个 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 的一种措施。在完整部署中，网络 必须 被锁定，以确保所有出站流量都被强制通过 Agent Vault。

请求实际如何流动

当 Agent 试图访问像 api.stripe.com 这样的 service 时，它的 HTTP client 会使用 HTTP CONNECT 与 Agent Vault 建立一个 tunnel。对于传统 proxy 来说，这个 tunnel 是不透明的，只会简单转发加密流量。对于 credential brokering 而言，这种模式行不通，因为没有办法在看不到请求内容的情况下注入 headers。

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

在这一点上，Agent Vault 就可以匹配该请求，剥离 Agent 附加的任何 credentials，从其加密存储中注入正确的 credential，并在完成正确验证的情况下与真实的 upstream 建立新的 TLS connection。MITM 架构意味着 Agent Vault 在未来可以扩展出类似 firewall 的功能，在 parameter 级别分析和处理请求。

响应会沿着相同路径返回，而从 Agent 的视角看，什么都没有改变；它发出了一个正常的 HTTPS 请求，并收到了一个正常的响应。区别在于，它从一开始就没有处理过那个 credential。

为什么这行得通

因为这一切都发生在 application layer 之下，所以 integration surface 几乎被压缩到了最小，同时 policy 在各处保持一致。Allowlisting、rate limiting、audit logging，以及按 Agent 划分的 credential scoping，都可以在 APIs、CLIs、SDKs 以及 Agent 使用的任何其他接口上统一强制执行，而无需这些层中的任何一层理解 secrets。

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

这一切都回到了一个简单的想法：如果 Agent 不能被信任持有 credentials，那它就不应该拥有它们。

试试看

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

你应该注意到，Agent Vault 是一项实验性服务，我们预计在接下来的几个月里会对 proxy 的形态、ergonomics、安全性和可扩展性进行重大更新。就近期 roadmap 上的几个事项来说：我们希望继续降低 self-hosting Agent Vault 以及将其集成到不同 Agent 和 Agent orchestration use case 中的摩擦，提升项目安全性，并增加更多 credential 和 firewall 功能，使其更加完善。

总而言之，我们相信 credential brokering 是面向 Agent 的 secrets management 的下一步正确方向，并鼓励社区通过探索 repo、阅读 docs，以及为代码库贡献来参与进来。

另外，如果你的组织正在评估面向需要 production-grade reliability 和 enterprise support 的 Agent deployment 的 credential security，欢迎随时 联系我们的团队，我们很乐意向你介绍我们为商业路径准备的内容。

Tony Dang

Product, Infisical

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