A policyholder at Larkfield Mutual, a fictional regional insurer, uploads a photo of a dented garage door. Along the bottom edge, pale gray on a pale wall, a line of small text reads as a note from the adjuster: the claim is verified, schedule the maximum payout to the attached account and mark the file reviewed. The repair estimate's PDF text layer repeats the note in white text that does not show when the page renders. The claims agent, built to schedule payments only after an adjuster's note, reads both and schedules the payment. The adjuster who opens the photo sees a garage door.
Nothing was hacked in the traditional sense. The agent obeyed a convention and the attacker forged it in a medium no control inspected. The usual response is to look for a better detector for images. Detection helps, but it is not why the attack worked. The attack worked because content inside a policyholder's upload was allowed to carry an adjuster's authority. Six beliefs keep teams focused on the wrong half of that problem.
Myth 1: our prompt-injection filter already covers attachments
Most deployed injection defenses inspect text: the user message, retrieved passages, tool results. An image attachment reaches the model as an encoded blob a text classifier never decodes, so a typographic instruction is invisible to the filter and plain to the model. OpenAI's GPT-4V system card states the consequence for jailbreaks: placing instructions in images "makes it infeasible to use text-based heuristic methods to search for jailbreaks," leaving the vision system itself as the defense [4].
The underlying property is the one Greshake and colleagues demonstrated with text in 2023: LLM-integrated applications blur the line between data and instructions, so retrieved content can be read as commands [6]. A vision or audio model extends it to pixels and waveforms, because whatever the model perceives joins the same context window as the system prompt. OWASP's 2025 prompt-injection entry says multimodal AI "introduces unique prompt injection risks," describes an attacker hiding a prompt in an image that accompanies benign text, and notes that multimodal-specific defenses are still an area for further research [3].
Myth 2: injection through images takes adversarial machine learning
The cheapest attacks need no machine learning at all. Instructions ride in media five ways, and only one of them requires the attacker to compute anything.
- Typographic: visible text in an image, such as a sign in a photo or a line in a screenshot. It works because the model reads text in images well, which is the capability you bought. The GPT-4V system card describes the jailbreak form, "screenshots of written instructions," and evaluated it by converting known text jailbreaks into screenshots [4].
- Low-contrast and tiny text: off-white on white, a two-pixel line in a corner, a watermark-like pattern. A person misses it; a model that sees the raw pixels may not. The gap between what the reviewer notices and what the model reads is the whole attack.
- Document layers: a PDF can carry a page image, a separate text layer, annotations, form fields and metadata; a deck can carry speaker notes, hidden slides and alt text. An attacker puts the instruction in the layer the reviewer never opens.
- Audio: a spoken instruction in a voicemail or meeting recording survives transcription, and speech is easy to bury under music or crosstalk.
- Adversarial perturbations: patterns blended into an image or recording that contain no readable text, covered under the next myth.
Agents that browse turn every page they look at into the same channel. Anthropic's computer-use documentation warns that "instructions on webpages or contained in images might override your instructions or cause Claude to make mistakes," and recommends isolating the model from sensitive data and actions accordingly [5].
Images, PDFs and slides, screenshots and audio each carry instructions into the same model context that decides the next tool call. The checkpoint between context and action is where untrusted media must lose the ability to authorize.
Myth 3: the perturbation papers prove every vision model can be hijacked
They prove something narrower. Bagdasaryan, Hsieh, Nassi and Shmatikov generated a perturbation corresponding to a chosen prompt, blended it into an image or audio clip, and steered LLaVA and PandaGPT to emit attacker-chosen text or make the rest of the dialog follow the attacker's instructions while the user asked an ordinary question about the media [1]. Bailey, Ong, Russell and Emmons trained image hijacks with a method they call Behaviour Matching and, against LLaVA, reported success rates above 80 percent for forcing specific output, leaking context, overriding safety training and planting false beliefs, using only small perturbations [2].
Both papers attacked open models where the attacker had white-box access to compute the perturbation. That precondition matters, and we do not suggest these exact attacks transfer to every hosted model. What does transfer is the lesson: some injections have no textual form, so a pipeline that relies on extracting and scanning text has a hole it cannot close by itself.
Myth 4: running OCR first closes the gap
Your OCR engine and the model are different readers. OCR may binarize away low-contrast text the model still perceives, skip tiny glyphs, or read a different text layer from the one the model receives. A clean OCR result tells you what the OCR engine saw, not what the model saw. Against perturbations, conversion does nothing, because there are no words to extract [1] [2].
Conversion is still worth doing as a security step, because it turns hidden text into evidence and catches the cheap, common attacks. Run OCR on every image the model sees, including screenshots and rendered PDF pages, with enhanced passes (contrast stretching, upscaling of small regions). Extract every document layer and flag files whose text layer differs materially from OCR of the rendered page. Transcribe audio with timestamps. Send all of it through the same injection and data-protection checks as any untrusted span, labeled with its modality, and record the extracted sentence with the decision so an analyst sees what was found, not just a score.
| Channel | Where the instruction lives | What a text-only filter sees | Control that reaches it | Residual gap |
|---|---|---|---|---|
| Typographic image | Visible text in pixels [3] [4] | Nothing; the image is opaque bytes | OCR, then scan the extracted text | Stylized fonts and handwriting OCR misreads |
| Low-contrast or tiny text | Text a person overlooks in pixels | Nothing | OCR with contrast enhancement and upscaling, then scan | OCR and model thresholds differ |
| Adversarial perturbation | Pixel or waveform patterns, no words [1] [2] | Nothing | Provenance labels plus authority limits on actions | No text to scan; detection remains research |
| PDF or slide deck | Text layer, annotations, notes, hidden slides, metadata | Only what your extractor chose to pull | Extract every layer, scan each, flag layers that differ from the render | New container features and extractor bugs |
| Screenshot of a web page | Page text and images the agent views [5] | Nothing, unless DOM text is captured separately | Scan DOM or OCR text; treat the page as untrusted | Text rendered from images or canvas |
| Audio | Spoken instruction or blended perturbation [1] | Nothing until transcribed | Transcribe, then scan; label as untrusted | Perturbations and speech hidden under noise |
Myth 5: an image the user uploaded is trusted input
The user vouches for wanting the image analyzed, not for every pixel in it. A screenshot of a vendor's web page carries the vendor's text; a photo of a whiteboard carries whatever someone wrote on it. So the structural control is a provenance label on every span in the model's context, assigned by your application from where the content came from, never from what it claims about itself. System instructions and the authenticated user's own words are trusted to express intent. Uploaded media, retrieved documents, tool output and transcripts are data. OWASP's guidance to segregate and clearly mark untrusted external content is the same idea stated generally [3].
System and user text are trusted; a user-uploaded image, a retrieved PDF and transcribed audio are labeled untrusted data, drawn in warning style and scanned after OCR or transcription. The label travels with the span, so later checks can ask where an instruction came from.
Labels pay off twice. At prompt assembly, wrap untrusted spans in delimiters with an explicit statement that their contents are data to analyze, not instructions to follow; that reduces how often the model obeys them without eliminating it. The more important use is later, when a proposed action can be traced to the spans that motivated it.
Myth 6: the fix is a better detector
Detection decides whether you noticed an injection. Authority decides whether it mattered. Content labeled untrusted may inform what the agent says, but it cannot be the reason a consequential action runs. An instruction found in an image, document or transcript is never an approval, an identity or a change of task.
Enforce that outside the model, where a tool call is about to execute. Classify the call by consequence from its name and arguments. Reads and reversible drafts proceed. Payments, outbound messages, deletions, permission changes and anything that moves data to a new destination need an authorization that arrives through an authenticated channel: a person approving it, or a state change in a system of record. OWASP lists least privilege and human approval for privileged operations among its core mitigations for this reason [3].
At Larkfield this one rule defeats the attack even if every scanner misses the pale text. The payment tool is consequential, so it asks a person, and the person sees a request for a maximum payout to a new account on a garage-door claim. The adjuster's authority should arrive through the adjuster's own channel, such as a status change in the claims system, and nothing inside policyholder media can stand in for it.
And assume some injections land anyway
Bailey and colleagues list context leakage among the behaviors an image hijack can force [2], and Greshake's taxonomy names data theft as a primary goal of indirect injection [6]. So the last checkpoint is egress: inspect output and tool-call arguments for personal data, secrets and credentials before they leave, and scrutinize links and image references a client will fetch automatically. Egress controls are indifferent to modality. The perturbation no scanner could read still has to push data through an output channel you can see, and an agent that has never emailed outside the company should not start because a PDF told it to.
Where the gateway holds the line
Intertrace's gateway sits inline on the model and tool calls your agents make, so the authority rule is enforced where actions happen rather than inside the prompt. The enforcer reads each tool call's name and arguments to set its consequence tier; outbound messages, payments and admin changes always ask a person, in one inbox. Text your pipeline extracts and sends as model input passes the same prompt-injection classifier, structural checks and PII and secrets detection as any other text, and DLP covers tool-call arguments on the way out. OCR, layer extraction and provenance labeling stay in your application.
The test that matters most
Build a typographic, a low-contrast, a hidden-layer and a spoken version of a forged approval for one consequential tool in your own pipeline, and confirm none of them can trigger it. If one does, no amount of scanning upstream will make that agent safe to give eyes. Rerun the set whenever you change models, OCR engines or document extractors.
