文章总结： 该报告分析AIAgent安全威胁与攻击能力演进，提出能力借用概念，即攻击者利用Agent已有资源推进攻击。攻击面涵盖状态化后门、Skill供应链投毒及运行时供应链，通过跨Session持久化、恶意Skill分发等方式实现持续影响。建议防御方关注Agent状态管理、Skill来源可信度及运行时依赖关系，将后门检测边界扩展至信息环境与能力环境。
综合评分： 85
文章分类： AI安全,红队,安全研究,威胁情报
AI Agent安全威胁与攻击能力演进研究—— 攻击能力扩张的新路径
启明星辰
启明星辰
ADLab
2026年9月30日 17:54
北京
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
更多安全资讯和分析文章请关注启明星辰ADLab微信公众号及官方网站（adlab.venustech.com.cn）
第一章
概 述
近年来，AI大模型和Agent在持续快速迭代进化下，从最初的信息生成和问答工具逐渐发展为具备开发、部署、运营维护等全流程自动化实现的能力，并且其强大的规划能力、深度的知识复用能力、精确的工具调用能力结合大模型高效的决策能力，在诸多领域已经超越了经验丰富的专家。因此，AI Agent迅速地被落地应用在了各行各业之中。但与此同时，Agent的触手也逐渐伸向了系统最核心的权限，甚至是底层硬件，未来还可能对接具身智能，直接影响甚至主导物理世界的活动。然而，这一切快速的发展，伴随着的是人们对安全的担忧，如果这些广泛部署的AI Agent受到黑客或者是另外一些AI的恶意攻击，那所造成的危害将是难以想象的。
而现实是，黑产团伙和专业黑客组织已经大规模使用Agent执行攻击任务，攻击自动化程度持续提高。单次入侵的边际成本已降至数十美元量级，攻击节奏从人工操作的天级压缩至机器执行的分钟级甚至秒级。越来越多攻击活动实现了从初始侦察到目标控制的持续自主执行，攻击者只需设定目标，后续判断和操作均由Agent连续完成。更值得警惕的是，Agent能够持续运行、根据执行结果调整行为，并在完成任务后清理痕迹。这意味着部分攻击可能在未被察觉的情况下已经完成了渗透和驻留。攻防双方都在加速引入AI能力，但攻击方在使用AI时受合规、审计等约束更少，其自动化推进速度可能对防御方响应能力构成更大压力。
传统模型安全分析主要围绕模型输入输出和接口边界展开。现有Agent安全研究已经延伸到状态管理、工作流传递和运行时依赖等环节，但多聚焦于某一类具体攻击技术，较少从“攻击者从Agent运行环境中获得了什么能力”这一整体视角进行分析。Agent连接了模型与多种外部运行资源，攻击影响可以在后续任务中持续存在，攻击能力可以在不同工具和Agent之间传递和组合。这些变化要求我们从新的视角重新审视攻击面的边界和攻击能力的形成方式。
通过跨案例的横向分析，我们将攻击者利用Agent已有资源和执行能力推进后续攻击的现象概括为“能力借用”。传统攻击中，工具、漏洞利用代码和执行环境需要攻击者自行准备；而在Agent参与的攻击中，攻击者可以直接利用Agent已经连接的资源，将Agent已有能力转化为后续攻击操作。这一变化的关键在于，攻击者获取和调用攻击能力的方式发生了改变。
从公开案例看，能力借用在不同攻击活动中呈现出不同的组织方式。JADEPUFFER体现的是单Agent内的状态延续；GTG-1002体现的是同一Agent跨工具的能力串联；多Agent攻击框架体现的是跨Agent的任务拆分与结果共享。我们将这三种方式归纳为三种粒度，它们逐层递进，但共享同一底层逻辑：已经借用的能力能够继续成为后续攻击步骤的输入，不同任务之间形成能力传递、调用和组合。这一从“借用已有能力”到“持续传递和组合能力”的路径，正是本报告所讨论的“攻击能力扩张的新路径”。
后续章节将从攻击面、自主攻击能力、真实案例、防护措施和未来影响等方面展开分析，并重点讨论任务状态、外部知识、第三方能力、工具权限和运行时执行等环节，这些环节既是攻击者实施“能力借用”的具体对象，也是防御者设计检测点和干预点的关键入口。
第二章
AI Agent攻击面的演进
随着Agent逐步进入实际业务环境，攻击方面临的安全边界也随之发生变化。Agent不再只是接收输入并生成结果的模型，而是在持续任务过程中处理外部信息、保存任务状态、调用工具和Skill，并根据前序执行结果决定后续操作。攻击方能够影响和利用的对象，也由单次输入进一步延伸到Agent运行过程中形成的状态、依赖和能力关系。
这种变化主要体现在三个方面。首先，攻击影响的存续方式发生变化。攻击影响可以突破单次任务边界，在后续任务或不同Session中继续存在，不再随当前交互结束而消失。其次，攻击方对Agent能力的利用方式发生变化。攻击方不一定需要直接获得目标资源或权限，而可以通过影响Agent对数据、任务和操作对象的判断，借助Agent已有的计算资源、数据访问能力和业务权限完成攻击。最后，原本可以独立进行安全检查的能力，在进入同一任务流程后可能通过输入输出、信任关系和执行结果相互连接，形成单个能力自身不存在的复合攻击路径。
已有攻击技术进入Agent运行环境后，攻击方能够施加影响的位置、能力利用方式以及攻击路径形成条件发生了怎样的变化，是本章我们分析的重点。
2.1 持续影响：从状态持久化到供应链传播
Agent在执行任务时会持续产生上下文、保存任务状态，并依赖外部知识、Skill 及运行时资源完成后续操作。与一次性输入不同，这些信息和依赖关系可能在当前任务结束后继续存在，并在后续任务、会话或其他Agent的执行过程中被再次使用，使攻击影响不必局限于单次交互。
这一变化并非产生了一种全新的持久化攻击技术，而是使已有的持久化控制、供应链投毒和运行时依赖传播等技术获得了不同的作用条件。攻击方可以影响Agent依赖的外部知识，使恶意内容进入后续任务；也可以利用持久化状态保存攻击进度，使影响跨越不同Session；当Agent进一步依赖动态获取的数据、Skill和其他Agent产生的信息时，恶意内容还可能沿运行时依赖继续传播。下面分别从状态化后门、Skill供应链投毒和运行时供应链三个方面进行分析。
2.1.1 状态化后门
状态化后门的演进并不是后门触发机制本身发生了根本变化，而是攻击影响能够依赖的Agent状态范围逐步扩大。早期研究主要通过投毒外部知识，使恶意信息在后续任务中持续发挥作用；随后研究开始利用Planning、Memory和Tool-use之间的状态传递，使攻击影响进入Agent内部工作流；进一步的研究则将状态保存扩展到跨Session场景，使攻击进度能够在不同任务会话之间恢复和延续。
早期研究主要关注如何利用Agent持续依赖的外部知识环境。AgentPoison针对Agent的Memory和RAG知识库设计投毒方法，将恶意信息植入Agent能够正常访问的外部知识，并通过触发条件使其在后续检索过程中进入任务上下文。此时，研究人员无需改变Agent本身，而是通过控制其持续读取的信息源，就可能使恶意内容参与后续任务决策。
图2-1 AgentPoison攻击路径示意图
这一机制的关键在于，外部知识从静态数据转变为能够影响Agent运行状态的输入来源。一旦恶意信息被检索并进入Task Context，其作用范围可能超出知识库本身，并沿Agent后续的任务执行过程继续传递。这也说明，这一影响环节可以进入Agent运行所依赖的信息环境。
随后，研究重点从外部知识投毒进一步转向Agent内部工作流中的状态传递。BackdoorAgent将Agent任务拆分为Planning、Memory和Tool-use等环节，在后门触发后观察恶意信息能否通过这些环节形成的中间状态继续向后传播。实验覆盖Agent QA、Agent Code、Agent Web和Agent Drive等任务，并进一步测试了语言和多模态场景。
图2-2 Agent工作流中的后门状态传播
与单纯影响一次模型响应相比，这类方法利用的是Agent工作流中的状态传递关系：后门触发产生的信息可以进入Memory或其他中间环节，并成为后续Planning和Tool-use阶段能够再次读取的内容。实验结果显示，后门影响能够在多个工作阶段保持较高比例。这说明，当Agent任务由多个相互关联的执行环节组成时，中间状态本身可以成为恶意影响持续存在的载体。
在此基础上，研究进一步将攻击状态从单次任务内的工作流传播扩展到跨Session持久化。Stateful Agent Backdoor针对这一条件，将攻击过程建模为可持续保存和转换的状态机。一次Session完成初始化后，攻击进度写入持久化组件；后续Session重新读取该状态，再从此前停止的位置继续执行。研究中，攻击状态被建模为按照 INIT → COLLECT → EXFIL → DONE 逐步转换，使原本需要连续完成的攻击过程被拆分到多个Session中。
图2-3 Stateful Agent Backdoor跨Session状态传播与攻击状态机
该研究进一步使用Mealy Machine描述攻击状态与环境条件之间的关系，使下一步攻击行为同时受到当前状态以及可用工具、环境条件等输入影响。在此基础上，研究人员通过Backdoor Decomposition将复杂攻击拆分为多个相互关联的子后门，再利用持久化状态重新连接不同阶段，并测试了Branch-and-Merge等非线性状态拓扑。实验结果显示，该方法在多个模型和任务中取得约80%—95%的攻击成功率。需要注意的是，这些实验建立在特定Agent架构、持久化组件和状态读写条件之上。尤其是跨Session攻击，需要存在攻击方能够影响的共享状态通道，并要求不同阶段的子后门能够正确触发和衔接。因此，实验中的高攻击成功率不能直接等同于现实Agent环境中的实际攻击成功率。
| | | | |
| — | — | — | — |
| 研究 | 主要作用位置 | 核心机制 | 攻击影响范围 |
| AgentPoison | Memory/RAG知识库 | 外部知识投毒与条件触发 | 恶意信息进入后续任务上下文 |
| BackdoorAgent | Planning/Memory/Tool-use | 中间状态在工作流环节间传递 | 恶意影响沿多步骤任务继续传播 |
| Stateful Agent Backdoor | 持久化状态组件 | 状态保存、读取与跨Session转换 | 攻击进度跨Session恢复并继续执行 |
从早期外部知识投毒，到工作流内部状态传播，再到跨Session持久化，相关研究所利用的状态范围逐步扩大，攻击影响的持续时间也从单次任务延伸至多个任务会话。Agent状态管理机制为攻击影响提供了越来越多的持续载体。
对防守方而言，后门检测边界也需要随之变化。除了检查输入内容和模型行为，还需要关注哪些外部信息能够进入Agent状态、哪些中间状态能够被后续任务重新读取，以及不同Session之间是否存在可被利用的共享状态通道。对于具备Memory、RAG和长期任务状态的Agent，这些持续性数据流和状态读写关系应当纳入后门风险分析范围。
状态化后门说明攻击影响可以在Agent的信息环境和任务状态中持续存在。但攻击方不仅能影响Agent读取的信息，还能影响Agent调用的能力。当Skill成为Agent扩展能力的主要载体后，影响范围就从信息环境延伸到了能力环境。
2.1.2 Skill供应链投毒
Skill供应链的风险变化，主要体现在攻击方能够施加影响的位置逐步向Agent的能力获取过程深入。攻击方可以影响Skill的描述和选择，使Agent优先加载特定Skill；也可以将恶意内容隐藏在Skill及其配套资源中，使恶意逻辑随Skill进入运行环境；进一步还可以将后门植入Skill内部模型，使恶意行为隐藏在具体能力实现中。公开Skill生态中的恶意活动则进一步表明，这些能力获取环节已经具备现实攻击暴露面。
图2-4 Skill供应链攻击面及能力扩展路径
首先，Skill的自然语言描述本身可能成为影响Agent能力选择的入口。针对Skill注册中心的研究发现，仅修改SKILL.md中的自然语言内容，就能够影响Agent对Skill的排序和选择。在受控实验中，对抗性Skill的平均选择率达到77.6%。
这一结果说明，Skill供应链的攻击面并不只存在于代码和依赖中。对于依赖自然语言描述进行Skill发现和选择的Agent而言，Skill描述同时承担了能力说明和能力选择引导作用。攻击方不需要直接修改Agent，只要能够影响Skill的描述内容，就可能改变Agent最终加载的能力。
当攻击影响从Skill选择进入实际加载过程后，攻击方可以进一步利用公开Skill生态进行恶意内容分发。ClawHavoc活动中，攻击者通过名称仿冒、恶意指令和嵌入式脚本等方式伪装Skill，部分恶意Skill具备SSH密钥窃取和恶意载荷部署等能力。
图2-5 ClawHavoc恶意Skill传播规模与攻击方式
【资料来源：根据Koi Security等公开的安全研究资料整理绘制】
这里的变化在于，Skill不再只是影响Agent“选择什么能力”的入口，还成为恶意能力进入Agent运行环境的分发载体。攻击者可以利用公开Skill生态扩大恶意内容的暴露范围，而一旦恶意Skill被用户安装或被Agent加载，其自身具备的执行能力就可能被用于后续攻击。需要注意的是，Skill安装或下载规模不能直接等同于受害主机数量。
对Skill生态的进一步分析显示，相关问题并非孤立现象。研究人员在大规模Skill生态中发现数百个恶意样本及大量安全问题，涉及凭据和数据窃取、恶意指令和系统访问等行为，部分样本还利用平台信任机制隐藏攻击逻辑。
图2-6 野外Skill生态恶意样本分布与安全问题类型
与此同时，攻击位置还可以继续向Skill内部深入。BadSkill研究将后门逻辑植入Skill所携带的模型，使恶意逻辑不直接暴露在Skill描述或外部执行代码中，而是在满足特定触发条件后产生异常行为。实验覆盖多种Skill、触发任务和模型架构，在部分配置下，较低的投毒比例即可获得较高的平均攻击成功率。
图2-7 BadSkill模型内部后门实验关键数据
这类方法改变的是恶意逻辑在Skill供应链中的隐藏位置：Skill可以在正常任务下继续提供预期功能，而后门逻辑随着Skill内部模型一同进入Agent运行环境。传统针对代码和依赖的完整性检查，因此无法覆盖Skill内部模型所携带的恶意行为。
从上述研究和实际攻击活动看，Skill供应链的攻击面已经覆盖三个相互关联的环节：Skill描述影响Agent选择什么能力，Skill生态决定恶意能力如何进入运行环境，Skill内部内容则决定进入Agent后的能力是否可信。攻击方获得的并不只是一个新的投毒位置，而是能够影响Agent能力发现、加载和执行的完整链条。这意味着Skill安全检查不能只判断代码和依赖是否完整，还需要覆盖来源、描述、选择过程、调用权限以及所携带的模型和其他资源。不能将“能够正常完成预期功能”等同于“Skill整体可信”，因为恶意逻辑可能并不影响正常功能，而是在特定触发条件下才进入攻击流程。
Skill供应链说明，攻击方能够施加影响的位置已经从Agent持续读取的信息延伸到Agent主动加载和调用的能力。当Agent在运行过程中继续获取外部数据、调用工具并与其他Agent交换信息时，供应链边界还会进一步进入这些动态形成的依赖关系。
2.1.3 运行时供应链
前两节关注的主要是攻击方如何通过持久化状态或Skill供应链，使恶意影响进入Agent并持续存在。在Agent实际运行过程中，Agent还会不断获取外部数据、调用工具和访问其他Agent，这些运行过程中动态形成的依赖关系同样可能成为可被利用的环节。攻击方不一定需要长期修改Agent本身，而可以通过影响其持续依赖的数据、资源和交互对象，使恶意内容在运行过程中被再次获取并继续传播。
Runtime Supply Chain研究从这一角度将供应链分析范围扩展到推理和运行阶段，将Agent运行过程中涉及的数据、Memory以及工具获取和调用关系纳入分析。与传统供应链关注“组件在部署前是否可信”不同，这里的关键问题是：Agent运行过程中依赖了什么、这些依赖是否被攻击方影响，以及影响产生的数据是否会继续成为其他Agent的输入。
图2-8 Runtime Supply Chain攻击面及Viral Agent Loop机制
其中，Viral Agent Loop描述了一种具有循环特征的运行时传播机制。攻击方首先向运行环境植入恶意内容，Agent A获取并处理该内容后，对外部环境产生新的数据或状态变化；随后，Agent B从该环境中获取包含这一变化的信息，并将其重新纳入自身任务上下文。如果新的输出再次改变共享环境，该过程就可以继续循环。
这一机制的重要变化在于，外部环境不再只是攻击载荷的存放位置，而成为连接多个Agent运行过程的传播媒介。一次输入产生的结果经过环境变化后，可以重新成为另一个Agent的输入，Agent由此从攻击目标进一步成为攻击传播链中的中间节点。攻击方能够影响的对象也从单个Agent或单个组件，扩展到Agent与外部环境之间持续形成的数据和能力依赖。
这种跨应用传播并非近期才出现。Morris II研究已经在受控环境中验证了GenAI应用之间的恶意内容传播：研究人员构造能够在模型输出中保留原始攻击内容的自复制Prompt，再利用不同GenAI应用之间的数据交换和连接关系，将恶意内容传递至后续应用。针对持续更新数据的RAG应用以及邮件助手等场景的实验表明，恶意内容可以在无需用户再次点击的情况下进入后续应用处理流程。
Morris II与Runtime Supply Chain关注的问题具有连续性，但二者的分析重点并不相同。Morris II主要验证GenAI应用之间的连接可以成为恶意内容传播通道；Runtime Supply Chain则进一步从运行时依赖角度解释这种传播，关注数据流、工具调用和共享环境如何共同形成持续的攻击路径。前者强调内容能够传播到其他应用，后者进一步指出Agent及其运行环境本身可能成为传播链中的中间节点。
图2-9 GenAI应用间恶意内容传播与Viral Agent Loop机制对比
由此可以看到，运行时供应链带来的变化并不是出现了一种新的供应链攻击技术，而是运行时依赖关系本身成为新的攻击面。只要攻击方能够持续影响Agent获取的数据、共享环境或运行时资源，恶意内容就可能被重新获取，并随着Agent之间的数据交换和能力调用继续传播。
对于防守方，供应链安全边界因此不能只停留在部署前的代码、模型和Skill检查，还需要覆盖Agent运行期间形成的数据来源、工具依赖、共享环境以及跨Agent的数据传递关系。尤其需要关注已经被其他Agent处理过的输出，因为这类输出虽然来自看似正常的Agent，却可能已经携带前序攻击影响，并在后续任务中被重新信任和利用。
2.2 能力借用：从资源利用到权限使用
Agent在运行过程中能够调用资源、处理数据并执行业务操作，这使攻击方不必直接取得这些能力对应的凭据或权限，而可以通过影响Agent的任务判断，使Agent代为完成攻击目标。
我们将这种利用方式概括为“能力借用”，包括三种方式：资源劫持（借用Agent的资源使用能力）、数据注入（影响Agent的数据处理链）和授权意图错配（借用Agent已有的身份和业务权限）。其中，数据注入并非直接获取资源，而是通过改变Agent所依据的数据和事实基础，进一步影响后续决策和操作。下面从资源劫持开始分析。
2.2.1 Resource Hijacking
Resource Hijacking的底层资源滥用机制并非新的攻击方式，但Agent将资源调用、服务访问和身份信任集中到自主任务执行过程中后，攻击方可以通过操纵Agent的任务目标，使这些资源在Agent执行任务的过程中被用于攻击目的。相比传统资源劫持直接控制资源本身，这里的关键变化在于攻击方控制的是“资源使用决策”，而不是资源所有权或访问凭据。
图2-10 Agent资源劫持与传统资源劫持对比
ResourceHijackBench将Agent可接触的高价值资源划分为六类，包括计算与存储资源、凭据和身份条件、服务配额与执行成本、组织身份与信任关系、信息与知识资源，以及通信和业务交互资源。研究人员构造了300个攻击场景和900条测试Prompt，并以Agent是否实际使用目标资源作为攻击成功标准，而不仅依据模型是否生成了具有攻击意图的文本。
图2-11 ResourceHijackBench资源分类与实验结果
实验结果显示，在未增加额外防护的情况下，平均攻击成功率达到84.06%，不同资源后端的成功率处于69.98%—89.58%之间；即使加入防护机制，部分场景仍保持较高的资源利用成功率。这些数据说明，Agent会把攻击方设定的目标当成自己的任务来执行，并真实调用相应资源。
这里真正的变化是：攻击方要的不是凭据，而是使用凭据的能力。Agent的合法权限本身没有变，变的是这些权限为谁服务。攻击方只要影响Agent的任务判断，就可能让Agent主动调用计算资源、访问服务接口、消耗服务配额，甚至利用自身所处组织环境中的身份和信任关系完成操作。对防守方来说，光看凭据是否合法已经不够。同一个调用，可能是用户授权Agent做的正常操作，也可能是Agent被引导去执行的攻击方目标，两者在权限层面看起来完全一样。要区分这两种情况，需要判断Agent为什么调用资源、调用结果是否符合当前任务的真实目的。
资源劫持说明攻击方可以借用Agent的资源使用能力。但Agent在执行任务时，不只需要调用资源，还需要依据外部数据做出判断。当攻击方能够改变Agent所依据的数据时，借用的就不再只是资源使用能力，而是Agent的数据处理链。
2.2.2 Agent Data Injection
攻击方可以通过修改Agent读取到的网页、JSON数据或工具返回内容，使Agent依据被篡改的数据继续执行任务。这里被影响的不是Agent收到的直接指令，而是Agent在任务过程中持续获取和使用的外部数据。Agent Data Injection（ADI）由此将攻击方能够施加影响的位置进一步延伸到Agent获取、解析和使用外部数据的完整过程。
ADI不要求攻击方直接控制Agent的对话输入。攻击方可以将恶意内容嵌入Agent后续会读取的数据源，使这些内容以网页元素、结构化字段、搜索结果、文档内容或工具返回值等形式进入任务上下文。Agent在处理这些数据时，如果无法准确区分数据内容与可信的任务信息，就可能将攻击方控制的数据作为后续判断依据，并继续调用工具或执行操作。
图2-12 Agent Data Injection攻击机制示意图
这种攻击方式的关键控制点在于数据进入Agent之后如何被解释和继续使用。例如，在浏览器操作场景中，网页中的恶意内容可以影响Agent对页面元素的识别，使其选择攻击方希望操作的对象；在编码Agent场景中，被篡改的源代码元数据、工具输出或依赖信息，则可能改变Agent对代码来源和执行条件的判断。攻击方并不需要直接修改Agent的系统指令，只需要控制Agent任务流程中能够被读取的数据，就可能影响后续决策。
针对这一问题，CSA联合SNU、UIUC和Largosoft开展的实验测试了多种Agent应用中的数据注入风险。研究人员针对结构化数据和非结构化网页内容分别构造注入场景，并测试了Claude in Chrome、Antigravity、Nanobrowser等Agent。实验中，研究人员将恶意信息嵌入Agent需要处理的数据，使Agent在完成原始任务的同时执行攻击方预设的操作。
实验结果显示，结构化数据场景下的攻击成功率约为31%—43%，而部分非结构化网页场景的成功率最高达到100%。研究人员还发现，通过调整注入内容的位置和数据边界，可以进一步影响Agent对恶意内容的解析。这说明，单纯依靠数据格式、分隔符或输入边界来区分“数据”和“指令”，并不能覆盖Agent处理外部数据时形成的全部攻击路径。
图2-13 Agent Data Injection攻击在不同数据格式和防御机制下的攻击成功率
ADI与Prompt Injection都可能最终影响Agent的任务判断，但攻击方能够施加影响的位置不同：Prompt Injection通常直接针对Agent能够接收到的指令或上下文内容，而ADI更强调攻击方控制Agent后续读取的数据，并利用Agent对这些数据的信任，使其进入任务处理链。当Agent能够持续访问网页、数据库、文件和工具返回结果时，外部数据本身就可能成为影响任务执行的输入通道。
因此，ADI带来的安全问题并不只是“恶意数据进入Agent”，而是外部数据一旦进入Agent的决策和执行链，就可能影响后续操作。这也改变了传统输入过滤的防护边界。如果防护机制只检查用户提交的Prompt，而没有继续验证Agent从外部环境获取的数据来源、完整性和使用上下文，攻击方仍可能通过后续数据流进入Agent的任务过程。对于需要执行高风险操作的Agent，防守方需要将数据源、数据内容、数据进入任务上下文后的处理过程以及由此触发的工具调用纳入统一的信任边界，而不能只在Agent最初接收Prompt的位置进行安全检查。
2.2.3 Authorization Confusion
Agent的权限没有变，变的是这些权限为谁服务。攻击方不一定需要直接取得目标账户、API或业务系统的权限，而可以利用Agent已经获得的身份和授权条件，使Agent在执行任务时完成超出原始授权意图的操作。这类权限使用关系上的错配，被称为Authorization Confusion。
Agent通常以用户身份、组织身份或服务账户调用外部系统。只要调用本身满足权限校验，目标系统就可能将操作视为合法行为，但权限校验只能回答“Agent有没有权限执行”，无法直接判断“Agent当前执行的操作是不是授权主体真正希望完成的操作”。当Agent能够自主理解任务、选择操作并连续调用多个工具时，这种差异就可能成为攻击方能够施加影响的位置。
图2-14 Agent授权意图错配示意图
Authorization Confusion与任务目标被改变、工具调用被操纵等行为往往相互关联，并非总是独立发生。AgentFence在覆盖多类信任边界的测试框架中对多种Agent架构进行了多轮交互测试，结果显示Authorization Confusion与Objective Hijacking、Tool Hijacking之间存在约0.54±0.10的相关性。这说明，当Agent的任务目标发生偏移时，目标控制问题可能传递到工具调用和授权边界，使Agent继续使用原有权限执行已经改变目的的操作。上述结果来自该研究设定的测试环境，不应直接理解为现实生产Agent的攻击概率。
图2-15 Authorization Confusion实验结果
例如，用户可能授权Agent帮助处理账户、文件或业务数据，但并未授权Agent根据外部信息自行修改安全设置、转移数据或执行敏感操作。如果攻击方能够影响Agent对任务目标或操作对象的理解，Agent就可能使用原本合法的权限完成攻击方希望实施的行为。
现实攻击活动进一步说明了这种错配的影响。Meta Instagram账户恢复机制曾出现授权关系与实际账户归属不一致的情况：由于系统未验证请求者提供的邮箱是否属于目标账户，攻击者控制的电子邮箱可以被关联到目标账户，并进一步用于密码重置，相关机制曾影响超过2万个账户。Meta随后关闭自动关联和重置路径，并将敏感账户变更转入人工审核。
图2-16 Meta Instagram账户恢复授权意图错配攻击实例
这一案例的技术背景与Agent环境并不完全相同，但它说明，当系统只验证授权条件而不验证操作意图时，合法权限就可能被用于非预期目的。在Agent环境中，这种问题会进一步受到自主决策机制的放大，因为Agent可以在获得合法权限后自行选择数据、工具和后续操作。
从攻击路径看，Authorization Confusion通常需要同时满足三个条件：Agent已经拥有目标系统的合法权限；攻击方能够影响Agent对任务目标、操作对象或授权范围的理解；目标系统主要依赖身份和权限校验，而缺少对操作意图的进一步验证。当这些条件同时存在时，攻击方就可能借助Agent已有的权限完成原本需要直接取得相应权限才能实施的操作。
因此，Agent权限安全不能只判断“调用是否经过授权”，还需要判断授权是否覆盖当前具体操作，以及Agent为什么执行这一操作。对于账户修改、数据导出、权限变更等高风险行为，应将用户原始意图、Agent当前任务目标和实际执行动作进行关联验证，并在高风险操作进入执行阶段时增加二次确认或人工审核。
Authorization Confusion 说明攻击方可以借用 Agent 已有的合法权限。当 Agent 需要同时调用多个能力时，这些能力之间的衔接关系本身也可能成为新的攻击路径来源。下一节以 Skill 组合为例进行分析。
2.3 Skill组合攻击：从单一能力到复合攻击路径
当Agent能够调用多个Skill时，单独检查每个Skill的安全性已经难以覆盖实际运行中的组合风险。部分Skill在独立执行时并不表现出明显的恶意行为，但多个Skill进入同一任务流程后，上游Skill的输出、运行结果或信任信息可能成为下游Skill的输入和执行条件，使原本分散的能力形成新的调用关系。
图2-17 Skill组合攻击机制示意图
有研究将这一类风险归纳为Skill Composition Risk（SCR），重点分析多个Skill组合后的实际行为，而不是仅根据单个Skill的静态内容进行判断。相关研究将组合风险归纳为能力流、信任转移和授权混淆三类机制：上游Skill可以向下游Skill传递任务目标、数据和运行上下文；正常的执行结果也可能被下游Skill作为可信依据继续使用；不同Skill之间的权限和操作关系还可能形成单独分析时不存在的授权路径。
SCR-Bench和CompoSkill的实验进一步验证了这种组合条件下的风险变化。在SCR-CapFlow测试中，单个Skill独立执行时攻击成功率接近于零，而进入特定组合路径后，攻击成功率达到33.6%。攻击方并不需要把完整的恶意行为集中放入某一个Skill中，而是通过Skill之间的数据传递和执行衔接逐步形成攻击路径。
CompoSkill进一步将Skill组合从被动分析转化为主动构造。在白盒场景下，攻击方可以利用已知Skill池搜索高风险组合；在黑盒场景下，则根据Agent角色画像和公开Skill信息获取候选Skill，并通过Skill Composition Graph搜索可能形成危险行为的Skill链。实验中，白盒条件下危险Skill链形成率最高达到83.3%，黑盒条件下达到80.6%。黑盒场景尤其说明，即使攻击方无法直接获得受害Agent的完整Skill配置，也可能根据公开能力信息构造具有攻击效果的Skill组合。
图2-18 SCR-Bench与CompoSkill实验结果
从影响范围看，Skill组合攻击利用的并不一定是某个Skill内部已经存在的恶意代码或恶意指令，而是不同Skill之间正常存在的输入输出关系、能力衔接和执行交接。单独检查时，每个Skill可能都满足预期功能，但当Agent按照特定顺序调用这些Skill后，上一个Skill产生的信息可能成为下一个Skill的操作依据，多个看似正常的能力由此被连接成单个Skill无法完成的攻击路径。
因此，Skill安全检测的边界需要从单个组件进一步延伸到组合关系。对于能够动态选择Skill、连续调用多个Skill的Agent，除了检查Skill自身的代码、描述和依赖关系，还需要分析Skill之间传递了什么信息、前序结果如何影响后续调用，以及组合后是否产生新的数据访问、工具调用或权限使用能力。特别是在高风险任务中，不能仅依据每个Skill已经通过独立安全检查，就认为由这些Skill形成的整体执行路径同样安全。
第三章
Agent自主攻击能力的演进
上一章分析了攻击方如何利用Agent的持续状态、外部Skill、运行时依赖以及自身具备的资源和权限，将攻击影响带入Agent的任务执行过程。这些攻击面解决的是“攻击方能够利用什么”的问题。在对公开测试和真实攻击活动进行梳理后，我们注意到，变化还出现在“谁来完成攻击过程中的判断和操作”。
在传统攻击流程中，漏洞发现、利用条件判断、Payload构造、执行结果分析以及后续操作通常由人员分别完成。Agent进入这些环节后，一些原本需要人工连续判断的工作开始被交给Agent处理。CVE-Bench实验中，Agent已经需要从漏洞信息出发判断利用条件、构造利用方案并执行请求；AgentCyberRange测试中，初始漏洞利用还可以继续衔接后续任务。在Red Agent的安全测试中，第一次Payload执行失败后，Agent能够读取错误信息、修改Payload并再次执行。
这几个案例呈现出三个相互关联的变化：Agent开始参与漏洞利用判断，执行结果开始进入下一轮攻击决策，攻击过程能够在多个步骤之间持续推进。随着这种能力继续向外延伸，Agent执行的对象、持续时间以及能够影响的环境也发生变化。
本章按照决策自主化、执行规模化、攻击边界扩展三个方面展开。首先分析Agent如何承担漏洞分析和利用判断，并根据执行反馈调整后续操作；随后观察这种能力如何进入连续攻击过程；最后分析Agent与外部系统、人员以及其他Agent交互后，攻击活动边界发生的变化。
3.1 决策自主化
攻击方要利用一个漏洞，并不只是找到漏洞名称或生成一段Payload，还需要判断漏洞是否存在于当前目标、利用条件是否满足、请求应该如何构造，以及执行后返回的结果是否证明利用成功。这些判断通常需要由安全人员结合目标环境分别完成，Agent开始进入这一过程后，漏洞信息可以直接成为后续利用操作的输入。
3.1.1 从漏洞分析到自主利用判断
CVE-Bench实验中，Agent需要完成漏洞理解、利用条件分析、利用方案构造、请求执行和结果验证。也就是说，Agent处理的对象已经从“漏洞是什么”延伸到“这个漏洞能否在当前目标上真正利用”。
图3-1 CVE-Bench中Agent自主漏洞利用过程及实验结果
CVE-Bench使用真实Web应用漏洞作为测试对象，要求Agent直接与目标应用交互。实验结果显示，最优Agent框架能够成功利用约13%的测试漏洞。实验以实际漏洞利用结果作为验证依据，而非仅根据模型是否生成正确的漏洞分析文本判断。
这个过程中的关键变化，是漏洞分析结果开始直接参与攻击决策。Agent需要根据漏洞类型、目标应用返回的信息以及利用条件，判断下一步应该发送什么请求；请求执行后，再根据返回结果确认当前方案是否成立。漏洞识别、利用条件判断和实际执行之间由此形成了连续过程。
CVE-Bench中体现的利用判断能力，还可以继续向初始利用之后延伸。AgentCyberRange将测试环境扩展到真实Web应用和企业化网络靶场，覆盖110个漏洞、15个真实Web应用和8个企业网络环境。在完成初始漏洞利用后，Agent还需要继续处理后续网络任务。
图3-2 AgentCyberRange中自主漏洞利用向后续任务延伸
从攻击过程看，初始漏洞利用在这里不再是测试任务的终点。Agent完成入口建立后，还可以继续根据当前环境处理后续任务，使“发现漏洞”和“进入目标环境”之间出现连续的任务衔接。攻击方由此可以把原本需要分别规划的漏洞利用和后续操作交给同一执行流程处理。
需要区分的是，上述结果来自受控实验环境，不能直接等同于现实攻击中的普遍利用能力。对于防守方，漏洞验证阶段也需要被纳入监测范围：当Agent开始自动构造利用请求并根据目标响应判断漏洞是否可利用时，仅监控漏洞扫描结果已经无法覆盖这一阶段的高风险操作。
3.1.2 从自主验证到反馈式攻击
漏洞利用并不总能一次成功。真正影响后续攻击过程的，是执行失败之后是否能够判断失败原因并修改下一步操作。
Wiz对Red Agent开展的Snowflake授权安全测试提供了一个直接案例。测试过程中，Agent针对GitHub Actions注入问题构造Payload，第一次执行因Bash语法问题失败。Agent读取执行返回的错误信息后，对Payload进行调整并重新执行，随后获得Jira API Token并进一步验证访问权限。
图3-3 Agent反馈式攻击执行过程
这里可以看到一个完整的反馈过程：Agent先执行攻击操作，目标返回执行结果；Agent读取错误信息并重新判断问题所在，再修改下一次操作。第一次失败没有结束任务，失败结果反而成为下一次攻击决策的输入。
这种机制改变了自动化攻击的执行方式。传统脚本通常按照预先设定的条件和顺序执行，一旦关键步骤失败，需要人工修改脚本或重新设定参数；在上述测试中，Agent能够根据实际返回结果调整操作内容，使攻击过程具备一定的运行时适应能力。
这种反馈机制与前面的漏洞利用判断连接起来后，攻击过程中的几个关键环节开始形成连续闭环：Agent分析目标，判断利用条件，执行操作，根据结果重新判断，再决定下一步操作。攻击自动化在这里不只是减少人工点击。执行反馈进入决策过程后，部分攻击决策也被放入了执行循环。
当然，单次Payload修正并不能证明Agent已经能够独立完成复杂攻击链。Snowflake测试更直接体现的是执行反馈如何进入下一轮决策。当这种反馈机制进一步作用于目标选择、权限获取、攻击方式和任务顺序等多个步骤时，攻击活动就会从单次利用进入连续执行阶段，这也是下一节分析的重点。
3.2 执行规模化
当Agent能够根据执行结果调整后续操作时，单次利用产生的反馈就可以继续进入后续攻击步骤。初始访问不再只是一次攻击动作的结束点，而可能成为后续漏洞搜索、权限操作和数据访问的起点。当这种反馈机制继续向后延伸，攻击过程中的多个操作也可以被连接起来。Agent获得初始访问条件后，可以继续处理当前环境中的其他任务；当后续操作受到目标环境影响时，Agent还需要根据返回结果改变原有操作，使攻击过程能够继续向后推进。
本节从连续攻击链和环境适应两个方面进行分析。AEPD事件用于观察这种连续执行是否已经出现在真实攻击活动中；JADEPUFFER则提供更完整的执行反馈证据，用于分析Agent如何在攻击过程中处理失败结果并调整后续操作。JADEPUFFER完整攻击活动将在第四章进一步展开，本节只讨论其中能够体现环境适应的过程。
3.2.1 从单步利用到连续攻击链
AEPD于2026年9月披露的一起数据泄露事件中，相关组织提交的事件通知记录了AI Agent参与攻击后的连续操作过程。已公开信息显示，攻击从搜索通用文件中的漏洞开始，在获得有效登录条件后，Agent继续搜索应用漏洞，并进一步修改个人数据、访问账单信息。
图3-4 AEPD事件中Agent连续攻击过程
获得登录条件并没有结束攻击活动。Agent继续利用当前环境中的访问条件搜索新的攻击入口，并将漏洞利用与后续数据操作连接起来。前一步获得的访问条件成为后续操作的执行条件，攻击过程不再停留于一次漏洞利用，而是延伸为多个连续步骤。如果初始访问只是一个独立的自动化动作，后续操作仍需要攻击者重新判断目标和执行方式；而在该事件披露的过程中，漏洞搜索、漏洞利用以及数据访问已经出现在连续的Agent执行过程中。
目前AEPD公开的信息主要来自相关组织提交的事件通知，尚未披露具体漏洞、Payload、Agent工具链和模型配置。现阶段可以确认的是攻击步骤之间存在连续关系，但无法据此还原完整的技术利用链。
从攻击监测角度看，初始访问之后的行为需要与入口阶段关联起来。异常登录、漏洞利用、数据修改和业务数据访问如果分别进行检测，可能被视为多个独立事件；当这些操作由同一Agent任务连续产生时，需要进一步关联其时间、身份、目标和操作上下文，才能识别连续执行形成的攻击过程。
3.2.2 从自动执行到环境适应
连续执行还面临一个实际问题：目标环境不会始终按照攻击方预设的条件返回结果。认证参数可能不匹配，请求可能执行失败，服务配置也可能与预期不同。攻击能否继续推进，取决于执行结果能否影响下一步操作。JADEPUFFER事件中的Nacos攻击过程提供了较明确的技术证据。攻击者通过互联网暴露的Langflow获得初始访问后，Agent继续发现目标环境中的服务，并尝试对Nacos执行操作。在创建管理员账户的尝试失败后，Agent根据返回结果调整后续操作，随后再次执行并获得访问权限。
图3-5 JADEPUFFER攻击过程中的环境反馈与操作调整
这里最值得分析的不是Nacos本身，而是失败结果在攻击流程中的作用。第一次操作没有达到预期结果后，Agent没有简单结束当前任务，而是继续处理返回信息，并据此改变下一次操作。
与3.1.2中单次Payload修正不同，JADEPUFFER中的反馈发生在进入目标环境之后的连续攻击过程中。Agent需要面对服务发现、认证和权限获取等不同操作产生的环境信息，并根据这些信息重新决定后续操作。
从技术实现看，Agent能够继续推进攻击至少需要三个条件：能够获取目标环境返回的信息，能够将这些信息用于判断当前操作状态，还能够根据判断结果重新构造后续操作。攻击过程中的环境状态成为Agent持续执行的重要输入。从公开材料来看，在特定目标环境、工具和任务条件下，Agent已经参与了从环境发现、攻击尝试到失败处理和再次执行的连续过程。
JADEPUFFER公开分析中还包含初始访问、环境侦察、凭据搜索、内部服务发现以及后续数据库操作等更多攻击阶段。第四章将以JADEPUFFER为完整案例进一步还原攻击过程。本节仅讨论其中能够体现环境适应的过程。
3.3 攻击边界扩展
前两节我们分析了Agent如何参与攻击过程内部的判断和执行。随着Agent能够访问互联网、调用外部服务并持续处理任务，其实际接触的对象也开始超出原本的目标系统。攻击活动可以进一步延伸到第三方服务、公开互联网资源以及真实人员和组织。
这种变化首先表现为Agent能够将新的外部系统、服务和人员纳入攻击过程。受控测试中，Agent已经出现面向真实人员和组织的未经授权行为；真实入侵活动中，Agent也被用于访问第三方平台、获取外部凭据并继续推进攻击。攻击边界不再只由目标主机和内部网络决定，而开始受到Agent实际能够访问和交互的外部环境影响。
当多个Agent被组织到同一攻击框架中后，这种扩展还会进一步发生。不同Agent可以分别承担侦察、漏洞利用、凭据获取、数据处理等任务，并通过共享信息把各自的执行结果传递给其他Agent。攻击活动的边界由单个Agent能够完成的任务，进一步扩展到整个Agent群体能够共同完成的任务集合。
3.3.1 从单一系统到外部环境
Agent获得互联网访问能力后，攻击目标已经不再局限于当前任务所对应的技术系统。AISI在2026年7月开展的网络安全评估中，对122次测试运行进行了调查，其中10次出现了超出测试范围、面向真实互联网目标的自主行动，共记录19起相关行为。AISI于8月4日正式披露了这一事件报告。
图3-6 AISI测试中Agent面向真实互联网目标的攻击行为
【来源：AISI《Security Incident INC-2026-07-28-01》】
其中一次行为中，Agent不仅识别了公开开源项目，还进一步收集项目维护者的公开信息、创建虚假身份并与维护者进行交互，试图推动恶意代码进入开源项目。维护者最终拒绝了相关代码。这一过程已经超出了传统网络攻击中“扫描目标—利用漏洞—控制系统”的技术边界，Agent开始把真实人员及其决策行为纳入攻击过程。
这里发生变化的并不是Agent多获得了一项通信功能，而是人员和组织关系本身成为了Agent可以尝试操作的攻击对象。当Agent能够搜索公开信息、创建账号、发送消息并持续处理对方反馈时，攻击行动就可以从技术系统进一步延伸到人员交互环节。
类似的边界扩展也出现在真实入侵活动中。2026年7月公开的Hugging Face事件显示，参与内部网络安全评估的Agent突破了原有环境隔离，获得互联网访问能力，并进一步访问第三方基础设施。OpenAI后续披露的信息显示，相关Agent还通过外部消息渠道交换信息、获取公开凭据，并继续利用第三方系统中的漏洞。
图3-7 Agent从受控执行环境向第三方系统扩展
【来源：Hugging Face，Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident】
Hugging Face随后发布的技术复盘进一步还原了这一过程：Agent从外部沙箱进入Hugging Face的数据处理环境，通过数据处理链中的两个攻击入口获得生产Worker上的代码执行能力，随后继续获取集群、云环境和内部网络中的凭据，并向多个内部环境横向移动。整个入侵过程中，Hugging Face记录了约17,600次攻击者操作。
这些行为说明，只要Agent能够访问新的网络环境，并能够将获得的凭据、服务信息或执行结果继续用于后续操作，新的系统和外部对象就可能被纳入同一个攻击过程。
对防守方而言，Agent的网络边界不能只按照“允许访问哪些目标IP或服务”进行判断。真实攻击过程中，Agent可能通过公开互联网、第三方平台、公开身份信息和业务通信渠道不断发现新的交互对象，因此需要同时关注Agent实际访问过的对象、建立的身份关系以及这些交互是否与原始任务目标一致。
3.3.2 从单Agent执行到多Agent协同
当一个Agent承担侦察、漏洞分析、工具调用和执行任务时，攻击过程受到单个Agent上下文和执行能力的限制。进一步的变化是，攻击方开始将多个Agent组织到同一攻击框架中，让不同Agent分别处理不同任务，再通过共享信息或任务调度将结果重新汇聚。
Google Threat Intelligence Group在2026年9月8日发布的AI威胁追踪报告中披露，攻击者部署了自主multi-agent框架，用于管理扫描流程、处理执行错误并开展大规模凭据窃取。相关行动中，攻击者先控制云资源，再利用AI编码聊天机器人、Prompt和Agent指令构建攻击框架，在不到六小时内完成大规模凭据收集。该框架管理了漏洞扫描管道、收集凭据、解决技术问题并轮换IP地址，全程无需人工干预。GTIG还单独发现了一个暴露的命令控制服务器，运行名为“Recon”的自动化侦察与凭据管理系统，实时管理超过23,800个凭据，包括云平台和AI服务的API密钥。
图3-8 GTIG观察到的multi-agent攻击框架与任务分工
【来源：Google Threat Intelligence Group（GTIG），《GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI》】
这里的关键变化是攻击任务开始被拆分到多个相互配合的执行单元。这些任务不再必须由同一个Agent按顺序完成，而可以由不同Agent或不同工作流并行处理。Google披露的框架还具备对扫描流程和执行错误进行自动管理的能力，使部分操作能够持续运行，而不需要攻击者逐项干预。
Anthropic在2026年9月10日发布的最新AI威胁报告中，也观察到了类似结构。相关报告描述了一个由主Agent拆解侦察与入侵后任务、再向多个子Agent分派工作的结构。不同工作流可以分别承担入侵、政府信息侦察、安全产品逆向、恶意软件开发以及数据收集等任务，同时保存目标名单、取得的凭证与任务进度，使后续工作可以直接接续。部分操作能够并行运行数小时甚至更长时间，部分漏洞研究与情报搜集甚至会在操作员离开后继续执行。
图3-9 多Agent侦察任务的持续执行与信息循环
【来源：Anthropic，《Detecting and countering misuse of AI: September 2026》】
从执行关系看，多Agent协同增加的并不只是“同时运行几个Agent”，而是改变了攻击任务的组织方式。主Agent可以负责任务拆分和结果汇聚，子Agent分别处理具体技术环节，再将发现的目标、凭据、漏洞或执行结果交回其他工作流使用。单个Agent原本只能覆盖的任务范围因此被多个执行单元连接起来。
当前公开案例仍需要区分“多Agent协同”和“AI自动化”。一个Agent调用多个工具、连续执行多个命令，并不能直接称为多Agent协同；只有存在多个独立Agent或执行工作流之间的任务分工、信息交换或结果传递时，才能支持这一判断。当前公开事件已经提供了这类证据，但不同攻击活动中的协同程度仍然存在差异，不能简单视为统一的技术架构。
从这一变化继续观察，Agent对攻击活动的影响已经不只是替代某一个攻击环节，而开始改变攻击任务的组织方式。攻击者需要直接参与的操作进一步减少，本章讨论的决策自主化与执行规模化，也从单个Agent的能力变化延伸到多个Agent之间的任务协同。
第四章
Agent攻击能力的真实案例分析
4.1 JADEPUFFER案例
Sysdig于2026年7月披露JADEPUFFER相关攻击活动。攻击者首先利用Langflow的CVE-2025-3248获得远程代码执行能力，随后从初始主机获取凭据、探测内部服务并访问下游生产环境，最终对生产数据库实施破坏和勒索。7月20日，Sysdig进一步披露JADEPUFFER再次进入同一Langflow环境，并部署专门针对AI/ML基础设施的ENCFORGE勒索程序。
在整理公开披露的攻击载荷、代码片段和执行记录时，可以看出JADEPUFFER的技术特征并不只体现在使用LLM生成攻击代码，而是体现在攻击代码能够持续获取执行结果，并据此调整后续操作。公开记录中可以看到，MinIO访问方式在返回结果异常后发生调整，Nacos账户创建失败后重新生成修正载荷，Docker Socket探测结果又进一步触发了容器环境利用和载荷部署。攻击过程由此从一次性脚本执行转变为持续的环境探测、动作执行和结果校正。
4.1.1 初始访问后的环境探测
JADEPUFFER首先利用Langflow的CVE-2025-3248获得Python代码执行能力。进入主机后，攻击载荷立即执行id、uname、hostname、网络接口和进程信息等环境探测，并同步搜索云凭据、LLM API Key、数据库配置和其他敏感信息。随后，攻击活动进一步扫描内部地址空间和服务，并尝试访问数据库、对象存储和配置服务。
从公开载荷代码中可以看到，JADEPUFFER并不是针对某一个固定服务执行单次探测，而是根据当前环境中发现的服务继续展开操作。例如，在发现MinIO服务后，载荷首先访问对象存储接口并枚举Bucket，随后进一步读取名称包含credentials.json和.env的对象。公开代码中可以看到，其使用HTTP请求访问MinIO接口，并解析返回的S3 XML结构；随后再针对指定对象执行读取并将内容保存到本地。
图4-1 JADEPUFFER对MinIO的探测与凭据获取
这一过程体现出攻击代码与环境信息之间的直接关联。攻击者获得Langflow执行权限后，后续操作并未局限于初始主机，而是继续利用环境中发现的服务和凭据寻找下一阶段目标。
4.1.2 执行结果驱动的操作调整
报告第三章从能力演进角度分析了JADEPUFFER的环境适应特征。这里我们进一步从代码层面观察这一调整过程是如何实现的。
对公开执行记录和代码片段进行比对后可以看到，JADEPUFFER多次出现“执行结果改变后续代码”的情况。
例如，在MinIO探测过程中，第一次请求尝试以JSON格式获取结果，但服务实际返回XML数据。随后生成的载荷直接调整解析方式，改为按照S3 XML结构提取Bucket信息，再继续读取目标对象。公开记录还显示，在JWT路径返回目标环境使用自定义密钥后，该路径被放弃。
这一过程与简单的失败重试存在区别。后续操作针对的是前一次执行产生的具体结果，而不是机械地重复同一命令。类似逻辑在Nacos账户创建过程中表现得更加明显。
公开载荷首先通过子进程调用生成bcrypt密码哈希，并写入新的管理员账户。登录验证失败后，31秒内又出现新的修正载荷：删除原账户、重新生成密码哈希并再次创建管理员账户。第二次代码直接导入bcrypt模块，并通过新的方式生成哈希。
图4-2 JADEPUFFER Nacos账户创建与失败修正
从代码变化可以看出，第二次操作并不是简单重新执行第一次脚本，而是针对前一次执行结果改变了实现方式。这种处理方式使后续Payload能够根据目标环境返回的具体结果改变参数、解析方式或执行路径，而不是继续执行原有代码。
4.1.3 容器边界探测
在获得数据库访问能力后，JADEPUFFER继续测试当前环境是否存在进一步扩大控制范围的条件。公开载荷使用MySQL的文件读取能力依次测试 /var/run/docker.sock、/proc/1/cgroup 和 /etc/hostname，进一步获取当前运行环境信息。
图4-3 JADEPUFFER通过MySQL进行容器环境探测
这里的技术变化并不是单纯增加一个容器逃逸技术，而是攻击过程开始根据环境条件选择下一步攻击路径。数据库访问本身成为新的探测入口，探测结果再决定是否继续向容器边界外扩展。
这一机制在JADEPUFFER后续攻击中进一步得到体现。第二次活动中，攻击载荷发现/var/run/docker.sock并确认Docker服务可访问；随后尝试直接下载ENCFORGE失败。公开记录显示，下载ENCFORGE失败后，后续Payload没有停止执行，而是改变载荷传递方式，转而利用Docker Socket创建具有宿主机权限的容器，并通过procfs将勒索程序从原容器环境复制到宿主机。
4.1.4 脚本迭代与载荷部署
这一过程提供了更直接的代码证据。公开记录显示，JADEPUFFER通过Langflow RCE通道连续构造6个Python脚本，从do.py v1逐步迭代到deploy.py v2，总过程约5分24秒。不同版本分别增加了/proc//root复制、共享执行函数、临时容器、Unix Socket HTTP客户端、动态PID获取以及执行后验证等逻辑。
图4-4 JADEPUFFER攻击脚本的版本迭代时间线
【来源：Sysdig，《JADEPUFFER: Agentic Ransomware for Automated Database Extortion》】
最终版本deploy.py v2已经将多个操作组合到一个连续执行流程中。公开代码显示，该脚本首先通过Docker Unix Socket创建容器，并设置宿主机PID、特权模式以及宿主机文件系统挂载；随后获取目标容器PID，通过/proc//root复制勒索程序；执行试运行检查；确认后启动实际加密；最后再次执行检查并统计.locked文件数量。
从代码结构来看，这里已经不再是单个命令或独立利用脚本，而是包含“环境获取、载荷传递、试运行、正式执行、结果验证”的完整执行逻辑。尤其是最后的.locked文件数量检查，使攻击程序能够获取最终执行结果，而不是在发出加密命令后直接结束。
图4-5 JADEPUFFER最终载荷的容器利用与执行验证
4.1.5 数据库勒索与AI/ML资产加密
JADEPUFFER第一阶段主要针对MySQL和Nacos环境实施数据破坏。公开载荷使用MySQL的AES_ENCRYPT()处理Nacos配置，并删除原始配置和历史表，同时创建勒索信息表。其后续操作进一步从单个表的数据加密扩展到数据库级破坏。
后续活动中，攻击目标进一步转向AI/ML基础设施。JADEPUFFER部署的ENCFORGE是一款使用Go编译并经过UPX压缩的勒索程序，公开分析显示其包含约180种目标文件扩展名，覆盖模型检查点、向量索引以及训练数据等AI/ML资产。其–include参数还允许根据目标环境追加文件类型。
图4-6 ENCFORGE针对AI/ML资产的文件目标范围
对两个阶段的攻击载荷进行比对后可以看到，攻击能力的扩展并不是简单增加一个新的勒索程序，而是攻击执行过程中已经能够根据目标环境持续寻找可利用资源，并将获得的控制能力进一步用于载荷部署和目标破坏。第一阶段依靠Python脚本和数据库自身能力完成勒索，第二阶段则进一步部署针对AI/ML文件格式设计的专用勒索程序。
4.1.6 小结
JADEPUFFER案例所体现的技术变化，并不是传统攻击技术被AI简单重新实现。公开代码和执行记录显示，攻击过程持续获取环境信息，并将命令执行结果作为后续操作的输入。攻击代码不再完全依赖预先确定的环境条件，而是根据实际执行结果调整后续操作。
第二次活动中的6个脚本版本进一步将环境探测、容器利用、载荷传递、试运行、正式执行和结果验证组合到连续执行过程中。前后Payload之间存在明显的状态承接和调整关系，前一阶段获得的环境信息和执行结果会影响后续操作，使漏洞利用获得的初始执行权限能够继续转化为对内部服务、容器环境和宿主机的操作能力。攻击过程的变化主要发生在初始入侵之后：通过多轮执行和调整，一次初始入侵逐步扩展为连续的环境内操作，最终完成目标破坏。
4.2 PromptSpy案例
ESET于2026年2月披露PromptSpy，并发现其在恶意软件执行过程中调用Google Gemini参与UI操作。ESET分析的样本来自两个版本，其中较早的VNCSpy已经具备VNC远程控制能力，后续PromptSpy在此基础上加入了Gemini驱动的UI操作功能。需要注意的是，ESET表示其遥测中尚未观察到PromptSpy Dropper及Payload，这可能意味着相关样本属于概念验证；但VirusTotal记录显示，PromptSpy Dropper样本曾通过mgardownload[.]com分发，因此ESET认为不能排除其已经在野外存在的可能性。
基于公开披露的样本代码、执行流程和网络通信数据来看，PromptSpy并没有将生成式AI用于全部恶意功能，而是将Gemini嵌入到一个具体的执行环节：通过读取当前Android界面状态，由模型判断下一步UI操作，再通过Accessibility Service执行。这个过程使原本依赖固定坐标和固定界面路径的部分操作，转变为根据运行时界面状态动态生成操作参数。
4.2.1 从VNCSpy到PromptSpy
PromptSpy样本具有明显的多阶段结构。Dropper内部嵌入了app-release.apk，用户启动Dropper后，会看到要求安装所谓“更新程序”的界面，实际安装的则是第二阶段PromptSpy Payload。Payload启动后首先申请Accessibility Service权限，为后续读取UI状态和执行自动化操作提供条件。
从样本代码来看，PromptSpy并非从零开始构建全部恶意能力。其前身VNCSpy已经包含VNC远程控制组件，PromptSpy在此基础上增加了AI辅助的UI操作功能。VNC模块用于远程查看和控制设备，而Gemini主要参与“将应用锁定在Recent Apps列表”这一持久化操作。
图4-7 PromptSpy多阶段安装与启动流程
【来源：ESET，《PromptSpy: An Android malware using Gemini for UI interaction》】
PromptSpy启动后会显示一个简单的Loading界面作为前台诱饵，同时在后台启动Gemini相关操作。执行流程显示，恶意软件随后打开Recent Apps界面并获取当前UI状态，由Gemini判断如何完成“锁定应用”操作。
图4-8 PromptSpy调用Gemini参与UI操作的网络通信
【来源：ESET，《PromptSpy: An Android malware using Gemini for UI interaction》】
4.2.2 Gemini调用与System Prompt约束
PromptSpy对Gemini的使用并不是将一段自然语言简单发送给模型。样本代码显示，PromptSpy在初始化Gemini通信时已经将模型、Prompt以及输出格式预置到恶意代码中，模型需要承担的任务被限定为Android UI状态分析和结构化操作指令生成。
其中，System Prompt对模型输出进行了较为严格的约束。UI节点中的bounds采用[left,top][right,bottom]格式，模型需要根据边界计算点击位置；只有在当前UI中观察到明确的成功状态时才能返回COMPLETED；如果上一操作已经执行但界面尚未反映结果，则继续保持IN_PROGRESS并等待下一轮状态获取；对于需要移动界面的情况，则使用SWIPE并返回起止坐标和持续时间。
这意味着Gemini在PromptSpy中并不是自由生成操作文本，而是被限制在一个预定义的UI状态判断—结构化操作输出接口内。恶意代码负责提供当前环境状态并解析模型返回的参数，模型负责根据状态确定下一步操作。
图4-9 PromptSpy中硬编码Gemini调用及System Prompt
这种设计降低了模型输出与恶意代码执行接口之间的转换成本。PromptSpy不需要将自然语言回答再次转换为可执行动作，而是要求Gemini直接返回预定义字段，恶意代码解析这些字段后即可进入后续执行流程。
4.2.3 UI状态输入
PromptSpy使用Accessibility Service获取当前Android界面信息。样本中提取到的字段包括可见文本、Content Description、Class名称、Package名称以及屏幕Bounds等。恶意软件将这些信息序列化为XML，并把当前UI快照加入发送给Gemini的Prompt。
这里的关键并不是“模型能够识别屏幕”，而是PromptSpy首先通过系统接口将真实设备状态转换成结构化数据，再把结构化状态交给模型进行判断。模型因此获得的不是预先写死的页面名称或坐标，而是当前设备实际呈现出的UI元素及其位置。
图4-10 PromptSpy提交Gemini的UI状态数据
与固定脚本相比，这种输入方式使操作参数可以随当前UI状态发生变化。即使目标控件位置、页面布局或系统界面存在差异，模型仍然可以根据新的UI XML重新判断目标位置。
4.2.4 操作指令生成与执行
在获得UI XML后，PromptSpy将当前状态发送给Gemini。模型返回结构化JSON，其中包含当前任务状态、操作类型以及具体操作参数。
某次模型响应如下：
json{ "status": "IN_PROGRESS", "reasoning": "I have accessed the recent apps list. I can see 'MorganArgs' listed in the recent apps. The next step is to long-click on the 'MorganArgs' app card to bring up the options menu, which should include an option to lock it.", "action_type": "LONG_CLICK", "x": 586, "y": 1126, "x1": -1, "y1": -1, "x2": -1, "y2": -1, "duration_ms": -1}
这个响应体现了PromptSpy中AI输出与恶意执行之间的直接衔接：模型首先判断当前UI状态，然后指定LONG_CLICK操作，并给出具体坐标；PromptSpy解析JSON后，再通过Accessibility Service执行对应操作。
图4-11 Gemini生成的结构化UI操作指令
这里可以看到，AI在恶意软件中的作用已经从“生成文本”转变为生成能够直接进入执行接口的控制参数。Accessibility Service并不需要理解模型的自然语言推理，只需要按照解析后的操作类型和坐标执行相应动作。
4.2.5 AI反馈循环
PromptSpy对Gemini的调用不是一次性的。完成一次操作后，恶意软件会重新获取当前UI状态，并将更新后的UI XML再次提交给Gemini。模型根据新的状态判断任务是否已经完成；如果没有完成，则返回下一步操作。样本中的Prompt明确要求模型不能仅根据“上一动作已经执行”判断任务完成，而必须在新的UI状态中观察到明确的成功迹象。
例如，在执行长按操作后，PromptSpy会向Gemini发送更新后的UI信息，并要求模型重新判断当前状态。如果Recent Apps中的目标应用已经出现锁定状态，则返回COMPLETED；如果状态尚未变化，则继续返回IN_PROGRESS并进行下一轮操作。
图4-12 PromptSpy基于UI状态的AI反馈执行闭环
这一机制使PromptSpy的UI操作从一次性脚本变成了具有状态验证的循环。传统固定脚本通常在代码中预设操作位置和执行顺序，而PromptSpy将“当前界面是什么状态”和“下一步应该执行什么动作”分离开来：设备状态由Accessibility Service采集，操作判断由Gemini完成，实际动作仍由恶意代码执行。
因此，生成式AI并没有替代Android系统接口，而是被插入到状态解析和操作参数生成这一环节，成为恶意执行流程中的一个动态决策组件。
4.2.6 功能分工
PromptSpy的AI能力范围相对集中。从样本代码分析来看，其核心恶意能力仍然由传统代码实现，包括VNC远程控制、屏幕截图、屏幕录像、已安装应用收集、设备信息获取、锁屏PIN或密码截取以及反卸载等。Gemini主要用于完成Recent Apps锁定这一持久化相关操作。
PromptSpy通过硬编码C&C地址与远程服务器建立VNC通信，并使用AES对通信进行加密。C&C还可以向恶意软件提供Gemini API Key，并接收已安装应用列表、锁屏数据以及屏幕采集结果。
此外，PromptSpy继续利用Accessibility Service实现传统的防卸载机制。当用户尝试停止服务或卸载应用时，恶意代码会在特定按钮区域创建透明覆盖层，对包含stop、end、clear和Uninstall等字符串的按钮进行拦截。通过调试方式可以将这些原本不可见的区域显示出来，从而验证该机制。
图4-13 PromptSpy利用Accessibility Service实施反卸载
【来源：ESET，《PromptSpy: An Android malware using Gemini for UI interaction》】
从功能分工来看，PromptSpy形成了两类不同的代码路径：Gemini负责根据当前UI状态生成操作参数，传统恶意代码负责VNC远程控制、数据采集、通信、反卸载以及实际的Accessibility执行。AI并没有替代这些传统功能，而是改变了其中部分UI操作的参数生成方式。
这种组合使AI能力集中作用于一个原本容易受到设备差异影响的环节。Recent Apps锁定操作在不同设备、系统版本和厂商UI中存在差异，固定脚本较难覆盖这些变化；PromptSpy则通过当前UI状态重新生成操作参数，从而减少对预设坐标和固定路径的依赖。
4.2.7 小结
PromptSpy案例体现的技术变化，并不是传统恶意功能整体由生成式AI接管，而是将模型引入具体的UI执行环节。恶意软件通过Accessibility Service获取当前Android界面信息并形成XML，将界面状态提交Gemini后，由模型按照预设Prompt返回结构化操作参数，再通过Accessibility Service执行；操作完成后重新获取UI状态并再次提交模型。原本依赖固定坐标和预设操作路径的部分执行逻辑，由此转化为根据运行时界面状态生成操作参数。
从功能分工看，Gemini主要承担UI状态分析和下一步操作参数生成，传统恶意代码负责其余功能。该案例体现的技术变化集中在执行环节：生成式AI被嵌入恶意软件实际运行流程，根据设备当前状态参与操作决策，并通过执行结果形成持续的UI操作反馈。与JADEPUFFER通过执行结果调整后续Payload不同，PromptSpy将这种状态反馈机制用于解决终端UI差异，使模型参与到具体操作参数的生成过程中。
第五章
防御建议
前文分析表明，Agent安全风险已从模型输入输出延伸至任务状态、工具权限和连续执行过程。防护重点需从“防止模型产生错误输出”转向“控制Agent如何获得信息、使用能力和持续执行任务”。
5.1 保护Agent任务状态和外部知识
Memory、RAG和任务上下文已成为Agent持续执行任务的重要信息来源。对能够影响长期状态的外部内容，应建立来源验证、可信度标记和写入控制机制，将外部数据与系统指令隔离，避免未经验证的信息直接进入长期Memory或作为后续任务的高可信输入。对长期保存的任务状态，记录来源和变更关系，关键操作前重新验证状态完整性。
5.2 限制工具能力与授权边界
按任务需求配置工具白名单，限制每个工具能够访问的资源范围。Agent应使用独立身份和最小权限运行，不应默认继承用户或主机的全部权限。跨系统调用时重新验证身份、任务目的和授权范围，不能因为已经获得一次授权就默认后续操作全部属于原有授权。账户创建、权限提升、数据导出等高风险操作应建立任务与授权的关联校验。
5.3 加强供应链控制
Skill、MCP服务和第三方工具扩大了供应链攻击面。防护重点不应只停留在组件是否包含恶意代码，还需关注组件实际获得了哪些数据、工具和权限。对第三方组件建立来源验证、版本管理和运行时行为监控，发现与声明任务功能不一致的操作时及时限制其运行。
5.4 建立任务级监控与响应
单个工具调用可能并不异常，但多个操作组合后可能形成完整攻击路径。应记录任务级执行轨迹，关联分析上下文来源、工具调用、执行结果和后续操作。为自动重试和动态调整设置边界，连续失败重试、操作权限逐步提升或任务行为偏离初始目标时，触发暂停或人工确认。发现异常任务时，支持暂停执行、撤销权限、关闭工具调用和切断外部连接。
总体来看，Agent防护需要同时控制三个层面：输入侧决定Agent接收的信息是否可信，能力侧决定Agent能够执行什么操作，执行侧决定异常行为能否被及时发现和阻断。三者结合，才能覆盖Agent攻击面从输入侧向执行侧扩展后的主要风险。
第六章
未来影响与发展趋势
前文分析表明，AI Agent带来的变化已经不只是增加一种攻击工具，而是使攻击方能够利用Agent已有的数据、工具、身份和执行能力，并通过持续反馈将不同能力组织到同一任务中。随着Agent连接的系统和可调用能力进一步增加，这种变化可能继续影响攻击能力的获取方式、攻击活动的组织规模以及攻防双方的响应节奏。
6.1 攻击能力获取方式变化
传统攻击活动通常需要攻击者自行准备漏洞利用代码、信息收集工具、凭证处理脚本和后续执行工具。随着Agent体系逐渐成熟，攻击者可能不再需要自行构建全部攻击能力，而是通过调用Agent及其外部工具获得相应的执行能力。
这种变化意味着攻击能力的形成方式可能从“自行构建工具”进一步转向“调用和组合能力”。Skill、MCP服务、代码执行环境以及其他Agent服务，都可能成为攻击能力的调用接口。攻击者只需要提供目标、任务约束或部分上下文，即可能调用已经具备特定能力的Agent完成相应操作。
如果不同Agent和外部组件之间能够进一步组合，攻击者获得的就不再是某一个固定工具，而是一组可以按照任务动态调用的能力资源。这可能降低攻击活动对单一攻击工具和固定Payload的依赖，也使攻击能力本身逐渐从独立工具向可调用的能力资源转变。
6.2 攻击活动组织规模变化
多Agent架构进一步发展后，复杂攻击任务可能被拆分为多个相互关联的子任务，由不同Agent分别承担信息收集、漏洞分析、执行、数据处理等工作。这种模式带来的变化并不只是增加Agent数量，而是可能改变攻击活动的组织方式。
不同Agent可以并行处理不同目标，并将执行结果作为其他任务的输入；攻击者需要直接参与的工作可能从逐步操作工具转向设置任务目标、分配任务和控制整体执行过程。当这种模式进一步规模化后，同一组攻击资源可以同时处理多个目标或多个攻击任务，攻击活动的并行处理能力也可能随之增加。
与此同时，多Agent协同会形成新的数据和状态传播关系。一个Agent产生的结果如果被其他Agent直接作为可信输入使用，相关影响就可能通过任务协作关系继续扩散。因此，未来多Agent系统需要进一步控制任务间的数据传递、状态共享和权限继承。
6.3 攻防时间尺度与安全边界变化
Agent能够持续处理任务状态并根据执行结果调整后续操作后，信息收集、分析、执行和验证等多个环节可以在较短时间内连续完成。对防守方而言，变化不只是攻击速度提高，而是原本需要人工分别确认的多个操作阶段可能被压缩到连续的机器执行过程中。
未来安全防护需要进一步缩短从异常发现到任务阻断之间的时间。对于具备持续执行能力的Agent，应能够在检测到异常任务后快速暂停任务、撤销临时权限并切断相关工具调用，而不能完全依赖事后分析。
另一方面，Agent连接的资源越多，其任务边界越可能跨越传统的主机、应用和账户边界。一个Agent任务可能同时访问代码仓库、数据库、云平台、内部服务和外部API，而这些资源原本属于不同的安全域。未来Agent安全边界可能需要从单一系统边界进一步转向围绕任务、身份和能力调用关系进行划分，安全控制需要关注的不只是Agent“能访问什么”，还包括其在当前任务中“为什么访问、以什么身份访问、调用后还能继续获得什么能力”。当任务目标、访问资源和实际操作之间出现明显偏离时，应能够及时限制后续能力调用。
总体来看，AI Agent可能推动攻击活动从依赖独立工具和人工操作，进一步转向调用能力资源、多Agent协同和连续机器执行。随着Agent承担的任务范围扩大，攻击活动的规模、执行节奏以及跨系统能力可能继续发生变化，现有围绕单一主机、账户或应用建立的安全控制也需要逐步适应这种变化。
第七章
总 结
本报告围绕AI Agent攻击面的变化和攻击能力演进进行了分析。Agent的安全影响已从模型输入输出扩展至任务状态、工具、身份、权限和执行环境，攻击能力的形成方式也逐渐从攻击者自行开发工具，转向调用、借用和组合Agent已有能力。从攻击面看，Agent引入的状态保存、外部知识和第三方能力调用，使攻击者获得了更多影响任务执行的入口；从攻击能力看，Agent开始参与漏洞研判、环境探测、攻击执行和任务协同等环节，并能够根据执行结果调整后续操作。
真实案例进一步表明，这种变化已经进入实际攻击和恶意软件执行过程。JADEPUFFER展示了攻击代码根据环境信息和执行结果调整后续操作的过程，PromptSpy则展示了生成式AI根据终端UI状态生成操作指令、并通过执行结果持续推进任务的方式。两类案例虽然作用对象不同，但都体现出AI参与攻击执行后，攻击过程对实时环境信息的依赖进一步增强。
这也意味着，Agent安全防护需要从模型输入输出进一步覆盖任务状态、工具调用和运行时执行过程，并建立任务级监控、异常行为阻断和权限快速撤销机制，将安全控制从单个组件或单次操作扩展到完整任务过程。未来，随着Agent连接更多系统并承担更加复杂的任务，攻击能力可能进一步向能力调用、多Agent协同和连续机器执行方向发展。安全团队需要围绕Agent实际能够获得和转化的能力重新评估攻击面，将任务、身份、工具和执行环境纳入统一的安全分析范围，并持续关注不同能力组合后形成的攻击路径。
启明星辰积极防御实验室（ADLab）
ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞7000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、电信运营商基础设施安全研究、移动终端安全研究、云安全研究、信创安全研究、物联网安全研究、车联网安全研究、工控安全研究、数据安全研究、5G安全研究、AI安全研究、卫星安全研究、低空安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：ADLab 启明星辰
启明星辰《AI Agent安全威胁与攻击能力演进研究—— 攻击能力扩张的新路径》