prompt-injection-testing

Prompt Injection Testing (Chinese Version)

When to Use

Need to verify an LLM application's ability to resist direct and indirect prompt injection, data exfiltration, and unauthorized tool use.
Need to conduct a risk review of an existing plan, result, or evidence, and form actionable improvement items.
The input is incomplete, but a usable initial version with assumptions and information gaps still needs to be provided first.

Default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required fields.

First read and follow the prompts/prompt-injection-testing.md input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that truly affect judgment.
First perform an input audit, then distinguish confirmed facts, reasonable assumptions, and open questions.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a constrained initial version and explain which conclusions cannot yet hold.

Each execution must read prompts/prompt-injection-testing.md; it is the complete execution specification of this Skill.
When this Skill needs to be evaluated or regression-tested, read evals/eval.yaml and the matching evals/cases/ cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Use safe placeholder data only in authorized environments
Do not provide sensitive targets that can be used for real attacks
Verify whether side effects still occur after refusal
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide verification methods.
Priority must explain the basis of business impact, likelihood of occurrence, or detectability.

Covered: direct injection, indirect injection, instruction hierarchy, data leakage, tool privilege escalation, encoding obfuscation, multi-turn persistence, detection and recovery.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priority, evidence, owner, or next steps.
The output includes verifiable judgment criteria rather than generalities.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without explaining input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of trade-offs.
Replacing domain judgment with tool names or general theory.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start from the paths most likely to cause business loss, security issues, or release blockers.
Use the smallest verifiable experiment to reduce uncertainty, and record reproduction conditions.
Make the output directly executable and reviewable by another engineer.