Skip to content

AudioHijack:不可感知音频 Prompt Injection 与语音 Agent 工具滥用 ​

摘要 ​

AudioHijack 研究第三方音频如何越权影响 Audio LLM:攻击者仅能提交或混入音频,目标是使模型在与用户真实问题无关的上下文中输出指定行为,部分实验进一步观察受控工具调用。作者在 13 个 Audio LLM、六类行为和未见用户上下文中报告 79%–96% 的行为匹配成功率,并在两项商业语音服务的受控试验中获得非零效果。

证据来自作者的优化、开放模型和 API 条件实验;商业服务没有公开全部内部配置,且版本会变动。因此它证明的是特定实现与实验环境下的音频来源认证缺口,不证明所有语音助手都会执行未授权动作。

核心创新与差异 ​

原研究贡献是面向离散音频 token 化的黑盒/数据受限优化:通过采样估计与跨上下文训练生成可迁移的音频扰动,并以声学保真度和行为匹配共同评估。它不同于当前用户直接用语音内容越狱,也不同于“持续监听时环境声与用户声并发”的攻击:这里的根因是外来音频样本被系统作为可影响高权限行为的指令来源。

本站分析将其归入 Prompt Injection 与上下文信任边界。语音转写、音频编码器或“看似自然”的载体不能证明内容已获授权;安全控制应在动作前验证来源、任务关联性和权限,而不是只依赖音频是否可感知。

威胁模型与攻击链 ​

攻击者只具音频数据注入能力,不能访问目标模型参数、用户账号或工具凭据。音频可作为上传文件、媒体片段或被 Agent 处理的外部声音进入系统;高影响后果需要目标 Agent 本身拥有相应工具权限。

  1. 第三方音频进入 Agent 的感知或转写路径。
  2. 模型从声音特征中恢复与当前用户意图无关的行为引导。
  3. Agent 将该影响带入回复或结构化工具参数。
  4. 缺少独立授权与参数约束时,工具可能执行错误目标的动作。

攻击工件与复现材料 ​

作者公开代码、数据和演示音频;本站未运行或转载其优化载荷、目标响应或商业服务调用配置。下列为不含攻击指令、真实端点或工具动作的验证骨架,用于测试“来源约束是否生效”:

python
sample = load_local_audio("fixture.wav")
result = agent.process_audio(sample, dry_run=True)
assert result.tool_calls == []                 # 外来媒体默认无工具授权
assert result.provenance == "third_party"
assert result.requires_user_confirmation is True
record_audio_hash(sample, result)

该夹具保留攻击链第 1、3、4 步的判定点,但省略原文的扰动优化、行为目标、工具调用 JSON 和 API 配置,避免产生可直接用于第三方语音服务滥用的完整链路。

实验设计与实际过程 ​

作者使用 AirBench、VoiceBench 等音频—文本数据,在 13 个不同架构/规模的 Audio LLM 上衡量提示词注入成功率和行为匹配成功率,并以 SNR、STOI、PESQ 等估计可感知性。工具误用实验将目标行为表示为文本或 JSON;商业实验限于两项服务的 PoC,论文明确其专有实现和 API 限制影响可见性。

关键结果与实际影响 ​

  • 在论文开放模型设置中,未见用户上下文的平均行为匹配成功率为 79%–96%;结果随模型、行为类别、音频长度和载体变化。
  • 商业服务实验的结果只能说明作者测试版本存在风险信号,不能得出当前服务、全部账户或所有工具配置均受影响。
  • 防护评估中的语义检测、注意力偏移检测和声学检测均有明显漏报或误报,表明单一分类器不足以替代外部来源隔离与逐调用授权。

防护措施与验证方法 ​

对外来音频保留可验证来源标签,与用户实时指令分通道处理;默认禁止媒体内容直接授权工具。高风险调用要求可信 UI 确认并展示规范化对象/参数;服务端应限制工具 scope、记录音频哈希和决策轨迹。红队测试须加入干净音频、噪声、不同语言/载体及零工具权限对照,并报告误报、拒绝率和效用损失。

局限与待验证问题 ​

优化代价、模型/API 差异和专有服务可观测性限制了复现。论文主要评估独立模型和受控工具情形,尚未覆盖多说话人分离、真实电话链路、端侧模型、持续监听与长期记忆。所有载荷都应仅在自有或明确授权环境中测试。

参考链接 ​