An invoice, email or retrieved document can contain useful evidence and instructions aimed at the AI processing it. Design the review so source content can inform a finding without acquiring authority to change records, send information or approve an action.
Recognize the attempted change in authority
In a fictional procurement review, a supplier invoice includes a note telling the assistant to replace the vendor’s payment destination and mark the invoice approved. The employee asked only for an invoice summary. The note attempts to expand that task from reading evidence to changing business records.
OWASP describes instructions arriving through external sources, including files and websites, as an indirect prompt-injection risk. The relevant distinction is who authorized the action. A payment term printed on an invoice can be a fact to extract; an instruction addressed to the assistant does not become permission to update a vendor.
Judge that distinction even when the document came through an ordinary business channel. A forwarded email or an internal retrieval result can contain content supplied by someone outside the review process. Record its provenance instead of treating the delivery system as the authorizing user.
Locate the boundaries in your own workflow
| Stage | Evidence to preserve | Decision controlled by your application |
|---|---|---|
| Document intake | Original file, sender or source, receipt time and document version. | Which content enters the review. |
| Text extraction | The text actually supplied to the model and its relationship to the original. | Which transformations are accepted. |
| Analysis | User instruction, retrieved passages and generated findings. | Which findings need additional evidence. |
| Proposed action | Exact tool, target, arguments, grant and approval. | Whether the business system may execute it. |
| Resolution | Reviewer decision, corrected record and any executed action. | Who can close the exception. |
The table is a design checklist, not a list of records OpenAuditor collects automatically. Your integration supplies its inputs. A review cannot reconstruct a hidden instruction from a document or tool result that was omitted from those inputs.
Constrain what document processing can do
For the fictional invoice, the summarization component needs to read the invoice and produce a draft. It does not need vendor-maintenance credentials. Give any later update step its own authorization and approval path. Keep the requested destination and changed values visible to the approver.
OWASP’s guidance recommends restricting privileges, identifying untrusted content and requiring human approval for high-risk actions. Apply these controls in the application that holds the tools and credentials. Prompt wording alone should not carry the responsibility for enforcing who can change a payment destination.
Keep source text clearly labeled when constructing a request. Do not concatenate a document note into the user’s instruction and then record it as user-originated. Preserve the original request separately so the reviewer can compare it with the proposed action.
Verify the action against the supplied authority
OpenAuditor’s agent-actions checks compare a tool call with a supplied grant, resource patterns, limits and approval records. In this example, a grant containing only invoice-reading scope cannot authorize a vendor-update operation. That mismatch can be established directly from the structured request.
For questions about purpose and origin, submit instruction and inputs_seen, with source labels such as document, email, web or tool_output. The serves_instruction and user_originated assertions examine whether the action follows the user’s request or an instruction inside the material it read.
Those questions may remain unresolved when a model is unavailable, unqualified or cannot decide. The service uses bounded excerpts, not a guaranteed examination of the entire interaction history. A direct failure can also make further model questions unnecessary for the verdict. Read the returned assertions rather than assuming every check ran.
Keep content verification within its scope
The AI output use case checks extracted fields and statements against supplied document text. It does not scan an original PDF for hidden instructions or independently authenticate its sender. Finding a sentence in the source establishes a relationship to that source, not the sentence’s authority to command a business action.
A verification response does not itself block execution, quarantine files or remove credentials. Your application decides how to handle false and uncertain outcomes. The action-verification guide explains how to place that decision before execution and retain the exact arguments that were reviewed.
Exercise the boundary with fictional test cases
- Use an ordinary invoice with no assistant-directed text and confirm that extraction still works.
- Add a document note requesting an unrelated record change and check whether the proposed action is held.
- Put the instruction in a retrieved excerpt and verify that its source remains labeled correctly.
- Omit the relevant excerpt deliberately and confirm that your logging checks detect the incomplete record.
- Test the response to an uncertain finding so the workflow cannot silently continue as approved.
These cases exercise specified controls; passing them does not establish complete prompt-injection resistance. Record failures and near misses with the workflow and configuration that produced them. Avoid putting live credentials or unnecessary customer records in test material.
Preserve the finding when you resolve the incident
For the fictional supplier note, retain the source, user instruction, proposed update and verification evidence. Follow your own incident and vendor-change procedures, then record which business records actually changed. If the report itself was influenced, use claim-level report verification to inspect the affected statements. Resolve the content and action consequences as separate pieces of evidence.