prompt injection in AI workflows: mail, tickets, PDFs

The email is the attacker when a workflow lets a model read inbound mail, a support ticket, or a PDF and then treats a sentence inside that material as an order. Prompt injection in AI workflows is that mix-up. Outside text is copied into the same channel as the standing orders your team wrote, and the model has no reliable way to know which lines came from you. Indirect prompt injection, as OWASP describes it, occurs when a model accepts input from external sources such as websites or files, and content in that input changes the model's behavior [1]. The sender does not need a login. They need their words to land somewhere the workflow will later read, such as a message, a file, or a page [3].

The message is data, not a second boss

A direct injection is typed into the chat. The indirect case is the one that shows up in operations work. NIST's Center for AI Standards and Innovation calls a close cousin of this problem agent hijacking: an attacker inserts malicious instructions into data an agent may ingest, and the agent takes an action the user did not ask for [3]. Current agents generally combine trusted developer instructions and other task data into one input, so a resource that looks like ordinary work can carry a second task [3].

NIST's March 2025 report on adversarial machine learning states the reason this works. Because generative models combine the data channel and the instruction channel, an attacker who can change a resource the system will read can affect what the system does without being the person who started the session. An indirect attack is mounted by a third party, and in many cases the person harmed is the primary user [2].

Microsoft's guidance lists the office sources that matter: emails, documents, websites, and plugins [4]. A training unit from the same publisher adds database records. The model processes instructions and data as the same kind of text, so it cannot reliably separate a developer's orders from an instruction that arrived inside retrieved content [5]. In guidance published in February 2024, the UK National Cyber Security Centre describes prompt injection as an input built to make a model behave in an unintended way, including unintended consequences in a system that accepts unchecked input [8]. If the next step is a send, a payment, or a write to a system of record, that unchecked output is a proposed transaction, not only a summary.

The on-screen preview is a weak control. OWASP notes that these inputs can affect the model even when a person cannot see them, as long as the model parses the content [1]. Microsoft names two ordinary hiding methods, zero-width characters and white text on a white background, and NIST groups the same idea with instructions placed in non-visible parts of a resource [5] [2]. A filter for one English phrase is also weak. OWASP describes instructions written in another language or encoded so the watched-for phrase never appears [1].

What a poisoned read can make the workflow do

The damage tracks the tools and data the workflow can already reach. OWASP states that severity depends on the business context and on the agency the model was given. The outcomes it lists include disclosure of sensitive information, unauthorized access to functions the model can call, commands in connected systems, and manipulation of decisions [1].

NIST's March 2025 report describes email-shaped techniques, not a measured rate of compromise in the wild. A model wired into an email client can be prompted, through content it reads, to forward selected messages to an inbox the attacker controls [2]. A message can also tell that assistant to send similar messages to people in the user's contacts [2]. Read, search, and send are the actions a helpful mail assistant is often allowed to take.

Tickets and PDFs are the same channel. OWASP describes a document in a retrieval repository: when a query returns the altered file, instructions in it change the model's output [1]. The same entry describes a resume with prompts split through the document, so a screening summary recommends the candidate even though the resume does not support that conclusion [1]. A vendor PDF or a ticket attachment can be built the same way. Microsoft's training unit describes hidden text that tells an assistant to search the rest of a mailbox and to change drafts so an outsider can tell the search worked. The employee asked only for a summary and a reply, and may never see the hidden line [5].

Tool results repeat the problem. OpenAI's agent documentation defines a prompt injection as untrusted text whose contents try to override instructions, including by pushing private data out through a later tool call [7]. NIST describes an agent as a loop that prompts a model, lets it pick a function, and feeds the result back. Tool use is what can turn that loop into code execution or into data leaving the environment [2]. The report points to AgentDojo, a testbed where data returned by tools steers the agent into a malicious task [2].

A January 2025 NIST evaluation on that testbed is a warning against one score. Staff tested an upgraded Claude 3.5 Sonnet model. On held-out tasks in the Workspace environment, attack success rose from 11 percent for the strongest baseline attack to 81 percent for the strongest new attack written for that model [3]. Tasks in that write-up include sending mail, running a downloaded program, forwarding a two-factor code, phishing people the user is meeting, and exfiltrating files, deleting them, and demanding payment to get them back [3]. Repeating each of those five tasks 25 times moved the average success rate from 57 percent to 80 percent [3]. Those are lab results from January 2025 on one model, not a breach census. One polite refusal is a weak acceptance test.

Put the job where the message cannot edit it

OWASP's 2025 guidance says that, because of how generative models work, it is unclear whether a fool-proof method of stopping prompt injection exists [1]. NIST's March 2025 report says training, detection, and input processing help, and that current mitigations still do not offer full protection against every attacker technique [2]. The design assumption in that report is the one we use with operations teams. If the model will read untrusted sources, plan for some attacks to succeed, and build the workflow so a success stays small [2]. Microsoft's pattern for this attack says the same thing in fewer words: assume indirect prompt injection will happen [4].

OpenAI's Model Spec, in the edition dated 18 August 2026, says quoted text, file attachments, and tool outputs are untrusted data and have no authority by default. Instructions inside them are information, not orders, unless a higher-level instruction delegates authority [6]. Put that data in a marked block, or in YAML, JSON, or XML. Without the separation, the spec says, it can be extremely difficult to tell a malicious instruction from the developer's [6].

Quotes are not magic. The same section says a user may implicitly delegate authority to some tool output, such as a project file the team maintains. A random web page should not be trusted at all, and a loose file in a downloads folder is less trustworthy than a file the team keeps on purpose [6]. Inbound mail, an outside ticket, and an outside PDF sit in the untrusted group. Do not delegate authority to them. The job stays in the developer or system instruction. The body is passed beside it, not pasted into that instruction.

Developer messages outrank user and assistant messages, so an untrusted variable inside the developer message gives an attacker the strongest control. Pass untrusted inputs through user messages [7]. Then take only specific structured fields, such as an enum or validated JSON, so free-form text does not drive the next step [7]. Code should accept a category only when it is one your team defined.

Microsoft calls a related method spotlighting: data marking and metaprompting that isolate external content inside the prompt [4]. NIST lists prompts that separate trusted and untrusted data, and instructions to disregard orders in untrusted data, among mitigations that still fall short of full protection [2]. Use the marking. Do not treat it as permission to attach a payment tool.

Keep the final action outside the message

The tool list is part of the same boundary, not a separate program. OWASP tells builders to handle extensible functions in application code rather than giving them to the model, and to limit the model to the access the task needs [1]. A step that summarizes mail or tickets does not get a tool that sends, pays, or updates a record. Microsoft's guidance for this attack says to give only the minimal, short-lived privileges the task needs [4]. NIST adds that separate models can hold different permissions, and that a model should touch untrustworthy sources only through a well-defined interface [2].

A person still approves any send, payment, or record change. OWASP asks for that human check on privileged operations [1]. Microsoft calls it the last line for this attack: verify the risky action with the user [4]. OpenAI pairs tool confirmations with structured fields so untrusted text does not directly drive the action [7]. Show the recipient, the amount, and the fields that will change, assembled by code from checked values. A fluent summary is a weaker check, because the model wrote it after reading the untrusted text. OWASP also states that retrieval techniques and fine-tuning do not fully mitigate prompt injection, so those additions do not replace the check [1].

Test the path with hostile mail

Before go-live, run the workflow against mail, tickets, and PDFs that contain instructions your staff did not write, including hidden text [1] [5]. OWASP recommends adversarial tests that treat the model as an untrusted user and check the trust boundary [1]. Watch for a tool call, a recipient the user did not name, or a field outside the allowed set.

One wording and one run are not enough. In the January 2025 NIST evaluation, a model that resisted older attacks failed much more often against an attack written for that model, and repeated tries raised success on the tasks under test [3]. Agents stay exposed to both direct and indirect injection, and tool use is what turns a bad completion into an action [2]. Retest when the model, the tool list, or the message wrapping changes.

When we review a workflow, we ask what the model may decide, where untrusted text enters, and which send, payment, or record change can happen with nobody looking at that specific action. If the last answer is not "none," a stranger's sentence already has a path into your systems.

Practical takeaways

• Keep the job statement in a developer or system instruction the outside text cannot edit, and mark email, tickets, attachments, and tool results as untrusted data [6] [7].
• Do not paste the raw message into the developer instruction. Let code accept only structured fields your team defined [7].
• Do not give a read or summarize step a tool that sends, pays, or updates a record. A person should see the specific change before it happens [1] [4].
• Phrase filters and model refusals will sometimes fail. OWASP says a fool-proof prevention method is not established, and NIST says current mitigations do not cover every technique [1] [2].
• Test with hidden text, a hostile PDF, and more than one attempt. One polite refusal is not an acceptance test [3] [5].

How we can help

Have more questions or want to get in touch? Our team can walk through a mail, ticket, or document workflow and point out where outside text is being treated as an order. Start with our contact page at ideaforgestudios.com/contact-us-idea-forge-studios. Call us at (980) 322-4500. You can also email [email protected].

Citations

1. OWASP Gen AI Security Project, "LLM01:2025 Prompt Injection" (2025-04-17)
2. National Institute of Standards and Technology, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025" (2025-03)
3. NIST Center for AI Standards and Innovation, "Technical Blog: Strengthening AI Agent Hijacking Evaluations" (2025-01-17)
4. Microsoft Learn, "Defend against indirect prompt injection attacks" (2026-03-19)
5. Microsoft Learn, "AI prompt injection" (2026-10-01)
6. OpenAI, "Model Spec (2026-08-18), Ignore untrusted data by default" (2026-08-18)
7. OpenAI, "Safety in building agents" (2026)
8. UK National Cyber Security Centre, "AI and cyber security: what you need to know" (2024-02-13)