AudioHijack: audio imperceptible secuestra agentes de voz (IEEE S&P 2026)
Un artículo de IEEE S&P del 16 de abril de 2026 introduce la inyección de prompt auditiva: una reverberación adversaria oculta en el audio empuja a 13 modelos de audio-lenguaje y a agentes de voz comerciales (Mistral AI, Microsoft Azure) a ejecutar acciones no autorizadas con un 79-96% de éxito.
What is this?
El 16 de abril de 2026, Meng Chen y colegas de la Universidad de Zhejiang, la Nanyang Technological University y la National University of Singapore publicaron en arXiv Hijacking Large Audio-Language Models via Context-Agnostic and Imperceptible Auditory Prompt Injection (2604.14604, cs.CR). El artículo ha sido aceptado en IEEE S&P 2026 e introduce una categoría que los autores denominan inyección de prompt auditiva contra los Large Audio-Language Models (LALMs).
El resultado incomoda. Una señal adversaria breve — entrenada en aproximadamente media hora y después mezclada por convolución dentro de una reverberación ordinaria — embebe instrucciones de un atacante en cualquier audio que el usuario reproduzca cerca de un agente de voz. El usuario oye un podcast, una canción, un vídeo o una nota de voz normal. El modelo, en cambio, recibe un canal de control. En 13 LALMs de última generación, las tasas de éxito promedio se sitúan entre el 79% y el 96% sobre seis categorías de comportamientos desviados. En un estudio en condiciones reales, la misma señal condujo a los agentes de voz comerciales de Mistral AI y Microsoft Azure a realizar búsquedas web, descargar archivos y exfiltrar correos en nombre del usuario.
Es la primera vez que una inyección de prompt auditiva se demuestra a la vez context-agnostic (la misma señal funciona independientemente de lo que el usuario dijera) e imperceptible (la perturbación se esconde dentro de una reverberación natural).
How it works
Los LALMs estándar — Qwen2-Audio, SALMONN, sistemas de la clase GPT-4o-audio, las pilas de voz de Mistral y Azure — toman una forma de onda continua, la tokenizan mediante un front-end de audio no diferenciable y alimentan esos tokens a un LLM de texto. Dos propiedades de ese pipeline son las que AudioHijack explota.
Primero, el canal de audio es continuo y de alta dimensión, lo que ofrece muchos más grados de libertad a una perturbación pequeña que un canal textual. Segundo, el tokenizador es no diferenciable, lo que históricamente bloqueaba ataques de gradiente de extremo a extremo; el artículo sortea ese obstáculo con estimación de gradiente basada en muestreo.
El framework se compone de tres piezas.
Supervisión de atención. Durante la optimización, la perturbación se recompensa por desplazar la atención del modelo hacia el segmento adversarial del audio y alejarla de las palabras del usuario. Esto es lo que da a la ataque su propiedad context-agnostic — el modelo «escucha» el audio adversarial sea cual sea la frase del humano.
Entrenamiento multi-contexto. Cada perturbación se entrena contra múltiples enunciados aleatorios de usuario para que generalice a contextos no vistos. El artículo reporta tasas de éxito del 79%-96% sobre contextos jamás vistos en entrenamiento.
Mezcla convolucional. El ruido adversarial crudo es audible. AudioHijack convoluciona la perturbación con una respuesta impulsiva de sala natural para que se perciba como reverberación. Los estudios de escucha del artículo confirman que los usuarios no la perciben como ataque — sólo como acústica ambiental.
Componente Propósito Efecto en el LALM
------------------------ ----------------------------------- -----------------------------------
Gradiente por muestreo Estimar gradiente a través del Permite optimización end-to-end
tokenizador audio no diferenciable contra pipelines casi black-box
Supervisión de atención Dirigir la atención del modelo al Desacopla el ataque del contenido
segmento adversarial del usuario (context-agnostic)
Entrenamiento Entrenar sobre prompts diversos Generaliza a contextos no vistos
multi-contexto
Mezcla convolucional Embeber la perturbación en Imperceptible al oyente humano
reverberación
El conjunto de comportamientos desviados que mide el artículo incluye seis categorías — rechazo de tareas legítimas, fuga de instrucciones de sistema, fabricación de llamadas a herramientas, llamadas no autorizadas a herramientas, generación de contenido prohibido y sustitución silenciosa de la intención del usuario. Las demostraciones en condiciones reales cubren la descarga de archivos controlados por el atacante, el envío de correos con datos del usuario y la desviación de búsquedas web — todo desencadenado mientras el usuario habla con el agente de otra cosa.
Aquí no se reproduce ningún payload. El artículo arXiv, la publicación de código de los autores en GitHub y la publicación de IEEE S&P 2026 son las referencias canónicas para los investigadores que quieran reproducir el resultado en un laboratorio.
Why it matters
Tres propiedades hacen que esta clase sea más difícil que la inyección de prompt en texto.
Primero, el modelo de confianza se rompe en la frontera de modalidad. Un agente de voz ya acepta por diseño el audio del entorno como entrada primaria. No existe equivalente de «documento no confiable» para un sonido que el usuario reprodujo voluntariamente. El micrófono está haciendo exactamente aquello para lo que fue diseñado.
Segundo, transferencia a sistemas comerciales. La sección en condiciones reales del artículo es la que los defensores deberían leer primero: el audio adversarial generado localmente se transfirió a los agentes de voz de Microsoft Azure y Mistral AI y los indujo a realizar acciones sensibles mediante llamadas a herramientas simples o encadenadas. No es un resultado de laboratorio cerrado — cruza la brecha hacia pilas de voz de nivel productivo.
Tercero, las defensas hoy desplegadas son débiles. Los autores evaluaron dos mitigaciones naturales y publican cifras crudas: el endurecimiento por prompt («cuidado con instrucciones sospechosas») redujo la tasa de éxito sólo en 7 puntos porcentuales, y la verificación de intención (el modelo comprueba si su respuesta coincide con lo que el usuario pidió) detectó apenas el 28% de los ataques. Ningún enfoque se acerca a una solución.
El patrón más amplio importa a cualquiera que despliegue agentes multimodales. Cada nueva modalidad de entrada — audio, imagen, vídeo, sensor — es un nuevo canal de inyección que las defensas centradas en texto no cubren. AudioHijack es el caso de estudio en audio; la lección estructural es más amplia.
Defenses
A finales de mayo de 2026 ninguna mitigación aislada retira esta clase. La lista más defendible, extraída del artículo y de las buenas prácticas estándar de seguridad multimodal:
- Autenticar el canal de entrada, no sólo el contenido. Los agentes de voz deberían distinguir el audio que el usuario habló directamente en el micrófono del audio reproducido por un altavoz en el entorno. Señales hardware de presencia (campo cercano vs. lejano, segundo array de micrófonos, vibración) pueden dar al agente una noción de origen que los pipelines puramente textuales nunca tuvieron.
- Tratar el audio ambiental como no confiable por defecto. Cuando un segmento de audio no puede atribuirse con confianza al locutor activo, degradar su autoridad: no permitir llamadas a herramientas ni escrituras en memoria derivadas de ese segmento sin un paso de confirmación.
- Entrenamiento adversarial y defensas certificadas. El artículo señala que el endurecimiento ad hoc por prompt no es eficaz. El entrenamiento adversarial sobre perturbaciones tipo AudioHijack, las transformaciones aleatorias de entrada (remuestreo, inyección de ruido, ida y vuelta MP3) y las técnicas de robustez certificada son las direcciones a financiar, con la advertencia explícita de que ninguna está resuelta.
- Restringir la superficie de herramientas de los agentes de voz. Un agente de voz que no puede enviar correo, no puede descargar archivos arbitrarios y no puede navegar a URLs arbitrarias, no puede ser forzado a esas acciones desde un prompt secuestrado. Aplicar la Agents Rule of Two — como máximo dos entre «entrada no confiable / herramientas sensibles / canal de exfiltración» a la vez.
- Exigir confirmación explícita para acciones de alto impacto. Enviar un correo, descargar un archivo, transferir dinero, cambiar una configuración: una breve confirmación hablada o en pantalla rompe la cadena de ataque silenciosa incluso cuando la inyección de prompt tiene éxito en el modelo.
- Registrar y poder reproducir el contexto de audio para acciones de alta autoridad. Cuando un agente de voz realiza una acción sensible, el audio que la precedió debería conservarse y ser revisable de modo que un análisis posterior pueda reconocer una superposición tipo AudioHijack.
- Vigilar el patrón intermodal, no sólo el audio. El mismo problema estructural — una modalidad no textual con un espacio de entrada continuo, de alta dimensión y un front-end no diferenciable — vale para los LLMs visuales, de vídeo y de sensores. Las defensas deben diseñarse independientes de la modalidad.
Status
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Artículo | arXiv:2604.14604 v1 | 2026-04-16 | Aceptado en IEEE S&P 2026 |
| Código | github.com/zju-muslab/AudioHijack | 2026-04 | Implementación de referencia |
| LALMs afectados | 13 modelos de última generación | — | 79-96% ASR promedio en contextos no vistos |
| Agentes comerciales afectados | Agente de voz Mistral AI; agentes de voz Microsoft Azure | 2026-04 | Secuestro de llamadas a herramientas demostrado en condiciones reales |
| Defensas evaluadas | Endurecimiento por prompt; verificación de intención | 2026-04 | -7 pp de ASR; 28% de detección — insuficiente |
| Categoría | Inyección de prompt multimodal | — | Nueva clase de ataque propuesta por los autores |
El audio había sido hasta ahora la modalidad donde la inyección de prompt se estudiaba al nivel del jailbreak — conseguir que el modelo diga algo que rechazaría por escrito. AudioHijack da un paso más: conseguir que el agente actúe en nombre del usuario, mientras el humano en la sala sólo oye reverberación ordinaria. El artículo de abril de 2026 no retira ninguna defensa; sí retira la suposición de que la voz fuera el canal más seguro.
Sources
- → https://arxiv.org/abs/2604.14604
- → https://arxiv.org/html/2604.14604v1
- → https://github.com/zju-muslab/AudioHijack
- → https://cybernews.com/security/ai-voice-bots-hidden-audio-hijack-attacks/
- → https://spectrum.ieee.org/voice-ai-audio-attacks
- → https://cyberinsider.com/ai-assistants-can-be-hijacked-and-manipulated-by-inaudible-sounds/