Image preprocessing belongs inside the approval boundary

A person cannot meaningfully approve an image-driven action by inspecting a representation that hides what the model receives. Image preprocessing belongs inside the approval boundary. The design also needs to restrict the actions available after interpretation, because seeing the transformed image cannot establish that every instruction embedded in it will be recognized or rejected.

Looking back from November 2026, Trail of Bits’ research published on 21 August 2025 exposed a consequential mismatch: downscaling could reveal instructions absent from the image as viewed at its original resolution. Researchers reported this across several named systems. Their findings establish behavior in the investigated setups, rather than universal susceptibility of every multimodal model or current deployment.

The demonstrated authority matters

In the Gemini CLI demonstration, the researchers used a Zapier MCP configuration with trust=True, allowing tool calls without user confirmation. They reported calendar-data exfiltration through that setup, with no preview of the transformed image available to the user. These conditions belong beside the outcome. The example is not evidence that an explicit confirmation dialog was universally defeated, or that every installation grants the same authority.

The product lesson is broader than that particular integration. A workflow may show an uploaded original to a person, then send a resized derivative to a model. If the person’s decision authorizes the model to use tools, the decision concerns more than whether the original looks ordinary. It also concerns which representation the system interprets and which operations that interpretation may trigger.

This is an approval-design problem even when the preprocessing is routine and well intentioned. Thumbnailing, cropping or other transformations can sit between upload and interpretation. A review screen that names only the upload has left an important stage implicit. The relevant boundary follows the input actually used for the consequential decision, rather than the file that happened to enter the product first.

Preserve the relationship between views

A proposed defensive interface should distinguish the original from the model-facing derivative. Explain which transformation produced the latter and associate both with the same submitted item. When the provider performs additional undisclosed processing, say that the visible derivative covers only the application-controlled stage. Claiming exact parity without access to the remaining stages would create another misleading assurance.

The record should identify the representation reviewed and the representation submitted. If processing changes after approval, the application should decide whether approval remains valid. A person who inspected one derivative has not necessarily approved a different crop generated later. This is a proposed product requirement, not a report that a named system currently implements such binding.

Showing both images can improve the reviewer’s evidence, but it also creates an interface burden. A small preview may conceal details in either version. The person needs a usable way to inspect relevant content and understand why there are two views. Merely placing another tiny thumbnail beside the first would satisfy a superficial design specification without resolving the decision problem.

Approval should name the action

Consider an illustrative assistant that extracts dates from a customer image. Reading an image and creating a draft calendar entry are different permissions from sending existing calendar data elsewhere. The useful authority for the first task can remain narrow. An unfamiliar instruction in the image should not acquire broader authority merely because the upload came from an authorized user.

A proposed approval can therefore name the operation, destination and data involved. If the assistant wants to send a message, the reviewer should see what will be sent and to whom. If it wants to alter a record, the approval should concern that change. Reviewing input content and approving a tool’s concrete effect answer different questions; neither should silently stand in for the other.

The same reasoning applies to integrations that bundle many operations behind one connector. A user may need access to a calendar without needing every calendar-related tool in every task. Restrict tools to the job and place consequential effects behind appropriate checks. This is a design proposal, not a claim that narrower tools remove all prompt injection or make arbitrary image interpretation safe.

A matching preview is insufficient

The strongest objection is that a faithful preview still leaves the human facing ambiguous or deceptive content. The reviewer may miss an instruction, misunderstand it or approve an action for an unrelated reason. Additional provider transformations may also remain unavailable for inspection. Preview parity cannot be promoted into a complete security guarantee.

That objection supports layered responsibility. Visibility addresses a particular information mismatch. Narrow authority limits the consequences of a mistaken interpretation. Action-specific confirmation allows a person to judge the actual proposed effect. Each mechanism has a different job and different failure cases. A team should say which one supports each claim instead of presenting a general “human approved” label as proof of safety.

For acceptance planning, use benign representative images and inspect the documented processing path and proposed effects. Include changed derivatives and unavailable preprocessing information. These are suggested defensive checks; no attack images, payloads, exploits or model API tests were generated or executed for this article. The historical research supplies the observation, while the interface requirements here are recommendations derived from it.

In custom software development, ask what the reviewer actually saw before asking whether approval existed. Preserve the connection to the model-facing input, then constrain the actions that input can influence. The August findings make that connection an explicit engineering responsibility. A visible original alone cannot carry the promise that the person reviewed the evidence used by the system.