当开发者快速搭建 AI Agent 时，把 API Key 写进配置文件、环境变量或系统提示词，往往是最顺手的选择。但对具备外部访问能力的 Agent 来说，这种便利正在变成安全漏洞的入口。开发者社区 Dev.to 上一篇关于 Agent 密钥管理的技术文章提出了一条更严格的原则：API 凭证应保存在模型无法查询的加密存储中，由可信运行时在出站请求时注入，而不是让 LLM 有机会读到明文。
密钥进入上下文，就进入了可被利用的风险面
文章引用的数据显示，GitGuardian 在 2025 年发现公开 GitHub MCP 配置文件中存在 24,008 个唯一 secret，其中 2,117 个为有效凭证。这些泄露并不是因为复杂攻击，而是因为不少配置指南本身就建议将密钥直接写入配置文件。
更深层的问题在于，语言模型无法稳定区分“数据”和“指令”。一旦密钥进入模型上下文，它就可能被复述、总结、记录，甚至在其他输入诱导下被发送出去。所谓上下文窗口并不是私密空间，而是同时连接提示词、工具调用、日志系统和记忆存储的共享表面。
- 系统提示词里直接写入 API Key，会被模型视为普通上下文内容
- 环境变量虽然能把密钥从源代码里移开，但仍可能被 Agent 执行的代码读取
- 配置文件中的明文密钥会随仓库、日志或调试输出扩散
- 工具返回的错误信息和请求头，也可能把凭证重新带回上下文
“盲注入”模式：让模型只看到工具调用和结果
文章给出的替代方案是“blind injection”，即盲注入。其核心流程是：Agent 只发出工具名称、参数和占位符；可信运行时在模型视野之外从 vault 中取出凭证，附加到实际 API 请求中；最后模型只接收经过清洗的结果，而不接触原始密钥。
在示例伪代码中，模型发出的请求里包含的是 Bearer {{github_token}} 这样的占位符，真正解析并替换为有效 token 的是运行时。返回给模型的内容也经过 redact 处理，只保留必要业务信息，例如请求是否成功、创建的资源编号等。
为防止这种模式被绕过，文章强调了两条护栏：
- 每个凭证都必须绑定允许访问的主机范围，避免注入指令把占位符导向攻击者服务器
- 工具返回中不得包含原始请求头、详细错误堆栈或可能回显凭证的调试信息
Prompt Injection 时代，最小权限和密钥隔离同样重要
文章还引用了开发者 Simon Willison 在 2025 年 6 月提出的“lethal trifecta”概念。当一个 Agent 同时具备访问私有数据、接触不可信内容以及对外通信三种能力时，它就可能被攻击者诱导读取私有信息并外传。API 密钥本身就是一种私有数据，因此最直接的防护方式是不让它进入模型上下文。
不过，密钥隔离并不能完全阻止 Agent 被欺骗，它限制的是被欺骗之后攻击者能带走什么。文章同时提到，MCP server 场景下还应遵循更完整的凭证加密实践，包括使用 AES-256 等成熟算法加密静态凭证、用 KMS 或 HSM 保护主密钥、按租户隔离、定期和事后轮换、绑定 token 受众，以及避免把客户端 token 透传到下游 API。
对正在构建 Agent 和 MCP 服务的团队来说，这意味着密钥管理要从“方便模型调用”转向“默认模型不可见”。Agent 仍然可以调用工具、执行操作，但不必持有那把最值得偷的钥匙。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-agent-de-api-mi-yao-wei-shen-me-bu-gai-chu-xian-zai-mo
