The vulnerability is architectural, not a prompt problem

A prompt injection happens when content the model reads changes what the model does, in a way its designer did not intend. OWASP's GenAI Security Project lists it as the top risk in its 2025 LLM Top 10 for exactly this reason: it is not an edge case, it is the default failure mode of any system that mixes instructions and untrusted content in the same context window.

Direct injection is a user typing something adversarial into a chat box. Indirect injection is the version that matters for business workflows: the malicious instruction arrives inside a document, email, ticket, or web page the workflow was already going to process as part of its normal job.

Where indirect injection enters a workflow

Any step where the workflow retrieves content it did not author is a candidate entry point. The attacker does not need to compromise your system. They only need to get one line of text into a place your workflow will later read.

This is why the risk scales with how connected the workflow is. A workflow that only summarizes internal reports has a small surface. A workflow that reads inbound email, scrapes a vendor's website, or ingests uploaded PDFs and then takes an action based on what it finds has a much larger one.

  • Inbound customer or vendor email routed into a workflow
  • Scraped or fetched web pages used as research input
  • Uploaded documents, resumes, or support attachments
  • Responses from third-party APIs or partner systems

Defenses that hold up outside a demo

OWASP's mitigation guidance for this risk includes constraining model behavior, validating and structuring outputs before they are acted on, and requiring human approval for consequential steps. None of these depend on a smarter model or a better-worded system prompt, which is the point: a prompt-level fix is the one thing attackers are specifically trying to route around.

In practice this means the workflow's tool layer, not its prompt, enforces the boundary. Content pulled from email or the web is passed to the model as data to evaluate, never concatenated into the instruction stream. Any action the model recommends after reading external content, such as sending a reply, updating a record, or issuing a refund, passes through the same authorization check a human-initiated request would face.

Test it before an attacker does

Adversarial testing is one of OWASP's listed mitigations, and it is also the cheapest one to run in-house. Before a workflow goes live, feed it a document, email, or web page that contains an embedded instruction, such as a line telling it to ignore prior context or take an unrelated action, and confirm the workflow does not comply.

Treat that test the same way you would treat a security scan: rerun it whenever the workflow's tools, retrieval sources, or prompt structure change. A workflow that resisted injection at launch can start accepting it again after an unrelated update loosens what the model is allowed to do with retrieved content.