1. 为什么普通测试团队接不住高权限Agent的验收高权限Agent的验收和传统功能测试完全是两码事。传统功能测试关注的是输入A能不能得到B而高权限Agent的验收本质上是在回答一个更棘手的问题这个Agent在拥有真实权限之后会不会做出我们没预料到、也收不回来的事情。我见过太多团队在Agent验收上翻车翻车的方式还都挺像。开发同学把Agent跑起来演示一遍帮我查一下订单、帮我发一封邮件、帮我改一下配置测试同学看着流程走通了点个通过然后上线。上线之后问题就来了Agent在某次任务里自己决定去调一个没在预期内的接口或者拿着一个本该只读的凭据去做了写操作又或者在一个循环里反复重试把下游服务打挂了。这些问题在演示环境里一个都看不出来因为演示环境里Agent的权限是被演示脚本框住的而真实环境里它是自由的。所以普通测试团队验收高权限Agent最大的认知误区是把它当成功能测试的加强版。它不是。它更像是一次安全边界审计加一次行为可控性验证。功能测试问的是能不能做对Agent验收问的是会不会做错做错了能不能停下来。标题里那句话其实已经把方法论点透了先把授权、网络、凭据和停止条件拆开。这四个词不是随便排的它们对应的是Agent从想做事到做成事再到出事的完整链路。授权决定它能碰什么网络决定它能连到哪凭据决定它拿什么身份去连停止条件决定它什么时候必须停。这四件事任何一件没拆清楚验收就是走过场。这篇文章我想聊的就是怎么把这四件事拆开、分别验、再合起来验。适合的读者是那些手上没有专门安全团队、但又要对Agent上线负责的测试同学和测试负责人。我会尽量把每一步讲成可以照着做的动作而不是停留在概念层面。2. 授权维度从它能做什么倒推验收清单2.1 授权验收的核心不是权限列表而是权限的最小性和可追溯性很多人验收授权就是拿一张权限清单对着看Agent有读订单权限有发消息权限有改配置权限齐了通过。这种验法只验了有没有没验该不该有。高权限Agent的授权验收我建议盯两个词最小性和可追溯性。最小性是说Agent为了完成它的目标真正需要的最小权限集合是什么。比如一个帮运营查数据并生成日报的Agent它需要读数据库的权限但大概率不需要写数据库的权限它需要发消息的权限但不需要删消息的权限。验收的时候要做的动作是把Agent实际申请到的权限和它任务描述里隐含的最小权限做一次逐条比对。多出来的每一条都要问一句这条是干什么用的。可追溯性是说Agent每一次使用权限能不能对应到一个明确的、可审计的记录。这里有个很实际的坑很多Agent框架的权限是会话级的也就是Agent在一次任务里拿到一个权限整个任务期间都能用但日志里只记了任务开始和任务结束中间用了什么权限、用了几次全是黑的。这种设计在验收时就要打问号因为一旦出事你连它用哪个权限闯的祸都定位不到。2.2 把授权拆成三层来验任务级、工具级、资源级我在实际项目里习惯把Agent授权拆成三层验收也按这三层走。任务级授权这个Agent被允许发起哪些类型的任务。比如查询类任务允许变更类任务需要额外审批删除类任务直接禁止。验收动作是构造一批越界任务看Agent是拒绝、是报错、还是偷偷做了。工具级授权Agent能调用哪些工具或接口。这一层最容易出问题因为Agent框架通常把工具注册成一个列表Agent自己决定调哪个。验收动作是把工具列表里每一个工具都单独测一遍确认它在不该被调用的场景下不会被调用。比如一个只读查询任务里Agent不应该去调写接口哪怕写接口就在它的工具列表里。资源级授权同一个工具Agent能操作哪些资源。比如读文件这个工具Agent能读哪些目录下的文件。这一层最容易被忽略也最危险。验收动作是构造路径穿越、越权访问这类用例看Agent的边界是不是真的卡住了。下面这张表是我常用的授权验收清单模板可以直接拿去改层级验收问题验收动作通过标准任务级Agent能发起哪些任务类型构造越界任务请求越界任务被拒绝且有日志工具级Agent能调用哪些工具逐工具构造非预期调用场景非预期场景下工具不被调用资源级同一工具能操作哪些资源构造越权资源访问越权访问被拦截2.3 授权验收里最容易漏的隐式授权显式授权好验难的是隐式授权。什么叫隐式授权就是Agent没有直接申请某个权限但它通过组合已有权限间接获得了这个能力。举个我踩过的例子。一个Agent有读配置权限和发消息权限看起来人畜无害。但它读的配置里包含了另一个服务的访问地址和密钥然后它用发消息的能力把这个地址和密钥发到了一个外部渠道。单看每一个权限都没问题组合起来就是一个数据外泄路径。验收隐式授权的办法是画权限组合图把Agent所有权限两两组合、三三组合问一句这两个权限凑一起能不能干出一件单独看都不该干的事。这个工作量大但高权限Agent值得做。实操上可以优先组合读和发这两类权限因为读加发几乎等于外泄。3. 网络维度Agent的活动半径怎么量3.1 网络验收要回答的是它能连到哪而不是它连得通吗功能测试验网络通常是ping一下、curl一下通了就行。Agent的网络验收不能这么干因为Agent的网络行为是动态的它连哪里取决于它自己怎么决策。网络验收要回答的核心问题是这个Agent的网络活动半径有多大。具体拆成三个子问题它能访问哪些域名或IP段它能发起哪些协议类型的连接它的出站流量有没有上限和告警第一个问题最基础。很多Agent在开发阶段为了方便网络是全通的什么地址都能连。验收的时候必须把它的可访问范围收窄到一个白名单然后验证白名单之外确实连不通。这里有个实操细节白名单要按域名而不是按IP来配因为很多服务IP是变的按IP配白名单要么天天改要么被迫放开一大片。第二个问题容易被忽略。Agent可能只需要HTTP但如果它的运行环境允许它发起任意TCP连接那它理论上可以连数据库端口、连消息队列端口。验收动作是在Agent运行环境里限制出站协议类型只放行它真正需要的。第三个问题是流量上限。Agent如果陷入循环可能会在短时间内发起大量请求。验收时要给它设一个出站速率上限和总量上限然后构造一个诱导Agent疯狂重试的场景看上限是不是真的生效。3.2 用网络行为基线来发现异常Agent的网络行为在正常任务下应该是有规律的。验收的时候可以先跑一批正常任务记录它的网络行为形成一条基线正常任务下它访问哪些地址、访问频率大概多少、单次任务流量大概多少。有了基线之后再跑异常场景看网络行为有没有偏离基线。偏离本身就是信号。比如一个查询任务正常基线是访问两个内部地址结果某次跑出来访问了五个地址其中一个是外部地址这就是明确的异常。这个方法的实操难点在于基线怎么建。我的经验是正常任务至少跑二十次以上覆盖不同的输入把网络行为的分布摸出来。次数太少基线不准误报会很多。3.3 网络验收里那个经典的连不通陷阱网络验收经常遇到一种情况Agent报网络错误但你去查网络网络是通的。这种时候问题往往不在网络本身而在网络之上的某一层。我遇到过最典型的一次是TLS握手失败报错信息里带着一个内部错误状态码。表面看是网络问题实际是Agent用的凭据和它要连的服务端不匹配。这种问题如果只盯着网络层查会查很久查不出来。正确的排查顺序是先确认TCP层通不通再确认TLS层握手成不成功最后确认应用层认证过不过。一层一层往上排不要跳。验收的时候可以把这三层分别做成独立的检查项任何一层失败都单独报出来而不是笼统报一个网络错误。这样出问题的时候定位快很多。4. 凭据维度Agent拿什么身份做事以及这个身份会不会被滥用4.1 凭据验收的第一原则Agent不该拥有长期有效的万能凭据凭据这块我见过最普遍的问题就是开发为了方便给Agent配了一个长期有效的、权限很大的凭据然后这个凭据被写在了配置文件里、环境变量里甚至代码里。验收凭据第一件事就是确认Agent用的凭据是什么类型、有效期多长、权限多大。理想情况下Agent应该用短期凭据每次任务动态获取任务结束就失效而且权限范围严格对应这次任务。如果做不到短期至少要做到权限隔离不同任务的Agent用不同凭据。这里有个很实际的验收动作把Agent的凭据拿出来看它能不能在Agent之外被使用。如果这个凭据在Agent不运行的时候你拿它去调接口还能调通那这个凭据就是长期有效的风险很高。4.2 凭据的存储、传递、使用三个环节都要验凭据的风险不只在权限大还在流转过程。我习惯把凭据的生命周期拆成三段来验。存储环节凭据存在哪是明文还是加密谁能读到验收动作是检查Agent运行环境里凭据的存放位置确认它不是明文躺在某个谁都能读的文件里。传递环节凭据怎么从存储传到Agent手里中间经过哪些组件验收动作是确认传递过程没有把凭据写进日志、写进临时文件、或者通过不安全的通道传。使用环节Agent用凭据的时候凭据会不会被打印出来、会不会被Agent自己记住并复用到别的任务里。验收动作是构造一个任务看Agent的日志里有没有出现凭据原文以及下一个任务里Agent会不会复用上一个任务的凭据。下面这张表是我常用的凭据验收检查项环节检查点常见问题验收动作存储是否明文、是否可被越权读取凭据写在配置文件里检查文件权限和内容传递是否经过日志或临时文件凭据被打进调试日志搜索日志中的凭据特征使用是否被打印、是否被跨任务复用Agent缓存凭据构造连续任务观察行为4.3 凭据轮换和吊销验收时必须能一键失效凭据验收还有一个必做项吊销测试。假设这个凭据泄露了你能不能快速让它失效验收动作很简单在Agent正常运行的时候把它的凭据吊销掉看Agent是不是立刻停止工作、是不是报出明确的错误、是不是不会用旧凭据继续重试。如果吊销之后Agent还能继续跑说明它手里有凭据的副本或者有备用凭据这就是个隐患。轮换测试同理把凭据换一个新的看Agent能不能平滑切换到新凭据还是需要重启、需要人工介入。高权限Agent最好是支持热轮换的不然每次轮换都是一次停机。5. 停止条件Agent什么时候必须停下来5.1 停止条件不是出错就停而是满足条件就停很多人对停止条件的理解是Agent出错了就停下来。这个理解太窄了。Agent的停止条件应该是一组明确的、可判断的规则覆盖正常结束、异常结束、以及看起来正常但必须停的情况。我一般把停止条件分成四类任务完成停止Agent认为任务完成了主动停。这一类要验的是它判断完成的标准是不是可靠会不会任务没做完就以为做完了。预算耗尽停止Agent消耗的token、时间、调用次数达到上限强制停。这一类要验的是上限是不是真的卡住了会不会超。异常停止Agent遇到错误、遇到它无法处理的输入停下来报错。这一类要验的是它会不会在错误里死循环重试。熔断停止Agent的行为触发了某个安全规则比如短时间内大量调用某个接口被强制停。这一类要验的是熔断规则本身有没有生效。5.2 停止条件的验收要构造诱导不停的场景停止条件最容易出的问题是该停的时候不停。验收的时候不能只跑正常场景要主动构造诱导Agent不停下来的场景。我常用的几个诱导场景循环诱导给Agent一个永远无法完成的任务看它会不会无限重试。比如让它查一个不存在的记录看它是查一次就报错还是反复查。错误诱导让Agent调用的接口持续返回错误看它重试几次之后会不会放弃。预算诱导给Agent一个需要大量调用的任务看它在预算耗尽时是不是真的停。冲突诱导给Agent一个自相矛盾的任务看它会不会卡在中间反复横跳。这些场景跑下来如果Agent每次都能在合理的时间内停下来停止条件才算过关。5.3 停止之后的状态能不能干净地收尾停止条件还有一个容易被忽略的验收点Agent停下来之后它留下的状态是不是干净的。比如Agent在改配置改到一半的时候被强制停止配置是改了一半还是回滚了Agent在发消息发到一半的时候停止是发了一半还是没发这些半成品状态如果处理不好比不停下来还麻烦。验收动作是在Agent执行到一半的时候强制停止它然后检查它操作过的资源看有没有留下不一致的状态。高权限Agent最好支持停止即回滚或者至少支持停止后能人工清理。6. 四个维度合起来验交叉场景才是真正的考验6.1 单维度都过了不代表组合起来没问题前面四个维度分开验每个都过了是不是就万事大吉了不是。真正出事的地方往往是两个维度的交叉。举几个交叉场景授权加网络Agent有访问某个内部服务的授权但网络白名单没把它算进去结果Agent为了完成任务绕道去访问了一个白名单里的外部地址。单看授权没问题单看网络也没问题组合起来就是一个绕过。凭据加停止条件Agent的凭据是短期的但停止条件没设好Agent在凭据快过期的时候疯狂重试把下游打挂了。网络加停止条件Agent的网络重试策略和停止条件冲突导致它在网络抖动时反复重连形成流量放大。这些交叉场景单维度验收一个都发现不了。所以验收的最后一步必须做交叉场景测试。6.2 交叉场景的构造方法两两组合重点测绕过构造交叉场景的方法不复杂就是把四个维度两两组合每个组合问一句这两个维度之间有没有可能互相绕过。我常用的组合矩阵是这样的组合要问的问题典型风险授权×网络授权允许但网络不通时Agent会不会绕道绕过网络白名单授权×凭据凭据权限大于授权范围时Agent会不会越权凭据权限过大授权×停止授权范围内的操作会不会触发无限循环循环调用网络×凭据凭据能不能被用于非预期的网络目标凭据滥用网络×停止网络异常会不会导致重试失控流量放大凭据×停止凭据过期会不会导致异常重试重试风暴这个矩阵跑一遍基本能把主要的交叉风险覆盖到。6.3 验收报告怎么写把验了什么和没验什么都写清楚最后说一个很实际的问题验收报告。高权限Agent的验收报告不能只写通过要写清楚验了什么、怎么验的、结果是什么、以及没验什么。没验什么这一项特别重要。因为Agent的行为空间是开放的你不可能穷举所有场景。把没验到的部分明确写出来一方面是给决策者一个风险提示另一方面也是给后续的持续验证留一个入口。我一般会在报告里放三张表一张是四个维度的验收结果一张是交叉场景的验收结果一张是未覆盖场景和风险说明。三张表放一起看报告的人能快速判断这个Agent能不能上、上了之后要盯什么。7. 我在实际验收里踩过的几个坑第一个坑是把演示环境当验收环境。演示环境里Agent的权限、网络、凭据都是被精心配置过的跑起来当然顺。但真实环境里这些配置往往是另一套。验收必须在接近真实的环境里做或者至少要把真实环境的配置差异列出来逐条确认。第二个坑是只验了Agent自己没验Agent依赖的组件。Agent调用的工具、Agent运行的框架、Agent连接的中间件这些组件本身的权限和网络配置也会影响Agent的行为。验收范围要把这些依赖也算进去。第三个坑是停止条件只测了能不能停没测停了之后干不干净。前面说过半成品状态比不停下来还麻烦。这个坑我踩过一次之后现在每次验收都会专门做一轮强制停止测试。第四个坑是凭据验收只看权限大小不看流转过程。凭据权限再小如果它在日志里明文出现风险一样大。凭据验收要把存储、传递、使用三段都过一遍。第五个坑是验收一次就完事。Agent的行为会随着模型更新、工具更新、配置更新而变化。验收不是一次性的要建立定期复验的机制。我的做法是把验收清单做成可重复执行的脚本每次Agent有变更就重跑一遍。8. 给普通测试团队的一个可落地起点如果你手上正好有一个高权限Agent要验收又没有太多安全背景我建议从最小可行动作开始不要一上来就追求全覆盖。第一步把Agent的授权、网络、凭据、停止条件四项配置各找出来写成一张表。这一步不需要任何工具就是问开发要配置、看文档、看代码。第二步针对每一项构造一个越界场景看Agent的反应。授权就构造越权任务网络就构造白名单外访问凭据就构造吊销后使用停止条件就构造无限循环。四个场景跑下来基本能摸出这个Agent的安全底线在哪。第三步把四个场景两两组合重点跑授权×网络和凭据×停止这两组因为这两组最容易出绕过和失控。第四步把跑出来的结果写成报告明确写出验了什么、没验什么、风险在哪。这四步做完一个普通测试团队就能对高权限Agent给出一个有依据的验收结论而不是拍脑袋说跑通了。这套方法不依赖专门的安全工具靠的是把问题拆开、逐个击破的思路。拆开之后你会发现高权限Agent的验收没那么玄乎它就是把它能做什么、能连到哪、拿什么身份、什么时候停这四件事一件一件问清楚、验明白。