一个模型指挥、一个模型找线索：多智能体攻击留下的是编排特征
一、值得防守方读的不是模型清单，是分工结构
据公开报道，一个名为 CyberCartel 的团伙用 Claude、Grok、Kimi 等多款模型搭了一套 AI 智能体系统，对拉丁美洲 400 多个金融目标发起自动化攻击，目标里包含银行与支付类应用。同一批报道还给出了这套系统的内部岗位：一款模型负责从公开渠道整理目标信息并把各处收集来的东西归到一处，若干模型负责讨论并给出推进方案，另有一个跑在编程工具里的模型充当协调者；配置中还留了后备——当某个模型拒绝执行某一步时，编排层把那一步改派给别的模型，整条流程不因单点护栏而停住。
模型名字本身对防守方没有操作价值。有价值的是”为什么要分工”这件事，它有三条理由，每一条都直接翻译成一个检测上的后果：
- 成本分层。 大批量的信息整理交给便宜模型，只在关键节点调用贵的。后果是单目标的攻击成本被压到”对长尾目标也值得跑一遍”的水位，过去只对高价值目标做的事现在对全部目标做。防守侧的推论是：低频慢速的探测不再是噪声，而是常态，任何”量小就不告警”的规则都会漏掉这一类。
- 上下文隔离。 每个子任务只喂它需要的那点信息。后果是单次请求的内容在结构上就不携带整体意图——不是模型太强以致看不出来，而是那一段本来就无害。靠审阅提示词或输出文本来判性质，这条路不是难，是选错了观测对象。
- 失败可替换。 任一环节加了护栏就换掉那一环，流程不动。后果是”某家模型已经做了限制”这类情报不构成缓解措施。真正构成缓解的是与模型无关的位置：认证强度、接口权限、调用序列异常检测。
还有一点容易被忽略：这套结构在工程上并不新。一个协调程序把若干可替换的执行体接成流水线，这就是工作流编排换了执行者。防守方一旦把它当成”AI 攻击”这个新物种，就会去找新的专用产品；把它当成”自动化脚本 + 会自己决定下一步”，问题立刻回到我们熟悉的地面上。
二、编排结构会留下的可观测痕迹
单点能力检测做不了，结构检测能做，原因是编排本身要花钱买确定性：一个自动跑的流程必须把每一步的输入输出对齐、必须重试、必须按固定模板组织任务，这些约束反过来就变成外在节律。下表是我们认为能落地的部分，”在哪一层能看到”按企业自己的系统写，不涉及任何外部数据源。
| 编排特征 | 在哪一层能看到 | 典型误报来源 | 我们建议的判定组合 |
|---|---|---|---|
| 调用节律过于规整，间隔方差极小，没有回读与停顿 | 接入层访问日志、网关的请求时序 | 定时任务、健康检查、批处理作业 | 与”是否带认证、是否命中写接口”组合 |
| 任务序列呈稳定的三段：摸清范围、判定价值、执行动作 | 同一主体访问接口的先后顺序 | 新同事的正常摸索、合作方接口联调 | 与”该主体是否首次出现、顺序是否符合业务真实依赖”组合 |
| 活跃时间窗与业务高峰无关，在低谷段反而密集 | 按主体聚合的时间分布 | 夜间跑批、跨时区的合作方 | 与”该主体历史上有没有该时段的行为记录”组合 |
| 来源是长会话而非零散请求，一个凭据长时间持续动作 | 认证与会话日志、令牌使用记录 | 长期值守的集成方服务账号、自动化测试 | 与”会话内动作是否跨越多个业务域”组合 |
| 多个账号共享同一套请求模板指纹：字段顺序、结构、失败重试方式一致 | 网关侧的请求体结构与序列化特征 | 同一厂商的多个客户端、官方开发包 | 与”这些账号的创建与凭证发放时间是否聚集”组合 |
| 同一动作在被拒绝后换一种来源再来一遍，参数几乎不变 | 上游调用的失败与重试序列 | 客户端容错重试、多活灾备切换 | 与”是否只在被拒之后出现、两次请求语义是否等价”组合 |
| 横向动作：一个主体可触达的资源集合快速增长 | 资源访问路径与权限审计日志 | 岗位调整、权限系统改造期 | 与”增长是否呈阶梯状、且找不到对应的人员变更”组合 |
这张表里最值得优先建设的是”任务序列”和”长会话”这两条，原因是它们与账号绑定，一旦命中就能直接处置（吊销凭据、限制接口范围），不依赖任何解释性判断。”节律过于规整”单独看意义不大，因为合法自动化同样规整；它的价值只在与其他特征叠加时出现。
三、内容检测为什么必须放弃
把”这是不是 AI 生成的”当成拦截点，有三个绕不过去的问题。第一，没有任何防守方看得见别人的模型内部状态，能拿到的只有已经格式化好的请求与响应；第二，用来判定的文本本身被上下文隔离切碎了，每次可见的那一段既短又无害；第三，这类判定天然不对称——改写一小段就能绕开，而误判的代价由业务承担，把大量正常的机器生成内容（导出文件、自动邮件、模板化文案）一起卷进去。
所以下一个明确的判断：把检测点从内容挪到行为与结构，具体是四件事——谁在调（账号与凭据）、以什么节律调（会话时长与时间窗）、调用的顺序是什么（接口序列）、能碰到哪些资源（访问路径与权限增量）。这四件事的第二个好处是不需要随攻击方的模型更换而调整：换一款模型不影响”一个服务账号开始按从未出现过的顺序访问三类接口”这个事实。
同时要说清它的适用边界，否则这套方法会被当成万能钥匙。它检出的对象是”异常编排的自动化访问”，不是”AI 攻击”——人工慢速操作命中不了，完全按合法集成方式走的滥用也命中不了。把”防 AI 攻击”写进目标的人会不断追问为什么没告警，把”防异常自动化”写进目标的人知道自己在看什么。
四、按这张表建检测会产出一堆告警：分级与误报代价
只要把上面几条规则开起来，第一批告警里大部分是合法自动化。处理这件事的关键不在调阈值，在分级维度选对。我们只用两条轴：这次动作是否触及认证接口或写操作，以及是否存在横向动作（资源集合在扩）。前者决定潜在损失，后者决定是不是”探索”。两轴交叉出四档，处置强度只给前两轴同时命中的那一档。
第二件事是把每一类误报的代价写在规则旁边，而不是只写严重级别：误伤一个集成方的服务账号，代价是合同层面的追责和一次现场救火；误伤一个员工的常规导出，代价是若干小时的支持工时和一次”你们的告警不准”的口碑损耗；漏掉一次真实的横向动作，代价是事后取证。这三行字必须让规则作者在上线前自己填，洹拓科技把它当作检测规则进评审表的前置条件——填不出来就不该有这条规则。
第三件事关于蓝队为什么会麻木。我们的观察是：麻木的成因不是告警条数多，而是同一类告警反复出现却没有一次能走到结论。所以每条检测规则上线前要回答两个问题——命中之后由谁处置、处置完以什么条件关闭。答不出的，一律降级成周报里的一个统计表，不进值班队列。把破坏性动作留在证据最足的那一层，顺序是先记录、再降权限流、再要求二次验证、最后才是阻断；反过来做，第一次误伤就会让整个检测体系在业务侧失去信誉。
五、真正划算的那件事：接口调用行为基线
上面所有判定都要落在同一个底座上——知道自己系统里”正常的调用长什么样”。要建的最小字段集是这些：
- 主体标识（账号、服务凭据、令牌 ID），不要用 IP 当主体。
- 认证方式与本次会话的标识和起始时间。
- 动作类型：读、写、删除、导出四类，导出要单独算，它是批量取数最省事的通道。
- 目标资源类别，粗粒度即可，别按 URL 打标签。
- 请求来源标识（客户端版本、开发包指纹），用于识别共享模板的那类特征。
- 结果码与失败原因，被拒之后的重试序列必须有失败标记才能关联起来。
- 调用序列在业务流程中的位置，这一项最贵，也最有用。
建法上有三条经验值得直接抄。按主体分别建模，不要用全局阈值：一个服务账号的正常节奏和一个前台坐席的节奏没有任何可比性，混在一起得到的阈值谁都不准。把已登记的自动化客户端放进显式白名单并强制归属人，白名单不是免检，是”这类异常不用告警，但要能查到是谁批的”。每个新接口上线时，在接口文档里同时写清预期的调用序列，这份文档就是基线的正样本来源——这件事是交付物的一部分，不是运维阶段的补救。
底座建好之后它同时服务三件事：异常访问检测、容量规划、事故回溯。这正是”不要为 AI 攻击单独建一套系统”这个判断成立的原因——单独建的那套系统只在一个偶发场景里有用，摊不掉成本。
六、这套方法在我们这类交付里成不成立
成立的条件很具体：你得有自己的 API 和自己的账号体系。SaaS 产品、支付与金融类系统、企业内部门户都满足，因为基线只能建在自己看得见调用序列的地方。反过来，如果业务主要跑在第三方平台分发的环境里，底层调用序列根本拿不到，这时候再怎么强调”编排特征检测”都是空的，能做的只有控制侧那两件旧事：收紧授权范围、把敏感动作拆成需要人工完成的一步。洹拓科技在方案评审里遇到这类需求会直接问一句”你们能不能拿到按主体聚合的接口调用日志”，拿不到就不承诺检测能力，只承诺控制与留痕。
第二个限制要说在前面：编排特征与合法自动化高度同形，误报无法归零，只能通过分级和代价声明来管理。把”检出率”当成这类系统的验收指标是错的，验收要看的是命中之后能不能在有限步骤内定位到主体并给出可复核的证据。
结论收敛成两句。为”AI 攻击”单独建一套系统，性价比不成立；把接口调用行为基线建起来，它顺带就把这类事接住了，代价低得多。而这件事的真正门槛不在算法，在于愿不愿意在接口文档里多写一栏”预期调用顺序”——大多数企业做不到，不是因为难，是因为从来没人把它当成需求的一部分。