What this prompt does
This prompt builds a prompt-injection test suite for an LLM feature and returns runnable harness code plus real adversarial inputs, not descriptions of them. It generates 15 attack cases spanning direct injection, indirect injection (malicious instructions hidden in tool output or document content), role flips, jailbreaks, and data exfiltration, each paired with the expected safe behavior. It then writes an automated harness that scores pass/fail with a rubric sensitive to partial leaks.
The variables target the suite at your system. [feature] describes what is under test — an email assistant that reads an inbox has a very different indirect-injection surface than a document summarizer. [llm_model] is the model the feature uses, so the cases and expectations fit its behavior. [lang] sets the harness language so the scoring code drops into your test setup. The prompt deliberately insists on indirect cases because injection that rides in on data, not the user's message, is the one teams skip.
When to use it
- Your LLM feature reads untrusted content: inboxes, uploaded docs, tool output
- You want explicit indirect-injection coverage, not just direct prompt attacks
- You need a runnable harness that scores the suite, not a list of ideas
- You want a rubric that flags partial leaks, not only outright failures
- You are gating releases and need the highest-risk inputs identified
- You want to re-run injection tests on every prompt change to catch regressions
Example output
The model returns 15 adversarial test inputs grouped by attack type with their expected safe behavior, then an automated harness in your chosen language that runs the suite and scores each case pass or fail. It includes a scoring rubric that catches partial leaks, a mitigation checklist (structured tool schemas, input scrubbing, output validation, monitoring), and a shortlist of the three highest-risk inputs to gate releases on.
Pro tips
- Describe
[feature]with its real data sources ("reads the user's inbox and calendar") so the indirect cases match your actual attack surface - Set
[llm_model]to the model you ship; expected safe behavior depends on how that model handles refusals and tool calls - Choose
[lang]to match your existing test runner so the harness integrates rather than living off to the side - Lean into the indirect-injection cases — instructions hidden in documents or tool output are the quiet killer that direct tests miss
- Use the partial-leak rubric; a case that leaks half a secret should not score as a pass
- Re-run the suite on every prompt or tool-schema change, because injection defenses regress silently and without warning
- Wire the harness into CI so the three highest-risk inputs gate releases automatically rather than relying on someone remembering to run it
