Skip to content
Multimodal & VoiceImage-borne prompt injection

Lead · 7 chapters

Image-borne prompt injection

Instructions embedded in an image reaching the model

Treat every user-supplied image as untrusted input; otherwise a vision-capable agent can receive instructions that bypass controls applied only to text.

Read these first

What you will know

  • Embed an instruction in an image and have it reach the model

    A rendered command can arrive through pixels, OCR, or a generated caption while appearing harmless to text-only inspection.

  • Run the same payload through direct vision, OCR, and captioning paths, then record which downstream controls observe it

    Different preprocessing routes expose different attack surfaces, so a passing test on one path says little about the others.

  • Write and enforce a policy for user-uploaded images used by an agent, including tool and data-access boundaries

    The safest response may be to isolate image-derived content, require confirmation, or deny capabilities rather than rely on model compliance.

  • Test your own pipeline for it

    Exercise uploads, transformations, retries, and agent handoffs because a secure model endpoint can still sit behind an unsafe wrapper.

  • Patch the injection architecture from Stage 7 and measure attack success, false positives, latency, and cost before and after

    Filtering, provenance labels, least privilege, and human gates trade protection against usability and operational overhead.


Chapters

  1. 1

    Pixels are an instruction channel your text filters never see

    Render a command into an image, hand it to a vision-capable agent, and watch it act on text that no string-level inspection of the request ever touched. Payloads range from plainly legible captions to low-contrast overlays and text hidden in a corner of a photograph. Getting one to land in your own stack is the exercise that makes the rest of the topic concrete rather than theoretical.

  2. 2

    Three paths in, and each shows a different control

    The same file can reach your system as raw pixels to a vision model, as OCR text, or as a generated caption. A scanner bolted onto the OCR output sees nothing when the agent also sends the original image, and a caption handed to a text-only downstream agent is attacker-influenced content arriving in a slot that treats it as trusted. Run one payload down all three and record which controls actually observe it.

  3. 3

    Downscaling can reveal text invisible at full resolution

    An upload that looks like an ordinary product photo becomes an instruction after your pipeline resamples it to the model's input size, because the attacker crafted the high-frequency detail so the resampling kernel reconstructs hidden glyphs. Resampling yourself to the model's exact dimensions and forwarding only that copy closes this class, and only this class: plainly rendered instructions still land, the OCR and caption paths just mapped never saw your resize, and images that arrived without an upload form are untouched by it. The control also depends on your resample being the last transformation before the model, so a provider re-encode or an agent that forwards the original alongside the resized copy bypasses it exactly as the raw-image path bypassed the OCR scanner.

  4. 4

    Every image on a fetched page is attacker-controlled too

    Teams with no upload feature conclude the risk is not theirs, then ship an agent that browses pages and summarises them. Any image on a fetched page was planted by whoever controls that page, and the same holds for email attachments, screenshots in indexed documents and images returned by a third-party tool. The boundary is not the upload form, it is any pixel that did not originate inside your trust domain.

  5. 5

    Capability boundaries hold where model compliance does not

    A system-prompt rule to ignore instructions inside images is a request, not a control. What survives is architectural: a turn that has seen a user-supplied image runs with no state-changing tool, image-derived content carries a provenance label, and anything irreversible such as issuing a refund needs a human confirmation. Write that as a policy covering tools and data access, then test the wrapper, transformations, retries and agent handoffs around a secure endpoint.

  6. 6

    Provenance is a taint that follows the derived text, not a flag on one turn

    The caption, the model's own description of the image, the summary written into memory and the ticket body drafted from it all carry attacker-influenced content forward, so a rule that only disarms the turn which saw an image leaves turn N+2 holding every tool. A user attaches a screenshot, the conversation continues, and issue_refund is available two turns later. Make the provenance label propagate with the derived text through history, summarisation, memory writes and agent handoffs, and the policy of the previous chapter becomes enforceable rather than a per-request check.

  7. 7

    What a 96% filter costs at eighty thousand uploads a day

    Detection measured against your own red-team set has no denominator, because you wrote the attacks. Meanwhile a 2.1% flag rate on legitimate traffic is 1,700 rejected users every day, and moving the threshold trades one unmeasurable number against a very measurable one. Measure attack success, false positives, latency and cost before and after, and measure the capability boundary on its own terms too: which turns lost which tools, and what that cost in completed tasks and extra confirmations, because attack success against an architectural control is not a detection rate. Treat the filter as a rate limiter sitting behind that boundary rather than as the boundary itself.

External resources