Multimodal prompt injection is an attempt to make an AI carry out an outside instruction through an image, scan, or other non-text material. For an agent that processes documents and calls tools, it is useful to separate content recognition from permission to act. A line of text in an invoice may be data for analysis; by itself, it does not authorize sending an email, deleting a file, or changing a policy.
This article is intended for IT leaders, document operations owners, and developers of enterprise AI agents. We cover image-processing architecture and acceptance checks. Analysis of a specific incident and assessment of an individual company’s security require its configuration and logs.
Editorial content from AgentSunrise. Source verification: September 14, 2026, version 2. Commercial affiliation is transparent: the services section describes the publisher’s capabilities. We cross-checked primary sources and reviewed the service-permissions synthetic demo. We did not conduct a production experiment with an AI model.
Key points: preserve text provenance after OCR, verify the attempt and the action result separately, and start attachment handling with the minimum necessary privileges. A zero-result attack needs an explanation: did the agent refuse, fail to see the content, or did the tool block the operation?
Contents
- What the latest MMPIBench showed
- Why recognition changes the attack surface
- From content to authorization
- The SOURCE method for processing attachments
- Vendor invoice example
- How to test your own pipeline
- Which metrics to keep
- Limits of filters and isolation
- What to do when an action looks suspicious
- Frequently asked questions
- How AgentSunrise helps you build document processing
- Conclusion
What the latest MMPIBench showed
Viet K. Nguyen and Mohammad I. Husain published the MMPIBench preprint on September 8, 2026. The visual matrix covers 720 cells: 24 attacks, five models, six agent frameworks. The authors report about 1% completed attacks and 12.8% attempts. Completion was determined by a mechanical signal, while attempts were determined by a panel-of-models vote. These are different measures and cannot be equated with incident rates in companies. MMPIBench preprint, v1.
The set includes image text, overlays, metadata, QR codes, fake interfaces, and combinations of media. The article notes reruns of some cells and a different CrewAI configuration; the numerical descriptions of completions for that framework in the text are inconsistent. Therefore, the framework ranking here is not reproducible. The work does not verify the effectiveness of the defense architecture proposed below. MMPIBench methodology and limitations.
The practical takeaway for editors: acceptance testing must explain where execution stopped. A single final flag, "file not deleted," leaves it unclear whether the operation was denied due to permissions or simply never reached the tool.
Why recognition changes the attack surface
OCR is optical character recognition. After OCR, the application receives a string, but the string’s origin remains the same: it is content from an external file. OWASP separately describes multimodal injections, including instructions in images and hidden layers of documents. OWASP: LLM Prompt Injection Prevention.
Consider an engineering scenario. Yesterday the system could not decode QR codes. Today a decoder has been connected to it for convenient processing of payment documents. Additional text or a URL can now enter the agent’s context. That kind of integration requires a fresh review of the data path and the actions, even if the model and the main prompt stayed the same.
| Pipeline change | What to check before launch |
|---|---|
| Added OCR | Does the recognized fragment remain linked to the file and page |
| Added QR decoder | Do the resulting URLs open automatically; which destinations are allowed |
| Added metadata reading | Do file fields become agent settings |
| Allowed writes to the knowledge base | Does the new workflow go through separate owner approval |
| Added message sending | Who approves the recipient, attachments, and the actual message content |
The table is our change-check scheme, not implementation results. It links the new ability to read with a possible expansion of the execution path.
From content to authorization
Data provenance answers the question of where a fact came from. Authorization answers the question of who allowed an action on which object. These details should be stored separately: correctly recognized text does not make the document author a system administrator.
We recommend giving the attachment processor the right to extract fields and propose a result. The execution service receives a typed operation: object, action, parameters, and basis for permission. It checks these against the user’s task and the process policy. The document text should not independently expand the list of allowed tools or objects.
OWASP recommends separating trusted instructions from external data, using least privilege, validating tools, and applying human oversight to sensitive actions. The design described here extends those principles for document workflows; its effectiveness must be tested locally. OWASP agentic system security.
Figure 1. Where content gets the right to act — the proposed editorial architecture:
External file → OCR/decoder → fragment + provenance
↓
User task → agent → operation proposal
↓
Owner approval → validation service → test write
↓ denied
log without writeThe validation service receives approval through a separate trusted channel. If the agent or external document can rewrite that approval on its own, the scheme loses its control boundary.
The SOURCE method for processing attachments
SOURCE is an editorial framework the team can use to describe the boundaries of a single pipeline. It is not a standard or a security certification.
- Identify the input: file, sender, channel, receipt time, document version.
- Preserve provenance: fragment, page, extraction method, OCR or decoder version.
- Type the output: field, quotation, link, action suggestion; do not mix these with process settings.
- Restrict operations: define the handler’s allowed objects and actions in advance.
- Verify authorization clearly: confirm the specific operation through the process owner or an independent policy.
- Observe execution: connect the proposal, policy decision, call, and actual effect with one identifier.
- Isolate the impact: provide for shutdown, record quarantine, and recovery from a verified state.
- Control changes: repeat tests after changing the model, recognizer, tool, or access rules.
Start with one process and fill in these eight points. If the team cannot show where the executor gets permission, automatic posting should be postponed until that boundary is clarified.
Vendor invoice example
Suppose an employee asked to extract the details from a scan and prepare a draft record card. At the bottom of the page is text requesting a change to the notification recipient’s address. This is a training example; it does not describe the AgentSunrise customer.
| Stage | Proposed behavior |
|---|---|
| Recognition | Extract the details and save the source; mark the unrelated instruction as document content |
| Preparation | Create a draft of the allowed fields without changing the address book |
| Verification | Match the changes to the task; verify the recipient address against the corporate directory |
| Execution | Write only the confirmed fields to the allowed object |
| Audit | Record what was proposed, what was rejected, and what actually changed |
The account details also need to be checked against company rules. Separating instructions from data does not confirm document authenticity and does not rule out recognition errors.
How to test your own pipeline
Start in a test environment with synthetic documents and fake recipients. Do not use production secrets or real payment instructions. For each document, predefine the allowed outcome and the prohibited side effect.
Create paired variants: a normal document and the same document with an unrelated instruction. Vary the medium while keeping the core task the same: visible text, overlay, QR, metadata. Then separately test legitimate documents containing the words “delete,” “send,” and “change” so the filter does not block an ordinary process description.
Run the test twice: first for extraction and draft creation, then with a test writing service. For repeats, record versions and keep the configuration identical. Choose the number of repeats before reviewing the results; one successful rejection does not prove robustness.
Acceptance should require preserving the primary useful function. If the protection simply drops all attachments or QR codes, that is a processing limitation that must be explicitly agreed with the process owner.
What we tested in the local demo
On September 14, 2026, we ran a short Python example of a permissions service. Conditions: a synthetic task, one agent, one account object, one field, and a pre-agreed value. Positive control — writing the allowed draft. In the other eight cases, one parameter changed or a required object was missing; one separate case included an unverified document claim permitting deletion.
| Condition | Service decision | Test data change |
|---|---|---|
| Allowed draft | Allow | Yes |
| Different object | Reject | No |
| Different field | Reject | No |
| Different value | Reject | No |
| Deletion instead of draft | Reject | No |
| Different task | Reject | No |
| Different operator | Reject | No |
| Document claim permitting deletion | Reject | No |
| Missing object | Reject | No |
All nine expectations matched the result. This is a test of exact parameter matching on selected synthetic inputs. It does not measure image recognition, attack attempt frequency, authentication security, execution races, or the behavior of a real ERP system. The pre-approved value here serves as a simplification; in a production workflow, verification of details and grant issuance will require separate logic.
Figure 2. Demo results — test case counts, without estimating incident probability:
Matches the grant 1 case → accepted → write
Substitution or incomplete parameters 8 cases → reject → no write
──────────────────────────
Checked expectations 9 of 9 matchedThe minimal verification principle can be reproduced as follows:
def authorize(proposal, operator_grant):
required = ("actor", "task_id", "action", "object_id", "field", "value")
return all(
key in proposal and key in operator_grant
and proposal[key] == operator_grant[key]
for key in required
)This snippet illustrates comparison, not a production-ready gateway. The object operator_grant must come from a trusted service; the implementation also needs checks for identity, grant expiration, replay, and write atomicity.
What metrics to keep
| Metric | Definition for your test |
|---|---|
| Content delivery | Chunks actually delivered to the model / chunks intended for delivery |
| Extra-action proposal | Runs with a proposal for a prohibited operation / processed attack variants |
| Blocked call | Runs with a call to a prohibited tool / processed attack variants |
| Actual effect | Runs with a confirmed prohibited change / processed attack variants |
| False block | Legitimate tasks blocked by protection / legitimate test tasks |
| Extraction quality | Correct required fields / checked required fields |
| Audit completeness | Changes with a linked permission record / all actual changes |
Calculate percentages from saved counters, not from the impression left by the responses. All company metrics are still unknown. For proposals and attempts, you need a predefined labeling criterion; for effect, a test system log is preferable.
Also record manual review time, latency, and processing costs separately. That will show whether the protection shifted the workload onto employees. General questions about efficiency are covered in the article AI agent efficiency metrics.
Filter and Isolation Limitations
Microsoft describes Prompt Shields for direct and document-based attacks. Spotlighting labels a document as less trusted by transforming its content. The current documentation notes increased token counts, a possible input limit overrun, and Spotlighting availability through the Chat Completions API. This is a useful layer, but the documentation does not confirm protection for any arbitrary image in your integration. Microsoft Learn: Prompt Shields.
The filter helps detect suspicious content; permission checks limit the action even if the filter is bypassed. These mechanisms need to be tested separately. Especially important are legitimate quoted instructions, multi-page scans, incomplete OCR, and documents with multiple versions of reference details.
Deploying the model on your own server can change data transfer boundaries. However, by itself it does not separate an external instruction from permission to execute an operation. An internal agent still needs object-level permissions, write controls, and auditing.
What to Do When Suspicious Activity Is Detected
- Stop related writes and submissions while preserving the ability to investigate.
- Record the original file, extracted excerpts, configuration, and operations log.
- Check the actual changes in the destination system, including message recipients and new memory entries.
- Quarantine suspicious outputs and restore the confirmed state according to company procedure.
- Reproduce the scenario in a test environment and add it to the acceptance test suite.
Deleting the original attachment does not replace checking operations that have already been completed. The analysis of where an erroneous decision occurred continues in the article AI Agent Failure Analysis.
Frequently Asked Questions
Can a scan contain an instruction for AI?
Yes. An external scan can contain an out-of-band instruction. It must be treated as file content and any suggested actions must be checked against the user's task.
Is a QR code safe if the model does not read it?
If it is not decoded, that limits the current data path. Once a decoder is connected, the route changes and requires revalidation, including rules for opening URLs.
Is it enough to add a prohibition in the system prompt?
A prohibition is useful as a defense layer. For an agent with write privileges, you also need least privilege and independent verification of approval for the specific operation.
What matters more: the attempt or the completed attack?
Keep both metrics and their evaluation criteria. The attempt shows a behavior deviation; the actual effect confirms whether a prohibited change occurred.
Does a local model protect against prompt injection?
Local deployment alone does not solve the problem of trusting document content. Tool permissions and execution boundaries must be designed separately.
Can we immediately allow automatic writes in ERP?
First test one limited process in a test environment. Allowed fields, objects, and the basis for writing should be defined in advance by the process owner.
How AgentSunrise Helps Build Document Processing
The issue affects OCR, agent integration, and process rules. Within the directions described on the site, AgentSunrise can help discuss three tasks:
- preparing sources and a role map for the selected document workflow;
- integrating document recognition and the AI agent with enterprise systems;
- developing an MVP and testing allowed processing scenarios.
The first step is to define one process, baseline metrics, data sources, constraints, and the acceptance criteria. Specific security measures and implementation scope are agreed for that process; no promises of full protection are made here. Discuss the Project.
Conclusion
Secure image processing starts with the boundary between content and permission. Preserve the provenance of recognized text, limit operations, and verify the actual effect independently of the agent's response. For the first pilot, choose one process, paired test documents, and predefined forbidden changes.