在 AI 智能体逐步进入生产环境的今天，凭证管理正在成为制约智能体安全落地的关键瓶颈。传统 secrets management 工具将凭证直接返回给调用方，这种模式在确定性系统中运行良好，但在面对非确定性、可能受到 prompt injection 攻击的 AI 智能体时，凭证泄露风险急剧上升。Infisical 推出的开源项目 Agent Vault 提供了一种全新的解决思路：通过网络层的凭证代理机制，让智能体永远不直接接触敏感凭据，从架构层面消除凭证外泄的可能性。
传统 secrets management 的适用性困境
在软件开发中，HashiCorp Vault、AWS Secrets Manager 等工具已经是成熟的凭证管理方案。这些工具的典型工作流程是：应用向 vault 发送请求，vault 验证身份后直接将明文凭证返回给应用，应用随后使用这些凭证访问目标服务。这一模式在传统应用中运行良好，因为应用代码是确定性的，只要代码不主动输出凭据，凭证就相对安全。
然而，AI 智能体的工作方式与传统应用有本质区别。智能体的输出是非确定性的，其行为受 prompt、上下文和外部输入的共同影响。近年来安全研究已经广泛讨论了 prompt injection 攻击的风险：攻击者可以通过精心构造的输入诱导智能体执行未授权操作。更关键的是，智能体的上下文窗口中可能包含系统 prompt、工具定义、历史对话等敏感信息，一旦智能体被诱导输出这些内容，存储在内存或上下文中的凭证就会直接暴露。
传统 secrets management 工具无法解决这一问题，因为凭证在返回给智能体的那一刻就已经处于风险之中。Agent Vault 的核心洞察是：与其在返回凭证后试图保护它，不如从根本上改变凭证的传递方式 —— 让凭证根本不经过智能体的内存和上下文。
代理架构设计：网络层注入而非应用层返回
Agent Vault 采用了一种独特的代理架构：智能体不是获取凭证，而是通过一个本地代理发送请求，代理在网络层自动注入正确的凭证，然后转发请求到目标服务。整个过程中，智能体只看到正常的 HTTP 响应，从未见过任何凭证。
从技术实现来看，Agent Vault 在本地启动两个关键端口：14321 端口提供 HTTP API 和 Web UI，用于 vault 管理；14322 端口则是一个 TLS 加密的透明代理，智能体的所有 HTTPS 流量都通过这个端口进出。当智能体发起一个对外部 API 的请求时，请求首先到达 Agent Vault 的代理层，代理根据请求的目标主机和配置规则，从保险库中取出对应的凭证，在 TLS 握手阶段完成身份认证，然后将请求转发到目标服务器。整个过程对智能体是完全透明的 —— 它只需要像平常一样调用 fetch 或其他 HTTP 客户端，不需要任何额外的 SDK 集成。
这种设计带来了显著的安全收益。首先，凭证永远不会出现在智能体的内存空间中，不存在于其上下文窗口里，因此即使用户通过 prompt injection 诱导智能体输出「当前使用的 API 密钥是什么」，智能体也无法给出答案，因为答案根本不在它可达的范围内。其次，即使攻击者能够截获智能体的网络流量，看到的也只是与 Agent Vault 之间的加密连接，目标服务的凭证完全不可见。
部署模式：从 CLI 到容器沙箱
Agent Vault 提供了灵活的部署模式，以适配不同类型的智能体运行环境。对于本地运行的智能体如 Claude Code、Cursor、Codex 等，开发者只需使用 Agent Vault 的 CLI 工具进行包装：运行 agent-vault run -- claude，Agent Vault 会创建一个作用域受限的会话，设置 HTTPS_PROXY 和必要的 CA 证书环境变量，然后启动智能体。之后智能体的所有 API 调用都会经过代理层，无需任何代码修改。
对于运行在容器环境中的智能体，Agent Vault 提供了 TypeScript SDK。开发者可以在智能体启动前通过 SDK 创建会话，获取代理配置和 CA 证书，然后将它们注入到容器中。SDK 会返回完整的环境变量配置，包括 HTTPS_PROXY、NO_PROXY、各类 SSL_CERT 路径等，开发者只需要将这些环境变量传入容器，并将 CA 证书挂载到指定路径即可。这种设计使得 Agent Vault 可以与 Docker、Daytona、E2B 等主流沙箱环境无缝集成。
对于高安全场景，Agent Vault 还提供了容器沙箱模式。通过 agent-vault run --sandbox=container 启动时，智能体被放入一个网络 egress 完全锁定的容器中，只能访问 Agent Vault 代理。iptables 规则确保即使智能体尝试绕过代理直接连接外部网络，连接也会被丢弃。这种模式对应了传统安全中的「非合作沙箱」概念 —— 无论智能体如何尝试，它物理上都无法接触到除代理之外的任何网络资源。
加密与审计：生产环境所需的安全基座
作为一款面向生产环境的工具，Agent Vault 在加密和审计方面也提供了完整的工程化支持。凭证在保险库中静态加密存储，采用 AES-256-GCM 算法，使用随机生成的数据加密密钥（DEK）进行保护。DEK 本身可以用主密码通过 Argon2id 密钥派生函数加密，这意味着一旦需要轮换主密码，不需要重新加密所有凭证 —— 只需要用新密码重新包装 DEK。对于无交互的 PaaS 部署场景，Agent Vault 也提供了无密码模式。
每个经由代理的请求都会被记录到审计日志中。日志包含请求方法、目标主机、路径、响应状态码、延迟以及涉及的凭证键名，但刻意不记录请求体、请求头和查询参数，以平衡安全审计需求与隐私合规要求。日志保留策略可以在 vault 级别配置，管理员可以根据合规要求设置不同的保留周期。
工程落地的关键考量
在将 Agent Vault 集成到智能体生产环境时，有几个工程问题值得深入思考。首先是密钥轮换的自动化程度：虽然 Agent Vault 本身不直接提供密钥轮换功能，但它与现有的 secrets management 工具兼容 —— 企业可以在 HashiCorp Vault 或云服务商的 secrets manager 中管理轮换后的新密钥，Agent Vault 只需配置从外部源同步最新凭证即可。其次是作用域限制的粒度设计：Agent Vault 支持为不同的智能体会话分配不同的凭证集，这要求在设计时仔细规划每个智能体的权限边界，避免过度授权。
最后是监控告警体系的构建。由于 Agent Vault 记录了所有经代理的请求，运维团队可以将这些日志接入 SIEM 系统，监控异常的目标主机访问模式、异常的请求频率或响应状态码，以及凭证使用情况的统计趋势。这些信号可以在凭证被滥用的早期阶段提供告警。
Agent Vault 为 AI 智能体的凭证管理提供了一种范式转变：从「获取并使用凭证」到「通过代理透明使用凭证」。这种架构不依赖于智能体的实现细节，不要求智能体代码进行任何修改，就在网络层实现了凭证与智能体的彻底隔离。随着智能体在企业生产中的逐步落地，这种从架构层面解决安全问题的思路，值得安全团队和平台工程团队深入评估。
资料来源：Infisical Agent Vault GitHub 仓库（https://github.com/infisical/agent-vault）