分支引导攻击与Agent安全防御架构解析

一、概念定义：什么是分支引导攻击

分支引导攻击（Branch Steering Attack）是一类针对智能体系统的间接操纵手法。它的核心特征是：攻击者不向模型发送或注入任何指令性内容，而是篡改、伪造或污染Agent在关键分支判断点所依赖的外部数据，使Agent从“用户批准的合法分支集合”中，选择一条虽然被计划允许、却不符合用户真实意图的执行路径。

可以从三个视角理解这一定义：

• 技术视角：Agent的执行计划通常被建模为一组带条件的分支。传统防御致力于保证控制流完整性（CFI，Control-Flow Integrity），即Agent只能沿计划内分支执行、不能调用计划外工具。而分支引导攻击绕开了控制流层面，直接攻击“分支条件的输入数据”，属于数据完整性层面的威胁。
• 业务视角：用户授权的是“目标与规则”（例如预算内购买），而非某一次具体的感知结果。攻击者正是利用“规则合法、感知失真”之间的缝隙完成操纵。
• 使用视角：用户看到的是Agent每一步都符合既定流程，没有越权、没有听从陌生指令，但最终结果却被引导到了对攻击者有利的分支上，隐蔽性极强。

这一定义来自近期多所海外高校研究团队的系统研究。该研究的关键结论可以概括为一句话：锁定Agent的执行计划，并不等于锁定执行结果。

二、背景与价值：Agent安全重心正在转移

早期Agent主要用于对话与内容生成，安全问题的关键是“模型能否识别并拒绝恶意指令”。而当Agent开始真正操作外部系统——浏览器、图形界面、接口调用、文件系统——一次错误执行就对应一次真实业务动作：下单、发送邮件、修改配置、删除数据。此时安全目标从“不执行恶意指令”升级为“可信地约束每一次实际执行”。

传统计算机操作类Agent（Computer-Use Agent）普遍采用ReAct模式：观察页面、推理下一步、执行操作，再根据新的页面状态继续决策。在这个循环里，同一个模型同时接触用户指令与外部数据，外部数据天然构成攻击面。分支引导攻击的价值在于揭示了一个系统性缺口：“计划安全”与“执行安全”是两回事，防御必须从提示层下沉到数据层与执行层。

三、工作原理：数据影响分支，分支触发操作

以一个简化示例说明机制。用户指令：购买一件商品，价格不得超过2000元。计划被写成两个分支：价格不超过预算则进入购买流程，否则停止。两条分支都在授权范围内，无论走哪条都“符合计划”。

用伪代码表示：

budget = 2000
price = read_page_price(page) # 数据来自不可信的外部页面
if price <= budget: # 分支判断点
submit_order() # 高风险动作
else:
abort(“超出预算，停止购买”)

攻击过程如下：

1. 攻击者控制Agent将要读取的某块页面内容，例如广告位、商品评论区，或能干扰视觉识别的页面元素；
2. 将不满足条件的商品伪装成低于预算的展示形态，例如篡改显示价格、遮挡真实价格、诱导视觉误识别；
3. Agent把被污染的信息当作真实价格，判断为“符合预算”，进入购买分支；
4. 整个过程中，页面里可以完全不存在“忽略之前的指令”“现在执行某个操作”之类的提示注入语句。

要点在于：攻击者干预的是判断依据，而不是行为规则。规则依旧被执行，只是规则所依赖的“事实”被替换了。需要说明，购物例子是为说明机制做的简化示意，实际能否造成错误下单，还取决于结算金额等关键量能否在执行边界被独立核验；真正值得警惕的是“数据影响分支、分支触发操作”这条传导链路。

四、为什么“锁死执行计划”仍然不安全

第一，CFI防住了计划外，防不住计划内。控制流完整性确保Agent只能沿预定义分支执行，但分支引导攻击的整条路径都在计划内：两个分支都是合法出口，攻击者只是在合法出口之间完成了一次“引导”。

第二，双模型隔离（Dual-LLM）有明确边界。这种思路让负责规划的P-LLM只读取可信任务描述、提前生成执行计划；负责操作的Q-LLM虽然会看到网页与工具返回结果，却不能改写计划。这在结构上阻断了“外部数据改写计划”的通路，但问题在于：分支条件本身仍需从不可信环境中取值——计划没被改，喂给计划的输入被改了。

第三，控制流完整性与数据完整性是两个正交问题。锁死计划解决的是“能不能走别的路”；分支引导解决的是“让你以为现在该走这条路”。二者必须分别设防。这也解释了为什么注入检测、指令过滤、工具白名单等已有防护在此类攻击面前常常失效：页面上根本没有可检测的恶意指令。

五、COBRA：把防御下沉到执行层的系统级思路

针对上述缺口，研究者在同一工作中提出了名为COBRA的系统级防御架构。其总体目标是：当Agent真正操作外部系统后，安全机制必须能可信地约束每一次实际执行，而不仅仅约束“计划文本”。从公开研究思路归纳，这类系统级防御通常围绕以下原则展开（具体模块与实现细节以原始论文为准）：

1. 决策数据可信化：识别哪些数据会进入分支判断，对数据来源分级标记，将不可信数据与可信上下文隔离；
2. 执行边界独立核验：在动作真正落地前，用独立于被污染上下文的可信通道重新核验关键业务量，如结算金额、收件对象、目标文件路径，核验通过才放行；
3. 最小权限与二次确认：对不可逆、涉及资金或数据破坏的操作，要求显式确认或独立凭证；
4. 全链路审计：记录每次分支判断所依据的数据快照与判断结果，保证事后可追溯、可归因。

其共同思想是：不再假设“计划内的分支都是安全的”，而是为每一个高风险分支的触发条件建立独立的信任锚点。

六、与相关概念的区别与联系

1. 与提示注入的区别：提示注入通过夹带恶意自然语言指令直接改写模型行为，通常存在可检测的恶意文本；分支引导攻击不发送指令、只污染判断数据，行为规则始终合法，文本层面往往“干净”。二者都利用了模型对上下文中不可信内容的信任，前者攻击“行为规则”，后者攻击“判断依据”。
2. 与越权工具调用的区别：越权调用是执行了计划之外的动作，属于控制流被破坏；分支引导中Agent执行的动作完全在计划之内，属于数据层被引导。
3. 与传统Web安全的联系：分支引导本质上是“不可信输入影响业务决策”这一经典问题在Agent场景的再现，攻击面从参数层扩展到了感知层（含视觉通道），因此输入校验、多源交叉验证等传统思路仍具参考价值，但需要针对感知失真重新设计。

七、典型适用场景

• 电商与交易类Agent：代下单、比价、领券，分支条件是价格、库存等可被页面污染的量；
• 办公自动化Agent：自动处理邮件、填写表单、审批流转，分支条件可能来自邮件正文或网页字段；
• 运维与企业流程自动化：根据监控数据或页面状态触发不同操作序列，数据被污染可能导致误操作；
• 浏览器操作类助手：凡是“读取网页、条件判断、执行动作”的链路，均存在同类风险。

八、落地防护清单与注意事项

1. 盘点分支判断点：梳理计划中所有条件判断，标明每个条件的取值来源与可信级别；
2. 关键量独立核验：金额、数量、目标对象等关键量，在执行边界用可信来源复核，不直接信任页面读取结果；
3. 感知层鲁棒性：对页面视觉元素与结构变化保持防御性读取，必要时多源交叉验证；
4. 高风险动作加闸门：不可逆操作引入人工在环或独立确认机制；
5. 数据来源与污点标记：让下游决策知道“这个数字来自广告位或评论区”；
6. 审计与监控：记录分支依据，监控异常分支命中率，及时发现被引导迹象；
7. 选型考量：优先考察大模型服务平台与Agent运行环境是否提供内容安全审核、操作审计、敏感动作管控等配套能力。例如百度智能云等主流云平台的大模型服务通常将内容安全、审计日志类能力作为通用组件提供，可作为企业构建Agent执行安全体系的基础设施之一。

九、总结

回到定义本身：分支引导攻击是一种不依赖提示注入的间接操纵手法，它利用“计划合法、数据失真”之间的缝隙，让Agent沿计划内分支执行偏离用户真实意图的操作。它揭示的核心事实是——锁定执行计划不等于锁定执行结果，控制流完整性与数据完整性必须分别设防。对开发者与企业而言，Agent安全的重心应从“识别恶意指令”转向“可信地约束每一次实际执行”：为分支判断建立可信数据源，为高风险动作建立执行边界核验，为全链路建立审计能力。只有当计划、数据、动作三层同时可信时，Agent的自动化能力才能真正安全地释放。