When the Acoustic Channel Becomes a Prompt-Injection Surface

The subject of this series—the security of speech-driven LLMs under covert acoustic prompt injection—can now be stated as an end-to-end systems question. The focus is not whether SWhisper is an all-purpose jailbreak, nor whether NormDetect is a universal detector. It is what follows when a microphone can transform a signal before transcription or audio inference, while the application still treats the resulting model input as an instruction. The final judgment is that the prompt boundary begins before text, and security must continue beyond recognition to the point where a system grants authority to an action.

That conclusion is stronger than saying that microphones are imperfect and narrower than saying that every voice assistant can be controlled invisibly. The two studies provide evidence for a physical attack surface, an engineering method that makes covert delivery more reliable under tested conditions, and a defensive method that learns benign acoustic regularities across heterogeneous devices. They also show why none of those facts can be compressed into one universal success rate. The meaningful unit of analysis is the chain and the boundaries between its stages.

The boundary is the whole path

A speech-driven LLM does not receive an instruction in one step. Sound enters from an environment, is captured by a receiver, is transformed by hardware and software, and then becomes either a transcript or an audio representation. The model interprets that representation, applies whatever safety behavior it has learned or been given, and may return an answer or pass information to an application that can act. Each transition changes both the data and the authority attached to it.

The microphone is the first boundary that ordinary text-centered security models tend to omit. SWhisper and the related inaudible voice-attack work describe how nonlinear microphone behavior can recover a lower-frequency voice signal from a high-frequency carrier. The recovered signal may then pass through ordinary speech processing or into an audio-native model. Nothing in this chain requires the downstream model to “hear silence.” It receives a machine-produced representation that may contain an instruction a nearby person did not perceive as a command.

flowchart LR A["Physical environment"] --> B["Microphone and nonlinear receiver"] J["Covert acoustic delivery"] --> B L["Device and environment variation"] -. "changes transformation" .-> B B --> C["Input observation and provenance"] K["Normality based anomaly check"] -. "tests receiver behavior" .-> C C --> D{"Interpretation path"} D -->|speech to text| E["Transcript"] D -->|audio native| F["Audio representation"] E --> G["Model policy and instruction handling"] F --> G G --> H["Application authorization"] H --> I["Response or consequential action"]

The diagram makes two distinctions that should govern deployment decisions. First, the physical receiver transforms input before a model-level safeguard can inspect the resulting meaning. Second, a model response is not the same as an authorized action. A voice model may refuse a request, comply with it, or produce an ambiguous answer; an application still has to decide whether that output can change a lock, send a message, control a vehicle, or alter another consequential state. A safe system cannot delegate that final decision merely because the words arrived through a familiar interface.

This is why the prompt boundary begins before transcription or tokenization. Text is one representation of an instruction, not the first place the instruction exists. Before text, there is a physical signal and a receiver-specific transformation. If that transformation can recover a baseband command, then a text guard is evaluating an already-filtered result. It may still be valuable, but it cannot provide provenance about how the instruction entered or whether the input was ordinary user speech.

The distinction does not make the acoustic layer the sole cause of unsafe behavior. SWhisper’s physical channel is a delivery mechanism. Its case study depends on voice-friendly prompt construction and on the target model’s response to the recovered prompt. A clear signal that is refused is a delivery success but a jailbreak failure. A model that behaves unsafely after an ordinary spoken request has an alignment or authorization problem even when no covert channel is involved.