Agent Vault：AI Agent 不应该持有你的密钥

当我们让 AI Agent 调用外部 API 时，最直觉的做法是把 API Key 交给它。但仔细想想，这等于把你家钥匙交给一个你不完全信任的人 — 而且这个人还可能被别人忽悠（prompt injection）。

Infisical 开源的 Agent Vault 给出了一个干净的解法：Agent 永远不碰密钥，所有凭证在网络层注入。

Agent Vault 的核心理念：brokered access, not retrieval

问题出在哪

传统的密钥管理假设调用者是可信的 — 你从 Vault 拿到密钥，负责任地使用它。但 AI Agent 是非确定性系统，它可能：

• 被 prompt injection 攻击，泄露环境变量里的密钥
• 在日志、调试输出中意外暴露凭证
• 把密钥拼接到不该去的请求里

这不是理论风险。随着 Claude Code、Cursor、Codex 这类 coding agent 越来越多地操作真实环境，凭证安全已经是一个现实问题。

Agent Vault 怎么做的

思路很简洁：不要给 Agent 密钥，给它一个代理。

Agent → HTTPS_PROXY (Agent Vault) → 目标 API

Agent 正常发 HTTP 请求，Agent Vault 作为透明代理在网络层注入凭证。Agent 的视角里，它只知道”我能调这个 API”，但从来看不到 API Key 长什么样。

实际使用效果：agent 通过代理访问 API，凭证在网络层自动注入

几个设计决策值得注意：

Scoped Session — 每次 agent-vault run 创建一个隔离的会话，只暴露该 vault 下的凭证。Agent 进程结束，会话销毁。

AES-256-GCM 加密 — 凭证在磁盘上全量加密，master password 通过 Argon2id 派生密钥。换密码不需要重新加密所有凭证。

请求审计日志 — 每个经过代理的请求都记录 method、host、path、status，但不记录 body 和 header。刚好够你排查问题，又不会变成另一个泄露点。

为什么这个方向是对的

Agent 安全正在经历和容器安全类似的演化。早期大家把密钥写在 Dockerfile 里，后来有了 Docker Secrets、K8s Secrets、Vault。Agent 领域现在就处于”密钥写在环境变量里”的阶段。

Agent Vault 的思路 — 零知识代理 — 是这个演化的自然下一步。Agent 不需要知道密钥是什么，就像你的浏览器不需要知道 TLS 证书的私钥一样。

当然，它也有局限。目前只处理 HTTP 层的凭证注入，对于 WebSocket、gRPC 等协议还需要额外方案。而且”透明代理”模式要求 Agent 运行时能设置 HTTPS_PROXY，某些沙箱环境可能不支持。

实用场景

对于每天跟多个 AI 模型打交道的开发者来说，Agent 的凭证管理是个真实痛点。像 OfoxAI（ofox.ai）这样的多模型聚合平台解决了模型切换的问题，而 Agent Vault 解决的是 Agent 调用外部服务时的凭证安全问题 — 两者互补。

如果你在用 Claude Code 或 Codex 做日常开发，值得花 5 分钟跑起来试试：

curl -fsSL https://get.agent-vault.dev | sh
agent-vault server -d

一个 agent-vault run 命令就能把你现有的 Agent 工作流包起来。不改代码，不改配置，只是多了一层凭证隔离。

---

GitHub: Infisical/agent-vault

Agent 安全不是可以”以后再说”的事。当你的 Agent 开始操作生产环境的 API，每一个暴露的密钥都是一个等待被利用的漏洞。先把门锁好，再让 Agent 进屋。