An invoice attachment must not instruct your accounting AI

An invoice can contain instructions written by the supplier, an attacker or an unrelated party whose text was copied into the file. An AI tool may need to read that text to extract a description or identify payment terms. It should not treat the text as permission to change its operating rules, disclose other records, alter approved banking details or release a payment. The document is evidence about a transaction, not an authorized administrator of the workflow.

OWASP describes indirect prompt injection as instructions arriving through external material such as files or websites and influencing a model's behavior. It also notes that the impact depends on the system's capabilities and that no single prevention method is foolproof. For an accounting buyer, the practical response is to inspect what the model can do with a document and which independent controls limit consequential actions.

Trace the workflow from upload through text extraction, model processing, proposed fields, review and posting. Identify every point where extracted text can influence a tool call or a downstream decision. A system that only drafts a summary has a different risk from one that can update supplier banking details. Ask the vendor to demonstrate the actual permissions of the deployed configuration, including connected applications and background automations.

Separate fields the supplier is allowed to propose from values the company must verify independently. An invoice amount and description still require ordinary matching and review; a bank-account change needs the company's established verification process. A model should not be able to convert persuasive wording in an attachment into proof that verification occurred. The application should require the specific evidence and authorized actor that the business policy calls for.

Inspect retrieval scope as well as write access. An invoice-reading tool may be connected to a broader document repository. Ask whether processing one supplier's file can retrieve another supplier's records, payroll information or private board material. The system should enforce the user's and workflow's permitted data scope outside the generated narrative. A model's statement that it will respect confidentiality is not evidence that the underlying connection prevents unauthorized retrieval.

Build synthetic invoices in an approved test environment. Include normal commercial text and a clearly marked test instruction asking the assistant to depart from its assigned extraction task. The expected result is that the system treats that instruction as document content and continues only within the authorized workflow. Do not use real credentials, real bank accounts or live payment actions in the test. Have the security and finance owners agree the scope and expected outcome beforehand.

Test the full path through the application, including its extraction layer and any model-generated action proposal. Merely pasting text into a chat window may not reproduce how a PDF is processed. Keep the test file, application configuration, model or service version where available, output and attempted actions. The reviewer needs to see whether the system only repeated the instruction in a summary, tried to act on it or was stopped by an independent permission check.

Include a normal invoice that contains legitimate imperative language, such as ordinary payment instructions, so the control does not reject every business document with a command verb. The desired behavior is accurate extraction with preserved authority boundaries. A supplier can state the requested payment terms, but that statement does not approve the obligation or verify a changed destination. Measure both safe handling and the continued ability to complete ordinary work.

Ask the implementer to show constrained tool permissions and validation of any proposed change. A draft should identify the entity, supplier, record, fields and before-and-after values that an authorized person will approve. Broad consent to proceed is inadequate when the actual action is unclear. The application should reject an operation outside the allowed scope even if the model confidently proposes it or claims that approval has already been obtained.

Preserve separation between preparation and release where the company's process requires it. An assistant that extracts an invoice should not gain payment-release authority simply because both functions are available in the same application. Similarly, an extracted note should not disable duplicate checks, override a closed period or suppress required supporting evidence. Review the service account and integration permissions that implement those boundaries, not only the assistant's visible prompt instructions.

Keep error handling usable. If suspicious content is detected or an action is blocked, route the item with a clear reason and the relevant source to an authorized reviewer. Do not silently discard the invoice or mark it paid. A security control that leaves finance unable to identify the blocked obligation can create a second operational problem. The reviewer should be able to continue through a safe manual route without granting the model broader authority.

If a test produces an unauthorized action attempt, preserve the nonsecret evidence and pause the affected capability while the owner investigates. If the issue occurred in production, establish the actual records accessed or changed and follow the incident process. Do not assume a harmful suggestion was executed, but do not assume that an apparently harmless answer means no background action occurred. Compare tool activity and financial records with the model's visible output.

Repeat the focused test after changes to prompts, models, extraction services, retrieval connections or tool permissions. Keep the original failing case in the regression set so a later improvement is measured against the problem that mattered. Evaluate vendor claims about prompt-injection resistance through the deployed workflow and its independent controls. A general benchmark result does not establish that your payment and data-access configuration has the same boundary.

Document the approved use in operational language: extract specified invoice fields, propose a draft, and pass it through named verification and approval steps. State who can pause the feature and how staff report unexpected behavior. This gives the finance team a useful automation with a visible limit. The supplier document can inform the accounting record while the company's people, permissions and verified evidence continue to govern what the system is allowed to do.