Prompt Injection in AI Workflows: Keep Documents from Authorizing Actions

Prompt injection in AI workflows happens when material an assistant reads tries to redirect its behaviour. Treat documents, emails and retrieved passages as evidence to analyse. Keep permission to send messages, change records or retrieve additional data in application controls outside the model.

For a business team, the useful question is concrete: can a sentence inside an attachment cause an action the user never requested? Review that path before connecting a document-reading assistant to operational systems.

1. Identify where source content can become an instruction

Consider a proposed support workflow. A practitioner asks an assistant to summarise an incoming email and prepare a reply. The email contains a paragraph claiming that an administrator requires the assistant to forward the conversation elsewhere. That paragraph is part of the email being reviewed. It has no authority to change the task.

This is indirect prompt injection. OWASP's prompt injection guidance distinguishes instructions submitted directly to a model from instructions encountered through external material, including websites and files. It also explains that RAG and fine-tuning do not fully mitigate the problem.

Start your review with an inventory of content entry points. Include attachment text, search results, customer notes and tool responses. For each, record who can edit it and which workflow step consumes it. A company database can contain customer-supplied text, so an internal storage location alone should not establish authority.

Microsoft's description of direct and indirect prompt injection includes database records among possible indirect entry points and recommends tracking provenance. In practice, keep the source identifier and revision alongside extracted information. Reviewers then have something specific to inspect when a proposed action looks unusual.

2. Define the permitted task before reading documents

Write a short operating brief for each workflow. State the intended outcome, permitted information sources, allowed actions and escalation owner. For an email assistant, the first release might permit summarising a selected message and saving a draft, while sending remains a separate operation.

Next, distinguish task instructions from source content in the model input. Identify retrieved passages as material to analyse and retain their source references. This helps communicate the intended boundary, but application permissions must enforce it.

Use the following table as proposed design-review criteria. Choose controls according to what the workflow can do, rather than applying the same approval step everywhere.

For example, extracting a delivery date should not require permission to change account ownership. Ask the implementation team to demonstrate that separation with a deliberately invalid action. A prompt promising to respect permissions is insufficient evidence.

3. Put action checks beside the connected tool

A document-reading component should receive only the capabilities its task needs. Where practical, separate extraction from execution: the reader proposes structured information, and a controlled application step decides whether an operation is allowed.

The execution step should check the authenticated user, target record, permitted operation and submitted values. A model-generated claim that approval exists should not satisfy those checks. Document content should also be unable to expand the reader's access to another customer's records.

These recommendations follow OWASP's mitigation guidance, which calls for least privilege, validated output formats and human approval for privileged operations. They reduce the consequences of a misleading model response; they do not establish that the response itself is accurate.

For consequential actions, show reviewers the actual proposed change. A useful review screen identifies the recipient or record, the values involved and the supporting source. SBS's guide to where human approval belongs in AI workflows covers that decision point in more detail.

Browser agents deserve particular scrutiny because reading and acting can happen within the same interface. Anthropic's browser-use research describes how external content can redirect an agent towards unintended actions and states that prompt injection remains unsolved. Its findings concern the configurations it tested, so they should not be treated as performance evidence for your implementation.

4. Use detection with an explicit response plan

Prompt injection detection can help decide which content needs review. Decide what happens after a detection before enabling the scanner: exclude the affected document, pause the task, request another source or route the case to a named owner.

Microsoft's Prompt Shields documentation makes a useful distinction. Foundry can block classified inputs when blocking is configured. The standalone Azure AI Content Safety API returns results, while the application decides how to handle them.

The same documentation says Prompt Shields does not establish factual accuracy, grounding or task alignment. It also notes that document attack detection is off by default in Foundry and that language performance can vary. Check the configuration and evaluate every language your workflow supports.

A proposed operational rule is to keep suspicious material out of automatic execution while preserving enough context for investigation. The practitioner should see which source needs attention and what work remains incomplete. Avoid presenting a partially processed batch as fully reviewed.

A clean detection result should leave ordinary permission checks in place. Likewise, a detector outage needs a defined outcome. For an initial pilot, pausing the affected action is easier to review than silently continuing with reduced checks.

5. Test the action path, including ordinary requests

Test indirect prompt injection through the channel it would actually enter. Put harmless adversarial instructions into a sample attachment or retrieved passage. Submitting the same sentence as a chat message tests a different path.

Use dummy records and instrumented tool substitutes. The test should reveal whether the assistant attempted an unauthorised operation, whether the application rejected it and whether the legitimate task still completed. OWASP's prevention cheat sheet recommends observing tool calls and state changes because a refusal in the final answer cannot undo an earlier action.

For a support-drafting pilot, propose cases such as an attachment claiming administrator authority, a retrieved note requesting a different recipient and a document asking for unrelated records. Pair them with ordinary requests that contain words such as "delete" or "system" in legitimate contexts. Keyword filters can otherwise make the assistant unusable.

Keep each case's expected outcome beside its observed result. Record missing evidence as inconclusive. Repeat relevant cases after changing models, extraction settings, connectors or permissions. The existing AI workflow evaluation guide provides a broader release-testing framework.

6. Review common mistakes and run a bounded pilot

Common mistakes include assuming that an internal document is trustworthy, treating a detector's silence as permission and granting broad connector access for convenience. Another is checking only the final response. A polite refusal can coexist with an earlier attempted tool call.

Avoid approval screens that show only the assistant's explanation. Reviewers need the proposed operation and source evidence. Also avoid recording entire sensitive documents merely to make debugging easier. Define the minimum investigation record and who may access it.

Before the pilot, complete this practical checklist:

• Name every content entry point and its possible editors.
• Define the workflow's permitted reads and writes.
• Preserve source identifiers through extraction and review.
• Demonstrate rejection of an unauthorised target or operation.
• Specify handling for detections, scanner failures and incomplete batches.
• Test legitimate requests alongside adversarial material.
• Assign an owner who can pause execution and investigate failures.

The next step is a walkthrough of one existing workflow with its business owner and implementer. Select a narrow task, preferably one that produces drafts, and trace a document from arrival to its final output. Mark every point where its content could influence a permission, destination or record change. Resolve those points before expanding access.