Red-team a prompt

An assistant that behaves well on friendly inputs can fail on hostile or unusual ones: users asking it to ignore its rules, instructions hidden in documents or web pages it reads, requests just outside its scope, ambiguous inputs that lead it to invent facts, or attempts to extract its instructions or other users' data. Red-teaming finds these weaknesses before real users do. You are doing defensive testing for the owner of this prompt: design the tests, predict the failures from the prompt's wording, and fix them. Prompt instructions alone never make an assistant fully secure, so you also say where controls outside the prompt are needed.

Only if [CONTEXT] is given:

1. Map the attack surface: the assistant's purpose and audience, what untrusted text reaches it (user messages, uploaded files, retrieved documents, web pages, emails, tool results), what it can do (answer only, or take actions, send messages, call tools), what it must protect (its instructions, personal data, other users' data, brand, safety). Mark anything you had to assume.
2. Write test cases scaled to the exposure: 12 to 20 for a public, multi-user or tool-using assistant; 6 to 10 for a low-exposure prompt (one trusted user, no tools, no external content), where only the relevant categories apply. Draw from these categories, weighted towards what this deployment exposes:

• direct injection (asking it to ignore or reveal its instructions, role-play loopholes, "developer mode" claims);
• indirect injection (instructions planted in a document, page or tool result it processes);
• scope (off-topic requests, competitor questions, adjacent professional advice it should not give);
• harmful or policy-violating requests relevant to the domain;
• data leakage (other users' data, secrets in context, system prompt extraction);
• edge cases (empty, very long, other languages, malformed input, contradictory instructions);
• hallucination traps (questions whose answers are not in its sources);
• tone and escalation (abusive users, distressed users, requests for a human). For each: the input (describe harmful payloads in placeholder form rather than writing working harmful content), what a safe response looks like, and your prediction of how the current prompt behaves, with the reason from its wording.

1. Rank the likely weaknesses by severity (impact × likelihood).
2. Propose fixes: prompt changes (clear scope, data-versus-instructions boundaries with delimiters, refusal and redirect wording, what to do when information is missing, escalation paths) and controls outside the prompt (input and output filtering, tool permissions, human approval for actions, logging, rate limits). Be explicit that prompt-level fixes reduce but do not eliminate injection risk.
3. Write the hardened prompt with the fixes applied, preserving the original's purpose and voice.
4. Suggest how to keep testing: turn the cases into a regression set and re-run after every prompt change.

• This is defensive testing of the user's own prompt. Do not produce working instructions for real-world harm, malware or attacks on third parties; use placeholders such as [request for dangerous instructions].
• Predictions are predictions: label them as such and recommend running the cases on the real setup.
• Keep the hardened prompt as short as it can be while closing the gaps; do not bloat it with long lists of banned phrases.
• Do not weaken the assistant's usefulness for legitimate users; each fix should say what normal behaviour it preserves.

Attack surface

Bullets, with assumptions marked.

Test cases

A table: # | Category | Input | Safe behaviour | Predicted result (pass, fail, unclear) | Why.

Likely weaknesses

Numbered, most severe first.

Fixes

Two lists: In the prompt, Outside the prompt.

Hardened prompt

One fenced code block.

Ongoing testing

Three to five bullets.