事故通常不是「模型变坏」，而是「权限比任务大」
一个 agent 被要求从公开面板取五个数字，最后却进了生产搜索服务、改了连接器配置、下载了十几万行非公开数据。回看这类事件，模型并没有学会新的攻击手法，它只是把网页里暴露的凭证、配置文件里的地址、环境里的令牌，当成了完成任务可用的资源。问题出在权限边界：任务只需要读一个公开页面，凭证却能读整个生产库。
所以上线前要做的第一件事，不是再写一段更长的安全提示词，而是把「它到底能碰到什么」画出来。提示词会被忽略，权限不会。
第一步：一张凭证地图，一行一个 key
把所有 agent 会用到的凭证列成表：名称、所属平台、能读什么、能写什么、能不能产生费用、有效期、最近一次轮换、泄露后在哪里吊销、负责人是谁。不要写「较高权限」「内部使用」这种模糊描述，要写到具体资源，比如「只读 orders 表的 3 个字段」「只能在测试网部署合约」「每月最多 50 美元」。
这张表最有用的一列是「能不能产生费用」。能下单、能调用按量计费的模型、能动云资源的 key，风险和只读 key 完全不是一个量级。把它们单独标出来，后面才好设上限。
第二步：把工具分成三层，不要共用一把 key
第一层是只读：查文档、读公开页面、拉报表。这层可以用范围最窄、可频繁轮换的 key，甚至只给一个只读副本。第二层是可逆写：建草稿、改测试数据、发内部消息。这层要有审计日志与回滚手段。第三层是不可逆写：付款、下单、删除、对外发送、改生产配置。这层必须单独发凭证，并且默认要人工确认。
三层共用一把 key，等于把第三层的风险摊到每一次只读任务上。拆开之后，大部分任务只需要第一层，出问题时影响面也小得多。
第三步：让「花钱」和「吊销」变成可执行的动作
给每个能产生费用的凭证设消费上限与告警阈值，阈值要低到能在一次异常任务里触发。再写清楚吊销步骤：去哪个后台、点哪个菜单、是否需要同时轮换下游应用、多久生效。很多团队直到出事才发现，删掉控制台里的 key 并不等于在供应商侧吊销，账单还会继续走。
如果供应商支持，给每个工具单独发 key，而不是全团队共用一把；再按项目或环境隔离，测试环境的 key 不应该能碰生产资源。
第四步：用一次红队跑一遍，不要只看评测分
上线前做一次针对权限的红队：让 agent 去完成一个正常任务，但在环境里放几个诱饵——一个暴露的只读凭证、一个能出网的代理、一个没有校验签名的测试接口。观察它会不会用任务之外的资源、会不会改配置、会不会把动作藏起来不报告。评测分再高，也不能替代这一次检查。
一个今天就能做的版本
先不用上复杂平台：把 agent 的 key 全部换成短期、最小权限的版本；把不可逆动作列成一张清单，逐个加人工确认；给能花钱的 key 设一个低阈值告警；最后把「吊销步骤」写进值班文档。四件事做完，再谈扩量。