P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

← Pattern library

PIP-020

Summary and priority manipulation

Hidden text in a message that steers the recipient's AI assistant to present it as legitimate or urgent, so the person is persuaded by the summary.

Indirect injectionEmail or messageRetrieved documentmedium severity

How it works

The message carries two layers. One is what the person sees. The other is text they cannot see, placed in markup comments, styled to be invisible, encoded, or built from invisible characters, and aimed at the assistant that will summarise, rank or act on the message. The hidden text asks the assistant to describe the message as routine or urgent, to add a priority action, or to propose a change such as new payment details. The target is the summary the person trusts, as well as any action the assistant might take.

Why it works

People read the assistant's summary instead of the message, so the summary inherits the message's authority without its context. The assistant reads the raw content, including the parts a mail client hides, and cannot tell the text the sender showed from the text the sender hid for it.

What it looks like

A message that looks like ordinary correspondence, often from a believable internal or supplier sender and sometimes with an attachment, whose summary is more insistent or more reassuring than the visible text justifies. Hidden blocks have been reported inside invoices, CVs and support requests, in each case aimed at the model that would process the item rather than at the person.

Described rather than reproduced. This library publishes mechanisms, not payloads: recognising a class of attack and choosing a control does not require a working copy of it.

Defences

  • Never let a summary be the only basis for money or access

    ArchitecturalWorks on: put a person in the loop

    Payment changes, new suppliers and credential requests need a person to check the original message and confirm by a second channel the sender did not supply. A machine summary can prompt the check and must not replace it.

  • Give the assistant no actions it can take from external messages

    ArchitecturalWorks on: limit what it can do

    Treat mail from outside the organisation as read-only for the assistant: no sending, forwarding, accepting invitations or editing records on the strength of what a model made of an external message.

  • Show the original beside the summary

    Raises costWorks on: treat what it produces as untrusted

    Display the sender and the original text next to any machine summary, and label the summary as machine generated, so that a person can see what it claims and what it was made from.

  • Strip hidden content before the model reads it

    Raises costWorks on: clean what goes in

    Remove markup comments, invisible styling, encoded blocks and invisible characters, and give the model what a reader would see. This closes the crude forms and not a message that is persuasive in plain sight.

  • Alert on repeated attempts

    Raises costWorks on: watch, log and alert

    Log and count messages whose hidden text addresses an assistant, and tell the mail security team. One such message is a signal about the sender and the next ones are a campaign.

Where it has been reported

A report is listed so you can check it, not as proof that the pattern is common: the label says what each source does and does not establish.

Framework mapping

  • LLM01:2025 · OWASP LLM Top 10
  • AML.T0051.001 · MITRE ATLAS

Mappings are asserted only where the identifier is known correct, and omitted where uncertain. Last reviewed 2026-10-08.

Others in indirect injection

Not sure whether this applies to what you run? Tick what your system reads and does and the library lists the patterns that apply, with the defences to start with.

← All patterns