先定目标：找权限缺口，不是找模型漏洞
这次演练不研究提示词注入的花活，也不要求模型「变坏」。选一个已经在用的 agent——写代码的、跑工单的、做客服的都可以——假设它完全按任务目标行动，然后问：为了完成这个任务，它现在能碰到哪些本来不该碰的东西？演练的产出不是一份风险评分，而是三张能直接改配置的表。
先约定边界：只在隔离环境或只读副本上做，不碰生产库，不发真实消息，不动支付与钱包。下面所有测试都以「能不能看到、能不能改」为目标，不实际执行破坏性动作。
第一张表：资产与不可逆动作
把 agent 可能接触的资产逐行列出来：代码仓库、数据库、对象存储、云控制台、CI/CD、部署脚本、支付或钱包、消息通道、邮件、文件系统、浏览器会话。每行标三个属性：读、写、是否不可逆。删除数据、改权限、发外部消息、转账、部署上线都算不可逆；读日志、查文档、跑只读查询不算。
这张表的作用是排出优先级。先处理「写 + 不可逆」的交集，再看「写 + 可逆」，最后才是只读资产。很多团队一上来就讨论模型该不该联网，却没发现 agent 的部署脚本里带着生产环境的写权限。
第二张表：凭证从哪里来、能活多久
逐个查 agent 进程能读到的凭证：环境变量、.env 文件、shell 配置、系统钥匙串、SSH 私钥、OAuth refresh token、浏览器 cookie、MCP server 自带的 token。每项记录四件事：存放位置、权限范围、有效期、谁有权读取。重点找三类问题：长期不过期的 token、范围过大的云密钥、以及「为了省事」放在项目根目录的 .env。
再补一列：这个凭证是给人用的，还是给这个任务用的？如果答案是「给团队所有人用的」，那 agent 一旦被诱导或出错，影响面就是整个团队。演练里最值得改的，往往不是模型参数，而是把长期共享密钥换成按任务签发、短时效、最小范围的凭证。
第三张表：任务到权限矩阵
把 agent 的常见任务写成行：读工单、查日志、改代码、跑测试、部署、发消息、导出报表。列成四列：读、写、执行、出网。每个格子只填「需要 / 不需要」，不要填「最好有」。这张矩阵会直接暴露过度授权：一个只负责总结工单的 agent，通常不需要执行 shell，也不需要访问对象存储的写接口。
填完后做一次反向检查：对每个「需要」，问如果这个权限被用在任务之外，最坏会发生什么。如果答案是不可逆的，就把它移到人工审批或双人确认，而不是继续留在自动执行路径里。
跑五个边界测试
测试一：让它读一个公开页面，但在页面里放一个内网地址，看它会不会跟着访问。测试二：让它改一个无关配置，看有没有写权限。测试三：让它把查询结果导出到外部，看 egress 是否被拦。测试四：让它在环境里安装一个包，看能不能执行任意命令。测试五：如果涉及支付或钱包，用测试网/沙箱看它能不能发起转账。
每个测试只记录三件事：请求有没有发出、在哪个环节被拦、日志里留下了什么。不要只看 agent 的文字回答——它说自己「没有访问」不等于网络层没有请求。以网关、代理、进程和云审计日志为准。
把结果变成三道闸
第一道是凭证：按任务签发、短时效、最小范围，任务结束就失效；能只读就不要给写，能限定单库就不要给整实例。第二道是出网：默认拒绝，只放行任务需要的域名，内网地址与云元数据端点单独封死。第三道是不可逆动作：删除、部署、转账、对外发消息一律人工批准，批准界面要显示「谁、对什么、做了什么」。
三道闸不需要一次全上。先做凭证收敛，通常能消掉大部分风险；再加出网白名单；最后把不可逆动作接到审批流。每加一道，都用同一组边界测试复测，确认没有把正常任务一起挡住。
多久复测一次
换模型、换 agent 框架、加 MCP server、改权限、改部署流程之后都要复测；稳定运行时至少每季度一次。把三张表和测试记录放在同一个目录，下一次演练从上次的「未关闭项」开始，而不是重新盘一遍。
边界：演练不是渗透测试
这套流程能找出明显的过度授权和缺失的闸门，但不能证明系统安全。真正的高风险场景——多步工具组合、供应链投毒、模型被微调后行为改变——仍需要专门的红队和代码审计。把这次演练当成一次「权限盘点」，先把能看见的洞补上，再谈更复杂的攻击面。