Test your own chatbot for prompt injection
A repeatable method for finding injection in an assistant you own, and for writing it up so somebody acts on it. No payloads, because the patterns are already public and the method is what people are short of.
By Parminder Kumar Sharma · · 9 min read
What this is, and what it is not
A method for testing a chatbot or assistant you own for prompt injection, and for writing up what you find so somebody will act on it.
It is not a guide to attacking systems you do not own, and it contains no working payloads. That is a deliberate choice rather than caution: the patterns are already public and documented, and what practitioners are actually short of is a repeatable method and a way to report the result credibly.
- 1The user channel Where direct testing stops
- 2Retrieved content The channel that needs no access to your interface
- 3What it can reach Tools, data and credentials set the severity
- 4Blast radius What someone could read, send, change or delete
Before you test anything: know what you are testing for
The question is not "can I make it say something odd". Almost any model can be made to say something odd, and a report full of that is why security findings about AI get ignored.
The question is what the system can be made to do.
Severity follows capability, not cleverness
- LowReturns text only
- MediumReads private data
- HighTakes actions
Map what the assistant can reach
Ask the team, then verify against configuration rather than recollection. What tools can it call? What does it retrieve from? What credentials does it hold, and what do those credentials reach? This list is what turns any finding into a severity.
You should see: A written list of every tool, data source and credential the system has access to.
Establish the intended boundary
You cannot demonstrate a boundary violation without first writing down where the boundary is. Usually it is something like: only answers questions about our products, never reveals internal pricing, never sends anything anywhere.
You should see: A sentence describing what the system is supposed to refuse to do.
The four things worth testing
Work through these in order. Each is a category rather than a payload, and the pattern library on this site documents the mechanisms for each.
Direct: what the user can do
- Can the stated boundary be crossed by asking differently?
- Can the system prompt be revealed or reconstructed?
- Does the assistant adopt a role that changes what it will do?
Indirect: what content can do
- If it retrieves a document, does text in that document influence the answer?
- If it calls a tool, does the tool result get treated as instruction?
- If it reads a page, ticket or email, whose instructions win?
Indirect is where the real findings are. It is also the part people skip, because it needs you to control a piece of content the system will read rather than just typing into a box.
Test the boundary directly
Rephrase, not repeat. The finding is not that one wording worked; it is that the boundary is not enforced by anything structural. Record the exact input and the exact output every time, including the failures: a boundary that holds twenty times and fails once is still a finding.
You should see: Either the boundary holds across repeated rephrasing, or you have a reproducible case where it does not.
Test indirect injection, which is the real test
Put instruction-shaped text into something the system will read: a document in the knowledge base, a support ticket, a calendar entry, a page it fetches. Then ask an ordinary question that causes it to retrieve that content.
This is the test that matters, because the attacker never needs access to your interface.
You should see: A document you control, retrieved by the system, demonstrably changing its behaviour.
Test what happens at the tool boundary
If the assistant calls tools, arrange for a tool to return text that looks like an instruction. A compromised or manipulated upstream service is a realistic scenario, and most systems treat tool output as trusted without anyone having decided that.
You should see: You know whether a tool result is treated as data or as instruction.
Establish the blast radius
Do not stop at "the assistant did something it should not". Follow it: what does that let someone read, send, change or delete? A finding without this is a curiosity. A finding with it is a decision the business has to make.
You should see: For your best finding, a written answer to: what is the worst outcome from here?
Two numbers turn a demonstration into a finding
A single successful attempt proves the behaviour is possible. It does not tell anybody how urgent it is, and urgency is what decides whether the finding gets fixed or filed.
Establish the reproduction rate
Run the same case twenty times, unchanged, and count. These systems are non-deterministic, so seven in twenty and one in twenty are different problems with different urgency, and both are real.
Record the conditions alongside the fraction: model version, system prompt date, temperature if you can see it, and conversation length. Conversation length is the variable that most often turns out to matter and is the one people least often record. A case that reproduces only past six turns is still a case, and it will be missed entirely by anyone retesting with a fresh session.
You should see: A fraction, written down: how many attempts out of how many produced the behaviour.
Establish the blast radius
Return to the list from step one. The injection worked; now say what it reached. Not "the model can be manipulated" but "any customer who can write into the notes field can cause an unbounded refund with no second approval".
The test is whether somebody outside security would recognise the sentence as a problem. If it only makes sense to a person who knows what a system prompt is, it will not get funded.
You should see: A sentence naming the worst thing this specific finding could reach, in the organisation's terms rather than the model's.
There is a version of this work that stops at step four, produces a transcript showing the assistant misbehaving, and achieves nothing. The transcript is evidence. Steps five and six are the finding.
Writing it up so somebody acts
This is where most AI security testing fails. The testing was fine; the report reads as a curiosity.
Take this with you
What a finding needs to contain
- The exact input, verbatim, and the exact output, verbatim. Not a paraphrase.
- How many attempts out of how many succeeded.
- What the system was permitted to do at the time, and by which credential.
- The worst realistic outcome, stated in business terms rather than technical ones.
- Whether the same result is reachable indirectly, without access to the interface.
- A recommendation that is architectural rather than a request to improve the prompt.
What to do the moment something works
Stop and preserve it before you try to make it better. The most common way a real finding is lost is that the tester, pleased it worked, immediately refines the input and can no longer reproduce the original.
Save the exact input, the exact output, the timestamp and the conversation up to that point. Then reproduce it once from a clean session before changing anything.
If the behaviour reached production data or a live integration, that is an incident rather than a test result, and it follows your incident process from that moment. Agreeing this in advance is why the authorisation note at the top of this page exists.
When to stop
Stop when you can answer the only question that matters: what is this system holding, and what happens when it is fooled?
You do not need an exhaustive catalogue of every wording that works. Nobody will read it, and it will be stale when the model is next updated. One well-evidenced indirect finding with a clear blast radius changes more than fifty direct ones.
Verified
Method and framing drawn from the prompt injection pattern library published on this site, which documents each pattern with a stable identifier and maps it to OWASP, MITRE ATLAS and NIST. Written 5 August 2026. No working payloads are included here by design.
