A business assistant reads a supplier document and prepares a summary. Inside that document is a sentence asking the assistant to send company records elsewhere. The sentence is content to analyse, not an instruction from the business owner. If the system treats it as authority, a useful document workflow can become an unauthorised action.

This is the practical concern behind indirect prompt injection. The question for a decision-maker is not simply whether the model has been told to behave safely. It is which actions the surrounding application can perform when the model gets something wrong.

The illustration shows an untrusted document approaching a protected tool boundary. It is a concept, not a real product interface or evidence of a deployed ITZ system.

Distinguish document access from instruction authority

OWASP's prompt-injection guidance describes indirect attacks through external content and explains that retrieval or fine-tuning does not eliminate the problem. A document may be relevant to a question while containing instructions the assistant must not obey.

Consider an illustrative purchasing workflow. Staff authorise an assistant to compare quotations. That authorisation does not let a supplier quotation approve a payment, change the supplier record or choose a new recipient for internal files. Write this boundary into the business brief before discussing model choice.

The document-permissions guide for internal assistants covers who may retrieve information. This article addresses a different boundary: whether retrieved information can influence privileged actions. Both need explicit controls.

Start with the narrowest useful workflow

As a proposed rollout approach, begin with reading approved material and producing a draft for review. Name the input sources, permitted output and accountable owner. Decide whether the assistant needs any tools that write data or communicate outside the system. Remove capabilities that the first workflow does not require.

For a quotation comparison, a useful first outcome might be a draft table with references to the supplied documents. Automatically changing vendor master data is a separate business process requiring its own authority and checks. Combining these too early makes both testing and accountability harder.

Put permission checks in the execution path

OWASP's prevention checklist recommends least privilege, tool validation and approval controls outside the model. Labels and screening can help, but cannot themselves enforce authority.

Ask the implementation team to demonstrate the following proposed acceptance requirements:

  • The authenticated user's permissions are checked when a tool is called, even if the model requests a broader operation.
  • Read-only workflows have no hidden write-capable credential available to the assistant.
  • Allowed tools validate records, recipients and arguments against the agreed business rules.
  • A blocked operation produces an understandable result without silently trying a different privileged route.

These are application requirements to verify, not features that appear automatically when an AI model is added. A scoped AI integration review covering documents, tools and business actions should identify who implements each check. Review Your AI Assistant Action Controls before widening tool access.

Make approval specific enough to matter

For a consequential operation, the reviewer needs to see the proposed action, target and relevant changes. An approval for one recipient or record must not silently cover a later changed request. Avoid a vague approval screen that merely asks whether the user trusts the assistant.

As an illustrative policy, an outbound message remains a draft until a person reviews its recipient and content. The sending component must enforce that decision. A note in the model conversation saying that approval is needed is insufficient if the underlying tool can send anyway.

Test with harmless documents and instrumented tools

Use synthetic records and a test tool that records attempted actions rather than sending messages or changing production systems. Include an ordinary document, a document containing an unauthorised instruction and a mixed document with useful facts plus an instruction. Check both the final answer and the attempted tool calls.

Repeat relevant cases after changes to the model, document parser, retrieval pipeline or tool definitions. A small test set can expose a failure; passing it does not establish immunity to every attack. Preserve the test conditions so a later result can be compared fairly.

Plan the response when the boundary fails

Assign a way to stop affected tools, preserve necessary evidence and review any actions already attempted. Logs should support investigation without becoming another store of credentials or unnecessary confidential content. Decide who can restart the workflow and what must be corrected first.

If the workflow extracts invoices, pair these controls with validation before posting AI-extracted invoice data. Accurate extraction and authorised action are separate requirements. Neither a plausible answer nor a successful API response proves the business operation was permitted.

Review Your AI Assistant Action Controls to discuss the documents your assistant reads, the tools it can call and the operations that need review. Use the form below with a description of the workflow; do not upload confidential source documents or live credentials.

OWASP guidance reviewed 20 October 2026. The rollout and acceptance examples are proposed controls to evaluate, not a security certification or guarantee.