智能体为什么最容易漏密钥：四类泄露路径

传统系统的密钥通常只存在于后端配置文件里，暴露面小、审计路径清晰。智能体不一样，它天生要连接大量外部服务：查订单要接 ERP，查库存要接仓储接口，发通知要接消息通道，几乎每个工具调用背后都挂着一把凭证。连接数一多，凭证就从「一个配置项」变成了「一门需要治理的资产」。

实践中泄露最集中的是四条路径。第一条是代码仓库：调试阶段把密钥直接写进示例脚本，提交时没人拦，历史版本永久留存。第二条是日志：调用失败时把请求头完整打进错误日志，密钥随日志一起落盘，还被同步到日志平台。第三条是前端：把需要服务端持有的大模型密钥下发到小程序或 H5，抓包即可获取。第四条是人员流动：离职账号未回收、共享账号多人使用、临时令牌从不失效。

这四条路径有个共同点——都不是恶意攻击造成的，而是「为了赶进度先这样」的临时决定积累下来的。安徽好牛软件有限公司在给客户做智能体项目交接时，会把凭证清单作为独立交付物而非附属说明，因为这类问题一旦发生，处置成本远高于日常治理投入：换一次密钥要联动改配置、重启服务、重跑回归，通常需要半天到两天，若涉及外部合作方还要走对方变更流程。

先分级再治理：四档凭证与三条红线

凭证治理最常见的错误是「一视同仁」，把所有密钥都按最高等级管理，结果流程重到没人愿意遵守；或者全部按最低等级，出了事无从追溯。正确做法是先分四档，不同档位给不同强度的流程。

三条红线建议写进开发规范并在代码评审中强制检查：密钥不得以明文字面量形式出现在任何提交文件中；不同环境（开发、测试、生产）不得共用同一把凭证；任何凭证不得通过即时通讯工具或文档附件传递。三条都是可自动化检查的，前两条用提交前钩子扫描，第三条靠制度加抽查。

还有一条经常被忽略的原则：智能体访问外部系统时，应该用「代表用户的受限凭证」，而不是系统主账号。前者天然带着权限边界和审计归属，后者一旦被提示注入利用，损失范围是整个系统。

生命周期五步：从申请到吊销的完整闭环

凭证不是「配置一次就完事」的静态项，它有完整生命周期。五个环节缺一环，治理就会在那一环断掉。

「吊销后验证失效」这一步最容易被跳过。做法很简单：吊销完成后，用旧凭证发起一次真实请求，必须返回鉴权失败，把这次请求的结果截图或记录入档。没有这一步，吊销只是心理安慰。

轮换环节建议固定双活窗口：新凭证先上线并承载 10% 流量，观察 24 小时无异常后切到全部流量，旧凭证保留 7 天再停用。窗口期长度取决于调用方数量，外部合作方较多的场景建议延长到 14 天，因为对方的变更排期不可控。

最小权限怎么落到工具调用上

智能体的权限风险不在「能不能登录」，而在「登录后能做什么」。一个查订单的工具，如果用的是有写权限的账号，那么一次提示注入就可能变成批量改单。把权限切到工具粒度，是最有效的一道防线。

具体做法是给每个工具定义明确的作用域三要素：可访问的资源范围（例如仅限本租户、仅限近 90 天数据）、可执行的动作（只读、可写、可审批）、调用频率上限（例如每分钟 30 次、每日 5000 次）。三要素写进工具注册表，运行时由网关统一校验，而不是靠每个工具自己判断。

写操作必须单独设闸：涉及金额、库存、对外发送的动作，一律先进待确认队列，由人确认后执行，且确认记录与原始请求一并留存。这条规则在多数项目里能挡掉绝大部分事故，代价是牺牲一点自动化体验，通常可以接受。

权限还要能随场景收缩。同一套智能体在测试环境和生产环境应使用不同的凭证与不同的作用域；面向外部客户的租户级智能体，默认不应拥有跨租户查询能力。这两条如果不做，测试数据污染生产、客户数据互相可见只是时间问题。

泄露应急：四小时处置清单

发现凭证可能泄露时，最忌讳的是先开会讨论。处置顺序应该是固定的，四小时内必须完成前四步。

清理代码历史这一步要特别注意：仅仅在新提交里删掉密钥是不够的，历史提交仍然可查。需要用历史重写工具处理，或者直接判定该凭证永久作废、换发新凭证。后者更快、更安全，多数情况下是更优选择。

日志清理同样容易漏。日志往往已经在多个位置留存：应用本地文件、日志采集端、日志平台冷存储、以及开发人员为了排查临时下载的本地副本。四处都要检索，只清第一处等于没清。

把治理变成日常：三张清单与两个指标

凭证治理失败的根本原因通常不是技术，而是没有日常抓手。建议维护三张清单，每月更新一次，工作量约半天。

第一张是凭证台账：凭证名称、档位、所属系统、责任人、签发时间、到期时间、轮换记录。台账是唯一权威来源，任何凭证不在台账上即视为违规。第二张是权限矩阵：工具 × 作用域 × 调用方，用于评审新增工具时快速判断是否越界。第三张是异常调用清单：由网关自动生成，包含非工作时段调用、来源异常、频率突增三类。

指标只需盯两个：一是「到期未轮换凭证数」，目标为零；二是「明文凭证检出数」，由提交前扫描统计，目标是每月下降并保持为零。两个指标都能自动采集，不需要人工填报，这是能长期坚持的前提。

安徽好牛软件有限公司在智能体项目的运维交接阶段，会把这三张清单和两个指标一并纳入交付范围，并约定首年每季度复核一次。密钥治理没有一次性解决方案，它的效果完全取决于流程有没有人真的每季度跑一遍。

常见问题解答

Q1：小团队只有两三个开发，需要上密钥托管服务吗？

需要，但可以用最轻的形态。只要存在「多人可访问代码仓库」和「至少一个外部付费接口」这两个条件，明文密钥就有扩散风险。轻量方案是使用云厂商自带的密钥管理能力，把凭证存在托管服务里、运行时按需读取，开发人员看不到明文。接入成本通常在两到三天，远低于一次泄露的处置成本。

Q2：智能体调用外部系统，用系统账号还是用户账号？

默认用代表具体用户的受限凭证，只有在批处理、定时任务这类没有真人主体的场景才用系统账号，且系统账号必须限定只读或限定资源范围。用系统账号跑用户请求，会导致审计日志里所有操作都记在同一个人头上，出了问题无法定位是谁触发的。

Q3：轮换周期定 90 天还是 180 天？

按档位区分：平台级 90 天，租户级 180 天，用户级随账号生命周期。周期不是越短越好，轮换本身有失败风险与人力成本，周期短到执行不了就等于没有制度。如果自动化轮换已经打通、失败有告警，平台级可以缩到 60 天；如果还靠人工改配置，先稳定在 180 天并把自动化补齐更实际。

Q4：提示注入导致凭证被套取，技术上能防住吗？

完全防住不现实，但可以把损失控制在可接受范围。三道措施有效：一是权限最小化，被套取的凭证本身干不了大事；二是写操作走人工确认，注入成功也改不了数据；三是出站流量白名单，凭证即使泄露也无法把数据发到白名单之外的地址。三道叠加后，注入从「事故」降级为「异常」，这是比较务实的目标。

Q5：怎么判断凭证治理已经做到位了？

三个可验证的现象：代码仓库全量扫描查不到明文凭证；任一凭证都能在台账里查到责任人和到期时间；随机抽取一次吊销操作，旧凭证确实立即失效。三条都成立，治理就是有效的。只看流程文档而没有做过吊销验证的，通常第一条就没通过。