Infisical Agent Vault：让 AI Agent 永远拿不到真密钥的凭证代理
阅读时间: 大约 9 分钟
Infisical Agent Vault：让 AI Agent 永远拿不到真密钥的凭证代理
把 ANTHROPIC_API_KEY、GITHUB_PAT 直接塞进环境变量交给 AI Agent，等于把家门钥匙交给一个会犯错、还可能被 prompt 注入的程序。密钥一旦进入 Agent 的上下文或磁盘，就可能被它”好心办坏事”地打印出来、写进日志，或被注入攻击骗走。Infisical 开源的 Agent Vault 给的答案很直接：Agent 本就不该持有凭证（Agents should not possess credentials）。
一、背景：凭证外泄是 Agent 时代的新安全问题
传统密钥管理的思路是”把密钥分发给应用”。这套模型在 AI Agent 上失效了：Agent 是能被 prompt 注入诱导的程序，一旦它手里有真 key，就可能被诱导外泄（credential exfiltration）。Agent Vault 要解决的正是这一问题——它不把真 key 交给 Agent，而是把密钥存进自己的保险库，强制 Agent 的出站请求全部经过它，由它在请求转发到目标 API 之前把真凭证贴上去。
二、概念：一个夹在中间的 MITM 代理
Agent Vault 既是保险库又是代理服务，以单个二进制同时充当服务端与 CLI 客户端，采用 MITM（中间人）代理架构。按官方设计，它应部署在与 Agent 不同的机器上，从物理网络上保证 Agent 无法直接够到密钥。
工作时：
- Agent 的环境被引导（bootstrap）为使用
HTTPS_PROXY，所有出站请求先到 Agent Vault； - Agent 手里只有占位符，例如
__anthropic_api_key__； - Agent Vault 在出站请求上把占位符替换成真凭证，或直接替换整个 auth 头，再转发到 Anthropic、GitHub 等目标；
- Agent 自始至终看不到真 key。
三、核心能力（官方 README）
| 能力 | 说明 |
|---|---|
| 凭证代理（Credential Brokering） | 在 Agent 不持有真凭证的前提下，代其访问 LLM 厂商、GitHub 等服务 |
| 可插拔凭证存储 | 后端可用本地加密库，也可外接 Infisical，从而用上动态密钥等能力 |
| 透明集成 | 兼容现有 MCP、CLI、SDK、API，靠 HTTPS_PROXY + MITM 透明接管，不改业务代码 |
| 出口过滤（Egress Filtering） | 控制哪个 Agent 能访问哪些服务与具体端点 |
| 请求日志 | 检查已鉴权流量，用于监控与诊断 Agent 行为 |
默认情况下，不匹配任何服务的请求会按普通代理流量直接放行；把保险库切到严格拒绝模式（unmatched_host_policy=deny）后，未匹配主机的请求会被直接以 403 拒绝。这相当于在网络层给 Agent 划了一条最小权限边界。
四、可核对数字与口径偏差
- 我调研时该仓库约 2.3k star、158 fork、330 次提交，以 Go 编写，提供 Dockerfile，并支持 PostgreSQL 用于生产部署；
- 开源版与商业版是分层的：官方 README 明确区分”Agent Vault（本项目，单二进制、自包含、存本地加密库）“与”Infisical Agent Vault（商业版，内置于 Infisical 平台，服务分组为访问包、Agent 通过有时限的会话接入、权限由 Infisical 访问控制治理）“，并直言**“生产与企业场景推荐使用 Infisical Agent Vault”**——开源版更像能力展示与自托管入口，企业级能力在商业侧；
- MITM 的隐含前提：Agent 所在环境必须信任 Agent Vault 签发的证书（自定义 CA）。这是一个需要运维的信任锚，配错或被绕过都会破坏安全模型；
- 遥测：提交历史里有”添加匿名使用遥测（anonymous usage telemetry）“的记录，对隐私敏感的自托管团队应主动关闭；
- 所有流量经过同一代理，它本身成为单点（koala 点评也指出了这一点），高可用需要自行部署多副本。
五、优势与局限
优势：
- 把安全下沉到模型管不到的位置：不靠 prompt 约束 Agent 守规矩，而是在网络层拦截，覆盖面比 MCP Server 内做权限校验更广（连 Agent 自己写代码直接发 HTTP 这条路也被堵住）；
- 透明、侵入小：靠
HTTPS_PROXY引导即可接入，兼容现有 CLI/SDK/MCP； - 可观测：已鉴权流量全量记录，便于审计 Agent 行为；
- 与 Infisical 生态衔接：需要动态密钥、细粒度访问控制时可平滑升级到商业版。
局限：
- 证书信任是硬前提：MITM 要求 Agent 环境信任其 CA，部署不当会留后门；
- 单点与性能：所有出站流量过代理，是瓶颈也是故障点；
- 遥测默认开启：隐私敏感场景需手动关闭；
- 企业能力在商业侧：访问包、时限会话、精细权限等”真正生产级”特性属于 Infisical 商业产品。
六、适合谁用
- 跑远程/不可信编码 Agent（如远程 Claude Code）的团队：不想把真 API key 交给可能被注入的执行环境；
- 对 Agent 出站行为要审计与限流的安全团队：需要一份已鉴权流量的完整记录；
- 已经在用 Infisical 的组织：开源 Agent Vault 是通往商业 Agent 凭证方案的自然一步。
它代表了 Agent 安全从”靠提示词约束”转向”靠网络层强制”的共识方向，但落地时务必把 CA 信任、遥测开关与高可用副本一起规划好。
值得把它和通用工具做个区分：mitmproxy、Squid 这类正向代理当然也能做流量拦截，但要让它们在转发时”按请求注入对应凭证、按 Agent 做出口白名单、并提供多租户与 Agent 专用 CLI”，需要大量二次开发。Agent Vault 官方称自己是”purpose-built”，正是把这些为 Agent 场景定制的能力做进了产品——这也是它区别于”拿通用代理硬改”的核心价值。从部署形态看，单二进制 + Docker + PostgreSQL 的组合，对已经有运维能力的团队并不陌生，学习成本主要在 MITM 证书信任这一环。
更进一步看，Agent Vault 不是孤立工具，而是 Infisical 把既有企业密钥管理能力延伸到 Agent 场景的一步：开源版帮团队建立”Agent 不该持有凭证”的直觉与最小可用闭环，等规模上来、需要访问包与时限会话时，再自然过渡到商业版。这条”开源建立习惯、商业承接规模”的路径，在密钥管理赛道并不新鲜，但在 Agent 安全这个新问题上，它是目前完成度较高的一套公开参考实现。