Agent Proxy：为 Agent 提供安全的凭证注入

Agent Proxy：面向 Agent 的安全密钥代理

四月，我们推出了 Agent Vault，这是一个开源的 HTTP 凭据代理与保险库，也是首批专为 Agent 代理凭据而构建的独立 MITM 透明代理实现之一。今天，我们宣布它的商业级继任者：Infisical Agent Proxy。

在 Infisical，我们每月处理数十亿个密钥，涵盖应用配置、数据库凭据、API 密钥等，服务于各种类型的工作负载。这其中就包括 AI Agent——它们同样会消费密钥，只是消费的格式不同。过去一年里，我们观察到凭据代理已成为对抗 Agent 凭据窃取的主流手段。凭据代理允许 Agent 使用凭据访问服务，而无需读取任何底层值。其工作原理是让请求经过一个专用代理，由该代理在网络边界附加凭据，再把请求转发至外部目的地。

Agent 代理的概念如今已相当普遍，我认为它代表了一种新的基础设施原语，与沙箱并列，专为满足安全 Agent 部署所需的安全保障而设计；我也相信，它将是构成不久后 AI 云的众多组件之一。

今天，我们将深入探讨密钥代理，以及 Agent Proxy 如何为任何安全 Agent 基础设施部署提供所需的商业级代理。希望这篇文章读起来有趣，也能对任何需要安全地为 Agent 配置服务访问权限的人有所帮助；你甚至可以考虑试用一下 Infisical Agent Proxy。

我们如何走到这一步

如果你还不熟悉凭据窃取和 Agent 代理这个领域，我们最初的 Agent Vault 发布文章 对这方面有更完整的阐述。其中详细探讨了：为什么为确定性调用方设计的传统密钥管理，在面对非确定性参与者（即 Agent）时会失效。

简而言之，我的观点是，当今大多数计算范式并非为 Agent 设计，而是为具有固定执行路径的传统工作负载设计的。毕竟，在计算历史的大部分时间里，自主软件 Agent 更多是科幻小说而非工程现实。如今它们已成为现实，我们也渐渐发现，软件基础设施所依赖的许多假设已不再成立。

Agent 是非确定性参与者，这带来了全新的挑战：其底层执行过程具有概率性，因此很容易通过提示注入等攻击向量泄露密钥。这相当于机器层面的社会工程学攻击——操纵 Agent 泄露信息，或执行它原本不会执行的操作。但挑战不止于此。提示注入几乎可以来自任何地方，从显式的用户输入，到 Agent 在正常工作中摄取的数据。即便完全没有攻击者，大多数组织也不希望 Agent 把凭据发送给 LLM 提供商。这种情况很快就会变得相当棘手。

至少在当前状态下，Agent 不能被信任直接持有密钥。必须在每个 Agent 旁边部署一个专用的正向 HTTP 代理（无论是专用服务、sidecar 还是出口层），以便安全地代理它访问外部世界所需的凭据。

如今，许多复杂的 Agent 部署都已汇聚到这种模式上。这与 Anthropic 的 Managed Agents 架构博客、Vercel 的凭据代理、Cloudflare 的出站 Workers，以及最近的 Claude Tag 架构 所描述的原则一脉相承。虽然每种密钥代理方案在架构细节上各有不同，但总体原则是一致的：Agent 无法接触真实的凭据值；即便持有，那也只是假凭据，由代理在边界处替换为真实凭据。

这正是我们构建并开源 Agent Vault 的原因，它是首批面向 Agent 的专用密钥代理实现之一。

我们学到了什么

事实证明，当你以恰当的使用体验解决凭据窃取这类"火烧眉毛"的问题时，产品很快就会被采用。尽管几乎没做什么推广，Agent Vault 还是在短短几个月内于 GitHub 上突破了 2,000 星，覆盖数万次安装、数百万次 Agent 运行，以及数十种 Agent，包括 Claude Code、OpenClaw，甚至非 Agent 类的不可信代码。

回顾来看，Agent Vault 的成功可归结为几项产品工程决策，正是这些决策共同让这种密钥代理实现变得切实可用：

• 架构：Agent Vault 采用了一种非侵入式的透明 MITM 代理方式，在网络边界代理凭据。无论 Agent 使用 CLI、SDK、MCP 还是原生 API 调用，请求最终都会落到 HTTP 层，由代理透明地代为处理。
• 安全性：Agent Vault 建议将代理部署在与 Agent 不同的主机上，从而在负责代理凭据的组件与消费凭据的不可信代码之间建立更强的信任边界。
• 邻近性：Agent Vault 被设计为正向代理，尽可能靠近 Agent 运行，位于同一专用网络内，在不牺牲安全边界的前提下最大限度降低延迟。

然而，随着采用率的增长，有一件事变得越来越清晰：Agent Vault 需要与密钥存储做更紧密的集成，最好还能接入像 Infisical 这样更高级的密钥管理平台，以避免密钥存储碎片化，并通过动态密钥、密钥轮换、版本控制、审计等丰富功能扩展代理密钥的能力。回想起来，我们把两个不同的概念捆绑在了一起：密钥存储和密钥代理。

虽然凭据代理解决了凭据窃取问题，但它只是密钥向 Agent 交付的"最后一公里"方式，而不是一个独立的平台。密钥代理应当遵循 Kubernetes Operator（如 External Secrets Operator (ESO)）的模式：从外部密钥存储获取密钥，并在运行时提供给工作负载；区别仅在于，这里是借助代理流量的凭据注入，把密钥提供给 Agent。代理不应成为密钥的事实来源；它只需按需检索密钥，并安全地交付给 Agent。

这一认识催生了 Agent Proxy。

介绍 Infisical Agent Proxy

Infisical Agent Proxy 是一个密钥代理，它从 Infisical 取回密钥并提供给 Agent，设计灵感来自我们从 Agent Vault 的成功中学到的一切。不同之处在于，它自身不存储任何密钥，而是把密钥管理交给 Infisical 处理，只专注于向你的 Agent 代理密钥，从而使代理本身保持轻量、无状态且高度可扩展。

通过 Agent Proxy，我们为你的 Agent 需要访问的常见服务提供了 30 多个预设，涵盖 LLM 提供商（Anthropic、OpenAI 等）以及 GitHub、Slack、Datadog 等服务。如果没有现成的预设，你也可以随时请求添加，并通过主机模式与代理规则注册自定义服务。

我们还在持续反思 Agent 应当如何消费密钥：我们相信保险库和/或密钥存储会一直存在，但密钥的交付方式将发生巨大变化，以适应 Agent 的实际运行方式。这一变化的一部分，便是用于保护 Agent 实现的 HTTP 代理；Infisical Agent Proxy 正是这样的解决方案。如今，它与你已经熟悉的密钥管理器——Infisical——紧密集成。

作为 Infisical 密钥管理的一部分，Agent Proxy 会继承你在 Infisical 中可能已有的全部密钥、集成、自动轮换、RBAC、审计日志、访问策略和工作流。

试一试

从部署角度来看，Agent Proxy 刻意保持轻量：它随 Infisical CLI 一起提供，也可以作为 Docker 容器部署。它是任何 Infisical 密钥管理方案的一部分，所有套餐均可使用。

在生产环境中，我们建议将 Agent Proxy 部署在独立主机上，并让该主机尽可能靠近你的 Agent。Agent Proxy 应尽量贴近 Agent 运行——无论是位于同一专用网络、与沙箱 worker 并行，还是作为负责代理出站流量的专用 sidecar。让代理在物理上靠近 Agent，可以在保持不可信执行环境与凭据处理组件之间信任边界的同时，最大限度降低延迟。

从概念上讲，只需四个步骤：

1. 在 Infisical 中定义一个代理服务，指定 Agent Proxy 应代理哪些主机名、身份验证方式以及要附加哪些密钥。你可以从 30 多个预设中直接选用，也可以自行配置。
2. 为代理和 Agent 分别创建独立的机器身份，让两者能够独立完成身份验证，并且各自只获得所需的权限。
3. 将 Agent Proxy 与你的 Agent 基础设施一起部署。
4. 将你的 Agent 配置为通过代理发送出站 HTTPS 流量。

你可以在此处的文档中找到 Agent Proxy 的完整设置指南。

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