ChronosAttack：LLM Agent 的对抗性工具调度时序攻击

摘要

ChronosAttack 首次提出工具响应时序本身构成攻击面。攻击者仅通过引入有界非负延迟（bounded non-negative delay）改变真实工具响应的到达顺序，不修改、添加、删除或加速任何响应内容，即可影响 LLM Agent 在多轮工具交互中的最终决策。作者在 GPT-5.6 Sol、Gemini 3.6 Flash、DeepSeek V4 Flash 和 Claude Sonnet 4.6 上评估了两个决策场景（云备份提供商选择和物流合作伙伴选择），每个场景在 stateful 模式下执行 30 次自然运行和 30 次攻击重复。结果表明单一调度反转（schedule reversal）即可导致大的决策变化：GPT-5.6 Sol 和 Claude Sonnet 4.6 在脆弱场景中显示强目标的决策偏移，Gemini 3.6 Flash 显示反向的大偏移，DeepSeek V4 Flash 相对更稳定。

这是首次揭示 Agent 工具交互中存在时序维度的攻击面的研究，但不代表所有 Agent 系统都面临相同的决策脆弱性。同步屏障（causal barrier synchronization）和顺序一致性投票（sequential consistency voting）两种防御可减少攻击者控制，但防御效果依赖于场景和模型。

核心创新与差异

原研究贡献：ChronosAttack 将攻击面从传统的 Prompt、工具响应内容、工具数量和身份扩展到工具响应的到达顺序。攻击者不需要具备修改工具响应内容的能力，仅通过控制各工具响应的延迟（不加速、不删除、不添加）即可实施攻击。论文形式化了 bounded-delay adversary 威胁模型，并提出了两种防御机制：因果屏障同步（causal barrier sync，即等待所有响应到达后再做决策）和顺序一致性投票（sequential consistency voting，即检查不同排序方式的决策是否一致）。

本站分析：这项研究在工具使用安全中新增了一个此前未被审视的失效模式——Agent 将工具响应的到达顺序视为中性或可信的，但该顺序实际上可被攻击者控制。这与本分类下已有的 Function Hijacking（工具描述影响路由）和能力门控不等于授权的研究形成互补：Function Hijacking 关注工具元数据内容对路由的偏置，ChronosAttack 关注内容不变但顺序被篡改时的决策偏移。最先失效的控制是 Agent 将响应到达时序作为可信输入而非攻击者可控的信号。

威胁模型与攻击链

攻击者能力：攻击者可向一个或多个工具调用的响应引入有界非负延迟，但不能修改、添加、删除或加速任何响应。延迟仅改变响应到达 Agent 的相对顺序，不改变响应内容本身。

威胁模型：攻击者控制了 Agent 与工具之间的通信信道（如代理、中间件或调度器），或控制了某些工具服务的响应速度（如通过负载控制或资源竞争）。工具响应的内容来源于合法的工具实现，攻击者不能写入或篡改内容。

目标资产：Agent 在多轮工具交互后做出的最终决策——例如选择哪个云备份提供商或物流合作伙伴。

最先失效的安全控制：Agent 决策过程对工具响应到达顺序的敏感性，以及缺少对响应排序完整性的验证机制。Agent 隐含地将先到达的响应赋予更高的注意力权重或优先级，但该顺序可被攻击者操纵。

攻击链：

1. Agent 发出多个并发的工具调用请求。
2. 攻击者引入有界延迟，改变部分响应的返回顺序，但不修改响应内容。
3. 以被操纵顺序排列的响应进入 Agent 的上下文窗口，影响其注意力分配和推理过程。
4. Agent 基于被操纵的顺序做出最终决策，可能与自然顺序下的决策不同。

攻击方法与复现材料

以下为本站依据论文公开机制重构的去武器化伪代码，用于说明延迟注入点、调度反转实现方法和防御机制设计。所有响应内容和模型调用均在本地 mock 环境中进行，不连接真实工具或 Agent 服务。

延迟注入与调度反转

攻击者在 Agent 的工具调用分发层和响应接收层之间引入一个可控延迟组件。以下伪代码描述攻击者的调度反转逻辑：

# 攻击者控制的调度器（本站依据公开机制重构，仅用于说明攻击原理）
# 所有工具响应内容为 mock 数据，不连接真实服务

def attacker_scheduler(tool_calls, honest_responses, delays):
    """
    tool_calls: Agent 发出的工具调用列表
    honest_responses: 各工具的真实响应内容（mock 数据）
    delays: 攻击者为每个调用引入的非负有界延迟，单位为秒
    """
    # 步骤 1：收集所有响应（内容来自 mock，不修改）
    scheduled = []
    for call, resp in zip(tool_calls, honest_responses):
        scheduled.append({
            "tool": call.name,
            "response": resp,      # 内容不变
            "delay": delays[call.name],  # 攻击者只控制延迟
        })

    # 步骤 2：按攻击者指定的延迟排序，延迟小的先到达 Agent
    scheduled.sort(key=lambda x: x["delay"])

    # 步骤 3：按被操纵的顺序逐个交付给 Agent
    for item in scheduled:
        wait(item["delay"])  # DRY_RUN: 实际不执行真实等待
        yield item["tool"], item["response"]

防御机制一：因果屏障同步

因果屏障同步（causal barrier sync）要求 Agent 在所有并行工具调用全部返回之后再统一处理响应，拒绝在部分响应到达时就开始推理。该防御消除了响应到达顺序对决策的影响，但会增加端到端延迟。

# 因果屏障同步防御（本站依据公开机制描述的去武器化实现）
# 所有响应内容为 DRY_RUN mock，不连接真实服务

def causal_barrier_sync(tool_calls, response_collector):
    """
    等待所有调用全部返回后再交付给 Agent 决策模块
    """
    all_responses = {}

    # 并发发起所有调用（DRY_RUN mock）
    for call in tool_calls:
        response_collector.submit(call)  # 异步提交

    # 屏障：等待所有响应到达
    while not response_collector.all_done():
        wait_for_next_response()  # DRY_RUN

    # 收集所有响应后统一交付，不保留到达顺序信息
    for call in tool_calls:
        all_responses[call.name] = response_collector.get(call)

    # 交付时不保证任何特定顺序
    return all_responses

防御机制二：顺序一致性投票

顺序一致性投票（sequential consistency voting）让 Agent 在多个响应排列下独立决策，仅当所有排列产生一致的决策时才接受。如果不一致，则标记为可疑或回退到安全默认值。

# 顺序一致性投票防御（本站依据公开机制描述的去武器化实现）
# DRY_RUN mock，不连接真实 Agent 或工具

def sequential_consistency_vote(responses, agent_decide, num_permutations=5):
    """
    responses: 所有工具响应（内容来自 mock）
    agent_decide: Agent 的决策函数（DRY_RUN mock）
    对不同的响应排列分别决策，检查一致性
    """
    decisions = []

    for perm in generate_permutations(responses, num_permutations):
        # 按当前排列顺序交付响应
        ordered_responses = [responses[name] for name in perm]
        # Agent 基于此排列做出决策
        decision = agent_decide(ordered_responses, dry_run=True)
        decisions.append(decision)

    # 检查所有排列是否产生相同决策
    if all(d == decisions[0] for d in decisions):
        return decisions[0], "consistent"
    else:
        # 不一致时回退到安全默认值或要求人工介入
        return SAFE_DEFAULT, "inconsistent - fallback triggered"

前置条件：自有或明确授权的离线模型环境，mock 工具响应，DRY_RUN 模式。防御验证中不执行真实支付、资源分配或对第三方服务的调用。

省略项：不包含可连接真实 Agent 服务的端点地址、真实凭据、真实工具 Schema，也不包含可针对生产 Agent 系统实施延迟注入的完整代码。

实验设计与实际过程

作者实验设置（以下均为作者在论文中报告的实验，本站未执行独立复现）：

• 模型：GPT-5.6 Sol、Gemini 3.6 Flash、DeepSeek V4 Flash、Claude Sonnet 4.6，均通过 API 访问。
• 场景：两个多轮工具交互决策场景——
  1. 云备份提供商选择：Agent 查询多家提供商的价格、可靠性、存储容量等属性后做出推荐。
  2. 物流合作伙伴选择：Agent 查询多家物流公司的时效、覆盖范围、成本后做出选择。
• 模式：stateful 模式，即 Agent 在多轮交互中维护状态，每轮调用一个工具并等待响应后再决定下一轮调用。
• 重复次数：每个场景 30 次自然运行（无延迟操纵）+ 30 次攻击重复（攻击者引入延迟操纵响应到达顺序）。
• 指标：决策偏移（decision shift）——攻击运行下 Agent 选择与自然运行下不同选项的比例。

攻击者引入的延迟是有界的（不超过自然运行中最慢响应的到达时间），且不修改任何响应内容。

关键结果与实际影响

• GPT-5.6 Sol 和 Claude Sonnet 4.6 在脆弱场景中显示强目标的决策偏移（即攻击可以系统性地将决策推向攻击者期望的选项）。
• Gemini 3.6 Flash 显示反向的大偏移（决策偏移方向与攻击者意图相反），表明响应顺序影响存在但与攻击者目标的关系可能是非线性的。
• DeepSeek V4 Flash 在两个场景中相对更稳定，决策偏移较小。
• 单一调度反转（仅交换两个响应的到达顺序）即可导致大的决策变化，说明 Agent 对响应顺序的敏感性不依赖于多轮累积效应。
• 上述结果在论文指定的模型版本、场景和延迟条件下成立，不能直接外推为所有 Tool Calling 模型都存在相同程度的时序脆弱性。

实际影响是：如果部署 Agent 的系统中存在攻击者可以影响工具响应延迟的组件（如共享网络、调度器、代理中间件、资源竞争），Agent 的最终决策可能被操纵。这种攻击路径不需要攻击者具备注入恶意内容或篡改响应的能力，仅需控制响应时序。

防护措施与验证方法

将响应时序视为不可信输入，在 Agent 架构中引入时序无关的决策机制。

预防：

• 因果屏障同步：在 Agent 的工具编排层引入屏障机制，要求所有并行调用全部返回后再开始推理，拒绝在部分响应到达时提前决策。代价是增加端到端延迟（受最慢响应约束）。
• 顺序一致性投票：对工具响应执行多次不同排列下的独立决策，仅在一致性满足时接受结果。不一致时回退到安全默认值或请求人工确认。代价是额外的推理开销（与排列数成正比）。

检测：

• 监控同一 Agent 实例中工具响应的到达间隔和顺序异常（如历史模式中总是先返回的工具此次后返回）。
• 在 Agent 决策日志中记录响应到达顺序，用于事后审计和归因。

验证方法（应在自有或授权的离线环境中进行）：

• 选取多个决策场景和 Agent 模型，分别在自然顺序和攻击者操纵顺序下运行，记录决策偏移率。
• 分别测试因果屏障同步和顺序一致性投票在实际部署中的效果，报告决策偏移降低比例、额外延迟和推理开销。
• 验证防御不会因引入屏障或投票而错误拒绝在自然顺序下正确的决策（误拒率）。
• 所有副作用接收端使用 mock 或不路由的本地端点。

局限与待验证问题

• 论文仅在两个特定决策场景和四个模型版本上评估，未覆盖更多样的 Agent 架构（如 ReAct、Plan-and-Execute）、更多工具类型或更复杂的多阶段决策链。
• 实验在 stateful 模式下进行（Agent 串行调用工具），未评估 stateless 批处理模式下时序攻击的有效性。
• 攻击者的延迟能力和边界根据场景设定，未探索自适应延迟策略或攻击者最佳延迟分配方案。
• 同步屏障防御会增加端到端延迟（最坏情况受最慢工具响应约束），在实时性要求高的场景中可能不可用；顺序一致性投票的推理开销与排列数呈线性关系，在工具调用数量多时可能成本过高。
• 论文未验证防御在生产环境中的工程可行性，包括与现有 Agent 框架（如 LangChain、LangGraph 等）的集成复杂度。
• 本站未执行独立复现；以上均为作者在论文中报告的实验结果和机制描述。
• 尚需在更广泛的模型、框架和真实部署场景中独立验证时序攻击的可利用性和防御的有效性。

参考链接

• ChronosAttack: Adversarial Tool Scheduling Attacks on LLM Agents
• Tool Use、Agency 与审批控制研究综述