AI Agent不要拿长期Key：短期凭证和代理签名怎么设计

Written by

把长期API Key直接放进Agent环境，是很多团队早期接入AI工具时的捷径。它简单，但代价很高：一旦提示注入、日志泄露、插件越权或开发机被扫到，攻击者拿到的是一个长期有效的通行证。

Agent能自动读文件、调用工具、访问网络时，凭证策略必须比普通脚本更谨慎。

长期Key的问题不只在泄露

长期Key泄露当然危险，但即使没有泄露，也会带来治理问题。它通常权限过大、归属不清、难以按任务追踪、离职或项目结束后容易遗留。Agent执行的是多步任务，某一步工具失败后可能反复重试，长期Key会让这种错误持续放大。

短期凭证的思路是：Agent只拿到完成当前任务所需的最小权限，并且很快过期。

一种更稳的做法是让Agent不直接接触上游Key，而是调用内部代理。代理根据任务、用户、项目和工具类型生成签名请求，检查权限后再转发。Agent看到的是一次性凭证或受限会话，而不是长期供应商Key。

这样即使Agent上下文被注入，攻击者也很难把凭证带到另一个环境继续使用。

短期凭证不只是设置过期时间，还要收缩范围。比如只允许调用某几个模型，只允许读取某个知识库，只允许访问某个工单，不允许上传文件或发外部邮件。凭证应绑定任务ID、用户ID和过期时间。

在 https://top-api.cc 这样的AI中转站场景里，可以把不同Agent、团队和项目拆成独立Key，再配合内部代理生成短期访问策略。这样既能保留统一API入口，又能降低单个Agent失控时的影响面。

短期凭证如果无法追踪，就只是一层包装。系统应该记录凭证签发、使用、过期、拒绝和吊销事件。异常情况包括：同一凭证在不同IP使用、过期后仍被调用、单任务内请求次数异常、模型或工具范围突然变化。

AI Agent越自动化，越不能依赖“长期Key保平安”。短期凭证、代理签名和最小权限组合起来，才能把一次提示注入或工具误用限制在可控范围内。