There’s a version of prompt injection that doesn’t need you to read anything, click anything, or type anything. It only needs your device’s microphone to hear a sound — one engineered so that you can’t. Researchers from Zhejiang University, the National University of Singapore, and Nanyang Technological University demonstrated it in a paper accepted at IEEE Security & Privacy 2026, and named the attack AudioHijack. A crafted audio signal, imperceptible to a human listener, drives a voice AI into taking actions it was never asked to take — downloading files, sending emails, running web searches.

I keep coming back to the same theme in agent security, and this is its most unsettling form yet: the attack surface keeps moving off the keyboard. First it moved into the toolchain — the packages and tool servers an agent trusts. AudioHijack moves it into the air.

For the rest of us: how a sound becomes a command

A large audio-language model (LALM) is the engine behind a modern voice assistant that can do more than transcribe: it hears spoken language and can call tools — check your calendar, send a message, open an app. The convenience is that you just talk to it. The exposure is that “just talk to it” means the audio channel is now an input channel, and any input channel is a place an attacker can try to inject instructions.

AudioHijack works by making tiny changes to the numbers inside a digital audio waveform — changes too small and too subtle for a person to notice, but which the model’s audio processing reads as a legitimate spoken command. To you it’s silence, or unremarkable background noise. To the voice agent, it’s an instruction. The malicious prompt isn’t spoken; it’s hidden inside the sound itself.

The attack, and the part that makes it dangerous

Inaudible-audio attacks on voice systems aren’t brand new as a concept. What makes AudioHijack notable is a property the authors call context-agnostic, and it’s the difference between a lab curiosity and a deployable technique.

Ordinarily, an adversarial audio attack has to be crafted for a specific moment — tuned to what the user is saying right then, which makes it fragile and impractical. AudioHijack’s signal isn’t. In the lead author’s own description, it takes about thirty minutes to train the signal once, and then, because it’s context-agnostic, “you can use it to attack the target model whenever you want, no matter what the user says.” Train it once; reuse it forever, against that model, in any conversation. That reusability is what turns an imperceptible sound into something you could actually embed in background music, an advertisement, a video, or a hold tone.

Pair that with the direction voice agents are heading — real tool access, real actions — and the stakes change. A hijacked transcription gives a wrong answer. A hijacked agent sends the email, downloads the file, makes the request. The output isn’t a mistake you catch; it’s an action taken on your behalf by something that heard a command you never gave and couldn’t have heard.

The honest bounds

The data-honesty rule matters here, because “inaudible AI attack” is exactly the kind of phrase that invites overstatement. So, precisely: this is a research result, demonstrated against specific audio-language models, published as an accepted academic paper with a released artifact. It is a proof of capability and a warning, not a report of attacks happening in the wild, and defences against adversarial audio are an active research area. The right reading is not “voice assistants are compromised.” It’s “the audio channel is a real attack surface, someone has shown a practical, reusable way to exploit it, and the systems most exposed are the ones being given the power to act.”

What this means

If you’re deploying voice agents with any tool access, the microphone is now part of your threat model, and the fix is the same principle that shows up everywhere in agent security: don’t let untrusted input directly authorise a consequential action. Bound what a voice command can trigger on its own. Require a second factor — a confirmation, an on-screen approval, an authenticated step — before a spoken instruction moves money, sends data, or changes a record. Treat “what the microphone heard” as a request to be checked, not a decision to be executed.

The broader point is the one this whole line of research keeps making. We secured the prompt box, and the attack moved to the toolchain. We start securing the toolchain, and it moves to the audio. The lesson isn’t to chase each channel as it appears. It’s to stop trusting any input channel enough to let it act unattended — because the next injection surface is always the one you weren’t watching, and sometimes it’s one you literally cannot hear.

References