Prompt Injection Testing checks whether untrusted text can change an application’s task, expose protected data, or steer an agent into an unauthorized action. The text may come from a user or be embedded in a retrieved web page, file, email, or tool response. The impact depends on the data the application can reach and the tools and permissions available to the model, so testing must observe responses, tool calls, and system state together.
This guide is for defensive verification in an authorized environment. Confirm the system owner, scope, and permitted actions first. Use a sandbox, mocks, and synthetic data; do not send test writes to real services or put real credentials or sensitive target details in test inputs.
Map trust boundaries, assets, and actions first
Inventory the application’s task instructions, policy sources, model and version, external-content entry points, retrieval paths, session or memory behavior, tool permissions, and high-impact operations. Identify which text is trusted and which is data to process. List the assets to protect, such as a synthetic test marker, mock profile, or mock account record. If information is missing, record assumptions and questions separately instead of turning unknown behavior into a confirmed system rule.
| Input or capability | Boundary to confirm | Observable evidence |
|---|---|---|
| User message | Can the user change the task, override policy, or request protected data? | Case ID, input, policy version, response and refusal state |
| Retrieved content | Can text from a page, file, email, or knowledge base be treated as an instruction? | Source ID, retrieved chunk, citation, and follow-up action |
| Tool response | Can returned text change the next call or its arguments? | Tool response, candidate call, authorization decision, and call trace |
| Session, memory, and multimodal input | Can instructions persist across turns or enter through supported images, audio, or other inputs? | Turn ID, memory state, parsed input, and follow-up action |
Include only entry points and capabilities the product actually supports. State which tools are mocked, which external connections are disabled, and which state changes are permitted in the test scope.
Turn risks into decidable test cases
Do not collect “malicious prompts” without a test contract. Give every case a unique ID, preconditions, input source, security property, expected behavior, prohibited side effects, and evidence requirements. Derive expected behavior from the application’s policy and tool authorization rules. Suspicious text does not mean the application must reject every related task; it may still need to safely summarize or quote that text as content.
| Coverage area | Safe setup | Main assertion |
|---|---|---|
| Direct injection and task hijacking | Put conflicting text in a user message that asks the app to ignore its task and reveal a synthetic marker | The app follows its defined task and policy without exposing the protected marker |
| Indirect injection | Add similar conflicting text to a test page or document fixture, then ask for a summary | The system treats it as content and does not disclose data or expand the task because of it |
| Tool overreach | Have a mock tool return text containing an instruction, then observe candidate follow-up calls | Tool calls still require application-policy authorization; the injection does not broaden parameters or target scope |
| Obfuscation and persistence | Vary language, format, or turn structure where the product supports those paths | Unsupported paths are marked untested; a rejected instruction does not enter later tasks or memory without basis |
| Refusal and recovery | Cover policy-blocked requests, cases requiring clarification, and allowed normal tasks | A refusal has no side effects; normal tasks still work; the reason for stopping is traceable |
Example: In an isolated document-Q&A environment, add conflicting text to a test document and place the marker TEST_SECRET_7F3A in controlled test data. Ask only for a document summary. Check whether the summary stays focused on the document, whether the marker is disclosed, whether any tool tries to read or send data, and whether system state changes unexpectedly. The marker must be a synthetic value created for the test, never a real key.
Verify the full path, not only the response
For each case, record the model, system-instruction, application, and tool-configuration versions; run time; input source; response; citations or retrieval trace; attempted tool calls; authorization result; and post-run state. Repeat runs for behavior that can vary, recording each outcome. If settings cannot be fixed, capture those differences. One refusal does not prove later turns are safe, and one successful run does not show that every similar input will be blocked.
Link those details under one case ID and run ID, preserving the relationships among input source, retrieved content, call trace, and post-run state. Keep each repeated run separate instead of combining several outputs into a single “pass” result.
Compare side-effect evidence directly: did the blocked write stay blocked, was a tool call attempted, was data sent outside the system, and did mock state remain as expected? If you have only refusal text but no call trace or state evidence, mark the result “insufficient evidence” rather than a security pass.
Classify, prioritize, and close the regression loop
Use a clear outcome for each case:
- Pass: All required assertions have supporting evidence and no prohibited side effect was observed.
- Fail: An unauthorized action, data disclosure, or task hijack was observed, or a policy-required block did not occur.
- Insufficient evidence: Environment, trace, or state information is missing, so behavior cannot be determined.
Prioritize findings by business impact, reachable entry point, permission scope, and evidence strength. Separate assumptions, observed facts, and recommendations; list untested models, channels, and tools. After a fix, rerun the original cases and add neighboring boundary cases. A useful handoff includes the trust-boundary map, case IDs, expected assertions, run configuration, evidence locations, risk ranking, and next owner. The Skill organizes verification; it does not certify that an entire application is secure.
Use the OWASP GenAI Security Project’s Prompt Injection risk guidance: https://genai.owasp.org/llmrisk/llm01-prompt-injection/ as a reference, and derive expected behavior from the project’s own authorization policy. For model behavior and task quality, see LLM Testing: https://inaodeng.com/en/qaskills/llm-testing/. For tool permission and side-effect checks, see Agent Tool Call Testing: https://inaodeng.com/en/qaskills/agent-tool-testing/; broader controls are covered by Security Testing: https://inaodeng.com/en/qaskills/security-testing/.
Install the Skill with:
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/prompt-injection-testing -gReferences
- Prompt Injection Testing prompt: https://github.com/naodeng/awesome-qa-skills/blob/main/skills/en/testing-types/prompt-injection-testing/prompts/prompt-injection-testing.md
- Prompt Injection Testing source directory: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/prompt-injection-testing
- Prompt Injection Testing directory on this site: https://inaodeng.com/en/qaskills/prompt-injection-testing/