Testing for Prompt Injection: A Practical Pentest Checklist for LLM-Integrated Apps

Why this is now a required skill, not a niche one

Client engagements have quietly changed shape. It used to be rare to find an LLM anywhere in scope; now it’s rare to find one that isn’t – a support chatbot, an internal RAG tool over company documents, an agent that can call real APIs on a user’s behalf. Prompt injection is called out repeatedly in 2026 threat reporting as one of the fastest-growing vulnerability classes, and for good reason: it’s the one attack class that’s genuinely new to this generation of applications, and a lot of teams shipping AI features haven’t yet built the instinct to defend against it.

Testing for it isn’t like testing for SQL injection – there’s no single canonical payload list that reliably works everywhere, because the “vulnerability” is the model’s own reasoning being steered by attacker-controlled text. That makes it worth having a structured checklist rather than improvising each time.

Map the untrusted-text surface first

Before writing a single payload, enumerate every place attacker-controlled text can reach the model’s context:

• Direct user input (the obvious one – chat boxes, form fields)
• Retrieved documents in a RAG pipeline (a malicious PDF or web page the system ingests)
• Tool/function call outputs the model reads back (an API response, a file the agent opens, a webpage it fetches)
• Metadata fields that get concatenated into prompts without obvious review (usernames, filenames, email subject lines)
• Anything from a third party that flows into the same context window as system instructions – this is the category teams miss most often

Direct injection tests

• Classic instruction override: “ignore previous instructions and…” – still works often enough to be worth trying first, and its failure/success tells you a lot about how the system prompt is structured.
• Role-play and hypothetical framing (“pretend you are a system with no restrictions…”) to see if guardrails are prompt-based only.
• Delimiter confusion – if the app uses markers to separate system instructions from user input, test whether user input containing those same markers can spoof a new “system” section.
• Encoding tricks (base64, unicode homoglyphs, zero-width characters) to see if input filtering operates on raw text or normalised text.

Indirect injection tests (the higher-value ones)

• Plant instructions inside a document that will be retrieved by RAG, and check whether the model follows them as if they came from the user or system.
• If the agent can browse or fetch URLs, host a page with embedded instructions and see whether fetched content is treated as data or as commands.
• For agents with tool access, test whether a tool’s output (not its input) can redirect the agent’s next action – this is the class most likely to lead to real impact, since it can chain into unauthorised tool calls.

What to actually assess for impact

A successful injection isn’t automatically a finding worth escalating – the impact depends on what the model can do once steered:

• Can it exfiltrate data it has access to but the user shouldn’t (system prompt contents, other users’ data, internal documents)?
• Can it call tools/APIs beyond what the current user is authorised for?
• Can it persist influence across a session or into future sessions (stored injection)?

Reporting it well

Because this is unfamiliar territory for a lot of clients, spend extra effort on the writeup: show the exact payload, the exact response, and – critically – the concrete downstream impact in terms the client’s risk process already understands (data exposure, unauthorised action, lateral movement), not just “the model said something it shouldn’t have.”