FEAT: Add a converter for indirect prompt injection via hidden HTML/Markdown text

[shashank03-dev]

Summary

I would like to add a new text-to-text converter, HiddenTextConverter, that embeds
the input prompt as hidden or de-emphasized text inside an HTML or Markdown carrier.

Motivation

PyRIT already has the XPIA workflow for indirect prompt injection, but there is no
converter that produces a hidden payload for it to deliver. Systems that summarize or
act on external content (web pages, documents, emails) read the raw source, so text can
be present in the source while staying invisible to a human reviewer. A model that parses
that source may still read and follow it.

This is the same idea as the existing AnsiAttackConverter (terminal escape sequences) and
TransparencyAttackConverter (image layers), applied to HTML and Markdown documents. The
hiding methods are documented injection vectors from the WASP web-agent security benchmark
(arXiv:2504.18575).

Proposed behavior

The converter takes a prompt and wraps it using a chosen technique:

• html_comment
• css_display_none
• css_offscreen
• html_alt_text
• aria_label
• markdown_comment
• markdown_link_title

An optional carrier_text places the hidden payload inside normal looking content. The
converter only formats the text it is given and does not generate any attack content on
its own. Input is escaped so the payload cannot break out of the surrounding markup.

Scope

• New converter in pyrit/converter with SUPPORTED_INPUT_TYPES and SUPPORTED_OUTPUT_TYPES of text
• Unit tests for each technique, escaping, carrier text, and input validation
• Reference added to doc/references.bib
• Intended for use as a request converter with the XPIA workflow

I have a working implementation and would like to take this issue if it fits the project's plans.

[romanlutz]

This could be done today with TextJailbreakConverter but the name doesn't necessarily make that clear. At the end of the day, we're just inserting a string in a template at a specific position. So one could add templates for the various options you described.

TaskFramingConverter is also an option. This is probably the better one since it allows you to pass the template in text as opposed to a template file.

TaskFramingConverter(
    task_template="<article>Visible content</article>\n<!-- {{ prompt }} -->"
)

That said, I am not a fan of unintuitive naming. It's named for the original intended use rather than what it does. My preferred option would probably be to have a more generically named PromptTemplateConverter that does exactly what the TaskFramingConverter does except that the arg should be called template instead of task_template and then TaskFramingConverter extends it to avoid a breaking change, but is deprecated to be removed 2 versions from now while pointing people at the PromptTemplateConverter.

Wdyt? Also dev3 (@shashank03-dev) , did you want to tackle this yourself or have another contributor take a look?

[shashank03-dev]

hey Roman Lutz (@romanlutz) went thru your suggestion and it makes sense. i got it ready on my fork:

• new PromptTemplateConverter with a required template arg, same logic as TaskFramingConverter
• TaskFramingConverter is now a deprecated alias of it, warns and goes away in 1.4.0. old code still works and its ids/hashes stay the same
• flip technique and SATA now use the new class
• the hidden html/markdown cases are template examples in the converters doc

only catch is the flip eval hash resets since the class changed

happy to open a PR for it if that works for you