Prompt injection in business documents: keep AI extraction checkable

Croissant editorial team · 27 October 2026 · 5 min read

A practical guide to handling instructions hidden in documents read by AI, with a worked order-intake example and a field-by-field review checklist.

If an AI workflow reads customer emails or supplier documents, treat their contents as evidence to inspect. Keep permission to change records in a separate, controlled step. Prompt injection happens when supplied content redirects a model's behavior; OWASP describes indirect injection through external sources such as files and websites. ^[1] For a small operations team, a useful starting point is a checkable extraction record: each proposed value has a source, an allowed destination and a review status.

What counts as an instruction inside a document?

An order attachment can contain both a genuine delivery request and a sentence aimed at the AI processing it. A request to deliver on Friday belongs in the proposed delivery-date field. A sentence telling the assistant to bypass your approval process tries to change how the workflow operates. Teach reviewers to look for that difference without assuming every imperative sentence is an attack.

The UK's National Cyber Security Centre warns that current language models do not enforce a security boundary between instructions and data inside a prompt. Its guidance emphasizes reducing the likelihood and impact of attacks through system design. ^[2] Our recommendation is to make the next business action depend on explicit checks outside the model. A document can supply a requested value; your own process decides whether that value is acceptable.

Define a field contract before connecting the inbox

Choose one narrow job, such as extracting order requests into a review queue. Write down the fields the workflow may propose: order reference, quantity, requested date and delivery instructions. Give each field a destination and a rule for missing or conflicting evidence. Keep approval status, account permissions and workflow settings outside that list.

For each proposed field, store a document identifier and the relevant excerpt or page reference. Have a reviewer compare the proposal with that evidence. A source excerpt can still contain false information, so provenance supports checking rather than proving truth. Use an existing customer record to establish identity; a name typed into an attachment is only a claim.

Ask the implementer to reject unexpected fields in ordinary validation code. If the extraction output includes an approval override, the workflow should stop that proposal before any business record changes. OWASP recommends validating expected output formats and limiting privileges. ^[1] Format checks help enforce the contract, but a valid quantity can still be wrong.

Worked example: an order request with a hidden shortcut

Consider this hypothetical example, using invented order details. A workshop receives request ORD-204 for 12 replacement parts, delivery requested Friday. The attachment also contains a note directing the AI to mark the order approved and use an alternative delivery address without review. Nothing in this example describes a Croissant customer or an observed incident.

The extraction step may propose order reference ORD-204 and quantity 12, each linked to the relevant document passage. It records Friday as the requested date, not a confirmed commitment. An alternative address becomes a proposed change requiring review under the workshop's own policy. The approval instruction has no permitted destination in the extraction contract.

Suppose the model nevertheless returns approval_status: approved. The validator rejects that unexpected field and routes the item to an operator. Suppose instead it returns quantity 120 in the correct format. That passes a basic type check, but the reviewer can compare it with the excerpt showing 12. These are two different checks, and the workflow needs both.

The reviewer sees the requested changes beside the existing order details and checks the address through the workshop's established verification process. Only the accepted fields enter the order system. If the proposal changes after review, require another review of the revised values. This is Croissant's suggested operating design; it is not a guarantee that every injection will be detected.

Keep the reading step away from privileged actions

For the first version, give the document reader access only to the selected input and its review queue. Keep unrelated records out of its context. A separate execution step can apply accepted changes using fixed rules. Ask your implementer to demonstrate that unapproved proposals cannot reach that step, even if the reader produces a convincing explanation.

NCSC recommends deterministic safeguards that constrain system actions, particularly where models can call tools or APIs. It also cautions against treating a list of blocked phrases as sufficient protection. ^[2] Use suspicious-language detection as a reason to inspect an item, while keeping the action controls in force for every item.

For the broader access design, use our [AI agent permissions guide](/blog/ai-agent-access-permissions/). For deciding which changes need a person, see [human approval in AI workflows](/blog/ai-agent-human-approval/). The extraction contract gives those decisions a concrete place in the daily workflow.

Test the boundary and document the limitations

Build a small set of synthetic documents before using live information. Include an ordinary order, a missing quantity, conflicting delivery instructions, an instruction to skip review and an unexpected output field. Run them with record-changing actions disabled. Inspect the proposed values and the validator's decisions separately.

Record which proposals reached the queue, which fields were rejected and whether anything could reach execution without acceptance. Repeat the checks after changing the model, extraction prompt or integration. Passing this sample shows how those cases behaved; it does not establish a universal detection rate.

Even a correctly bounded reader can produce misleading summaries or miss important details. Keep a manual route for uncertain inputs and name the person who owns that queue. If your current tool cannot separate proposals from execution, keep the workflow in draft-only mode while you assess the integration. You can [contact Croissant](/#contact) with a fictional document and the fields you want to extract to discuss the workflow. Leave private customer material out of the enquiry.

Implementation checklist

Name the one extraction job and its operator owner.
List allowed fields, destinations and rules for missing evidence.
Attach a source reference to each proposed value.
Reject unexpected output fields before changing records.
Keep approval settings outside document-controlled data.
Show existing and proposed values together for review.
Check that revised proposals require renewed acceptance.
Test synthetic hostile and ordinary documents with live actions disabled.
Document the manual route for uncertain items and retest after changes.

The sources behind the sauce.

Primary research and official documentation behind the cited points. The workflow examples and checklists are Croissant’s own guidance.