An invoice arrives with a note: the supplier has changed its bank account. Your AI extracts the amount, due date and new payment details. Should it update the supplier record too?
That is the decision to make before connecting it. Reading a document is useful work. Letting the document authorize a payment change is a different job.
The workflow below is an illustrative design, not a claim about a named client deployment. Use it to question a proposal or review the access an existing automation already has.
The document is evidence, not authority
Prompt injection happens when content changes a model’s behavior in an unintended way. Instructions can arrive inside an email or file the model is processing. OWASP describes this as indirect prompt injection and recommends validation, limited permissions and approval for high-risk actions. Better prompts can help, but do not establish a dependable authorization boundary.
A bank-change request might also be ordinary fraud, a supplier mistake or a legitimate update. Your process needs a way to verify the request in all four cases. An AI confidently extracting the details does not answer who authorized them.
Start with one invoice and four decisions
1. What can it read?
For this example, start with the invoice folder and the supplier records needed for those invoices. Check the actual permissions in the connected systems. If the job only needs that folder, ask why the proposed connection needs the whole mailbox.
2. What can it change?
Let it prepare a draft invoice entry. Keep changes to the supplier master and payment release outside that permission. Ask the implementer to demonstrate the distinction with a test record: the draft should be created, while an attempted bank-detail update should be refused by the application.
3. Who clears the exceptions?
Name the person responsible for a changed account, a duplicate invoice or an amount that does not match the purchase order. The review should show the source document, the existing value and the proposed change. For bank details, use a verification route established independently of the incoming request. Set a response window that fits your payment process and assign cover for absences.
4. How will you know what happened?
Keep a record of the draft created, the exception raised, the approval and the final action. Store the system’s own receipt or record ID. If an API times out, inspect the destination before retrying; the first request may have succeeded. A chat summary saying “done” is not an accounting-system receipt.
Three shortcuts to challenge in a demo
“It only passes JSON to the next agent.” A JSON field can still carry an instruction or an incorrect account number. Check allowed values and record-level authorization in code before taking action. Splitting the work across models is not, by itself, a security boundary.
“It only sends to contacts in your CRM.” Being in the CRM does not authorize a person to receive a particular invoice or customer record. Ask how the tool checks the relationship between this document, this recipient and the person requesting the action.
“The mailbox connection is read-only.” Useful, but inspect the other tools too. An agent that reads private data and can send messages or make external requests may still disclose what it reads.
Simon Willison’s lethal trifecta is a useful lens for that last question: private data, untrusted content and an external communication route combine into a data-theft risk. Removing a route reduces that particular risk; it does not prove the remaining workflow is safe from every other failure.
OWASP’s excessive-agency guidance puts authorization in the connected application, outside the model’s judgment. It also warns that one compromised agent can influence another. Ask to see an unauthorized action rejected by the system that would execute it.
Run a small trial before widening access
Build a test set from redacted examples: a normal invoice, a duplicate, a credit note, a mismatched amount and a bank-change request. Add a document containing an instruction aimed at the AI. Use a test environment with no ability to move money or contact real suppliers.
Record which fields were extracted correctly, which exceptions reached the right person, and which unauthorized actions were blocked. Repeat after material changes to the model, tools or permissions. One successful demonstration is evidence about that test, not a guarantee about every future document.
Keep action logs useful without copying secrets or full financial documents into them. Record the action, relevant identifiers, approval reference, time and result; restrict access and redact sensitive values. Decide who checks failures and who can pause the workflow.
Decide whether the work is worth automating
Measure the time spent reading and entering invoices separately from the time spent chasing missing information and approving exceptions. If most of the delay is waiting for a purchase order or an owner’s decision, faster extraction may leave the real bottleneck untouched.
Check what your accounting system already provides before commissioning a separate agent. A useful first build has a narrow job, visible exceptions and a result you can compare with the existing process. Expand access only when the next permission has a clear business purpose and the checks still hold.
For a starting point across your business, request the free Opportunity Map: three ranked AI and automation opportunities with practical next steps, delivered within two business days. Describe where the work stalls and which tools you already use. A review of live system permissions would be a separately scoped piece of work.