AI 应用 API 密钥安全：推理密钥是支付工具而非普通凭证

推理密钥是一种带有 API 的支付工具。正是这个属性使其与你管理的大多数凭据不同：盗取它的人不需要你的数据就能获利，因为密钥本身就是他们想要购买的东西。

什么让推理密钥与众不同

它可以直接变现。被盗的数据库凭据需要有买家购买数据。被盗的推理密钥在数小时内就会被转售，自动化扫描器持续扫描公开仓库寻找的正是这类东西。

损失在你睡觉时也在累积。按量计费意味着损失是 elapsed time 和 rate limit 的函数，而非单次事件的风险。这就是用硬上限而非谨慎监控来控制风险的理由。

它比大多数 secret 传播得更广。笔记本、评估脚本、同事的笔记本、CI 任务、Agent 自己的环境。每一次都是你不控制的一个副本。

爆炸半径往往是整个账户。如果提供商提供一个具有完全访问权限的密钥，泄露就是全面的。如果提供带范围的密钥，就用它们——这是可用的最大杠杆。

AI 应用特有的泄露路径

通用建议——不要提交 secrets、使用 manager——是正确的，也是广泛发布的。以下是那些只因为系统中有模型而存在的路径，而且它们是能扛过常规审查的路径：

上下文中的密钥。粘贴到系统 prompt 中的密钥，让某个工具"能访问它"。现在它距离 transcript 只有一次转述，而 transcript 是被存储的。

Traces 和可观测性。LLM tracing 工具默认捕获完整的请求体。如果 header、工具参数或环境转储最终落入一个 span，你的密钥就在一个比你的 secret manager 访问列表更宽的第三方仪表板中。

Prompt 和响应日志。同样的问题，在你自己的基础设施中。在错误时打印请求对象的 logger 会打印 Authorization header。

评估数据集。复用的生产流量作为 eval 集，然后与供应商共享或提交到仓库。在存储前 redact，而不是在共享前 redact——共享的副本不会是唯一的副本。

客户端调用。任何发送到浏览器或移动 binary 的密钥都是公开的。混淆和代理域名改变不了这一点；只有服务端 broker 才能。

模型引用自己的配置。如果 Agent 能读取文件或环境变量，一份文档可以要求它打印出来。拒绝这个能力而非拒绝这个请求。

笔记本输出单元。提交的 .ipynb 文件会保留打印环境的 cell 输出。

范围控制优于轮换

轮换限制的是你已检测到的泄露的窗口。范围控制限制的是你未检测到的泄露的损失——未检测到才是常态。配合无范围密钥的轮换计划是在错误场景下优化的控制。

实践层面：每个 workload 一个密钥，绝不要每个公司一个共享密钥。生产、预发、CI 和每个开发者分开密钥，这样撤销一个只会让一个 workload 故障，而不会让所有人出事故。在提供商支持的地方，给每个密钥附加消费上限、速率限制、允许的模型列表和 IP 或来源限制。并且给每个密钥起一个能标识其所有者和用途的名称，因为无法归属的密钥是谁都不敢撤销的密钥。

最后一点决定了其他控制在压力下是否可用。在事件期间，问题永远是"我现在能 kill 这个密钥而不会影响我关心的东西吗？"，答案完全取决于一个密钥是否服务一个 workload。单个共享密钥让诚实的答案是"不能"，这就是为什么组织会在已知凭据已泄露的情况下再服务一天，而某人还在弄清楚它是干什么的。

生命周期，具体来说

"使用"行中的 field-allowlist 细节比字面上看起来更重要。在有人添加你未预料到的 header 时，黑名单 secret 字段名就会失效；白名单允许记录的内容是失败安全的构建方式。

检测泄露的密钥

假设检测将来自模式而非"密钥泄露"的告警。值得接入的信号：消费率偏离自身基线而非穿越固定阈值；来自陌生区域或 ASN 的请求；workload 从不调用的模型的使用；workload 从不运行时段的流量；以及请求组合——超长 prompt、不寻常的采样参数——看起来不像你的应用。

在需要之前就把响应写下来：先撤销再调查，因为错误撤销的密钥代价是一次部署，而活着被盗的密钥代价是按小时累积的。

每个密钥的范围控制和每个密钥的消费上限是将泄露的推理密钥从事件变成有上限费用的两个控制。Multigrid 按 workload 发密钥并附带各自的限制，这也意味着你用来告警的使用基线是按密钥而非按账户——当基线只有一个 workload 那么宽时，异常检测要容易得多。

Encrypting Third-Party Credentials at Rest

Model Denial of Wallet: Attacks That Cost You Money

Securing Tool Calls in an Agent