安全测试 Agent 如何先确认操作授权

一个拿着登录 Cookie、能操作真实浏览器的 AI 安全测试 Agent，首先要回答的不是能找到多少漏洞，而是谁允许它测试这个网站。原文作者围绕 SecTestAi 的设计提出：授权必须成为每次任务执行时的系统约束，不能只写在服务条款里。

这篇值得读的地方，是把授权拆成了声明、人工确认、运行时检查、撤销和审计几个环节。不过，作者展示的是早期产品的设计经验，没有提供效果对照或完整实现，哪些机制已经足够可靠，还需要分别判断。

Agent 能操作到哪，授权就要管到哪

先看这个 Agent 在做什么，才能理解作者为什么强调授权。

它驱动真实浏览器，执行点击、填写表单、维持会话等操作，沿着用户实际使用产品的路径测试，而不是仅仅重放一组静态请求。它关注角色、业务状态和操作意图，试图发现对象级授权失效、返回字段未脱敏、审批步骤被跳过或调换顺序，以及并发操作造成的状态竞争。

这些问题都贴着业务边界。比如，一个用户能否访问另一个用户的对象，不能只看页面上有没有入口，还要看服务端是否真正限制了访问。

与此同时，Agent 持有会话 Cookie，还会改变应用状态。一旦测试目标未经许可，风险就已经发生，是否找到漏洞反而成了后话。

作者将产品定位为 Web & API 评估与风险分析工具，并非源码审计工具。他们还会报告哪些事情无法确认。这一点很实用：测试没有验证成功，与已经证明安全，是两个不同的结论。

授权不能由执行任务的 Agent 自己生成

作者团队的第一道限制，是要求操作者在每次评估前声明目标及其与目标的关系，只接受两种值：

• owned：这是操作者自己的应用。
• entrusted：客户或雇主委托操作者测试。

系统没有「其他」选项，也没有自由填写理由的入口。不符合这两类关系，就无法继续创建相应的测试流程。

这里的作用是收紧产品允许承接的任务类型。它并不能证明声明真实，但可以避免任意一段解释都被系统当成有效授权。

声明还必须绑定具体工单和一组具体目标，不能用一次点击确认覆盖此后所有测试。否则，用户曾经同意过什么，与 Agent 此刻正在测试什么，很容易脱节。

接下来，由另一名真人在门户中确认，Agent 才能运行。确认会留下独立记录，包括确认人、时间和来源；作者明确表示，Agent 没有生成这份确认记录的代码路径。

执行任务的 Agent，不能同时拥有批准自己行动的能力。

对做 AI 编程工具的人来说，这与让模型在提示词里自觉判断「我有没有权限」有明显区别。前者依赖系统能强制执行的边界，后者仍然把决定权留给了模型。

为什么批准一次，不能一直有效

作者把授权视为有生命周期的状态。

工单创建和任务启动之间，目标解析结果可能变化，执行位置也可能变化。因此，他们在运行实际开始时检查目标解析，而不是只在建单时检查。已确认的工单也可以撤销，撤销后，同一次运行便不再获得授权。

不过，原文没有交代位置的具体定义、检查规则、运行期间的复查频率，以及撤销后多久停止后续操作。可以认可这套原则，但还不能据此判断它对长任务的控制精度。

审计则采用哈希链日志：每条授权事件关联上一条记录，之后可以重新计算整条链，检查记录是否被改动。相比只能阅读的普通日志，它增加了校验记录一致性的能力。

另外还有两条容易被忽略的约束。每个账户独立运行自己的评估和目标，不共享其他客户的测试范围，也不转售别人的授权范围；如果目标方发现未经许可的测试，产品需要提供能联系到真人的投诉渠道，并明确响应时限。原文没有给出具体时限。

这些安排共同服务于三个问题：谁批准了行动，批准能否在执行中失效，事后能否由独立的人核验。

我的判断

我认同作者把授权放进执行链路的方向。对于会持有凭证、修改数据的 Agent，独立确认、目标绑定和可撤销状态，比单靠服务条款或提示词更容易形成可检查的约束。

但几个边界需要保留。

首先，owned 和 entrusted 都是声明，另一名真人确认也不自动等于真实委托。原文没有说明如何验证目标所有权、委托凭据，以及确认人是否有权批准。流程分工是必要条件，真实性验证仍然没有讲清楚。

其次，哈希链能够帮助检测记录变更，但如果有人能改写全部日志并重新计算整条链，仅凭链内部一致性未必足以发现。是否存在独立保存的校验值或其他保护措施，作者没有说明。因此，「任何拥有数据库访问权限的人改过记录都能被发现」不能直接照单全收。

对于固定目标、只读且短时的自动化任务，静态白名单和人工审批可能已经能覆盖不少需求；当任务持有登录态、持续运行并修改状态时，动态撤销的价值就更高。机制应当跟随实际操作能力增加。

SecTestAi 仍处于早期，采用预付费、无订阅的方式。作者没有提供误用拦截率、撤销延迟或与其他方案的对照数据。这是一份值得借鉴的设计说明，还不是经过数据证明的成熟方案。

能拿来做什么

• 如果你在做操作浏览器的 Agent，可以让每次任务绑定明确目标、操作者和授权记录，并由执行服务检查这些条件，避免仅靠模型阅读一段授权说明。
• 如果你的 Node 服务负责调度长时间任务，可以把授权设计成可撤销状态，在任务启动和后续关键操作前检查；具体检查位置和停止时效，需要按任务能力明确下来。
• 如果你用 AI 检查前端业务流程，可以围绕角色权限、字段脱敏、审批顺序和并发状态组织测试，并要求报告区分「已经验证的问题」与「尚未确认的风险」。
• 如果准备将这类工具提供给客户，可以提前明确确认人、撤销入口、审计记录和投诉响应流程，让一次测试的授权范围能够被追溯。