Prerequisite: Techniques Overview, Assumption Mapping, Attacker Persona
Adversarial Ideation
You’re testing a chatbot. You try encoding attacks. They don’t work. You try persona. Doesn’t work either. You try three more things you can think of. All from the same mental model, all failing for similar reasons.
The problem isn’t your techniques. It’s that you’re generating from habit, not from systematic coverage. You tried what you know. You didn’t try what you don’t naturally think of.
This exercise forces you to generate attack vectors across every technique category, find the gaps in your thinking, and then evaluate and prioritize what you’ve generated. It’s the difference between “try stuff and see what breaks” and systematic coverage of the attack space.
What it looks like when it’s done
Here’s a completed example. Read through the whole thing before learning the steps.
Setup
| Field | Value |
|---|---|
| Target system | AI-powered code review tool integrated into a development platform |
| ”How Might I” question | ”How might I get this code review tool to generate malicious code suggestions?” |
| Persona lens | Opportunistic actor (moderate skill, looking for easy wins) |
| Time box | 12 minutes divergent, 10 minutes convergent |
Divergent phase (generate without filtering)
| # | Attack approach | Category |
|---|---|---|
| 1 | Ask it to “fix a security vulnerability” by providing the vulnerability as the fix | Framing |
| 2 | Submit code with a subtle backdoor and see if the review catches or propagates it | Framing |
| 3 | Request “test code” that actually implements an exploit | Framing |
| 4 | Ask for code review in a language the tool is weaker in | Encoding |
| 5 | Frame malicious code as “penetration testing utilities” | Persona |
| 6 | Ask it to “refactor” code in a way that introduces vulnerabilities | Refusal Suppression |
| 7 | Provide obfuscated code and ask for a “clearer version” that’s malicious | Encoding |
| 8 | Build up over multiple reviews: establish benign patterns, then introduce malicious elements | Multi-turn |
| 9 | Ask it to generate code that “simulates” an attack for educational purposes | Narrative |
| 10 | Request output as a config file to bypass code-specific filters | Output format |
Cluster similar ideas
Group ideas by theme before evaluating. This reveals patterns and gaps.
| Cluster | Approaches | Theme |
|---|---|---|
| Semantic inversion | #1, #6 | Using the tool’s own purpose against it |
| Context manipulation | #3, #5, #9 | Framing malicious intent as legitimate development |
| Obfuscation | #4, #7, #10 | Hiding malicious content in unusual forms |
| Accumulation | #2, #8 | Building to malicious output gradually |
Coverage check
How many ideas per technique category?
| Category | Count | Gap? |
|---|---|---|
| Encoding | 2 | No |
| Framing | 3 | No |
| Persona | 1 | No |
| Narrative | 1 | No |
| Refusal Suppression | 1 | No |
| Output format | 1 | No |
| Multi-turn | 1 | No |
| Structural | 0 | Yes |
| Infrastructure | 0 | Yes |
Prompt-level is well covered. Zero structural or infrastructure ideas. Added: “Submit code with in-context examples of the tool approving similar patterns” (ICL exploitation) and “Target the code review’s safety classifier directly” (defense evasion).
Pause here. Look at the zero-count categories. Before reading the evaluation below, pick one structural technique and one infrastructure technique. What attack approach would they produce for this target?
Evaluate and prioritize
| # | Attack approach | Likelihood | Severity | Novelty | Priority |
|---|---|---|---|---|---|
| 2 | Subtle backdoor propagation | H | H | M | Test first |
| 6 | Malicious refactoring | M | H | H | Test first |
| 1 | ”Fix vulnerability” inversion | M | H | M | Test |
| 8 | Multi-review escalation | M | H | H | Test |
| 3 | ”Test code” framing | M | H | L | Test |
| 9 | ”Simulation” framing | M | M | L | Lower priority |
| 10 | Format bypass | L | M | M | Lower priority |
Priority logic:
- High likelihood + high severity = test first
- Any severity + high novelty = test (novel attacks are worth exploring even if unlikely)
- Low likelihood + low severity + low novelty = skip
Testing order
| Order | Approach | Rationale |
|---|---|---|
| 1st | #2 (backdoor propagation) | Highest likelihood + severity: does the tool propagate existing vulnerabilities? |
| 2nd | #6 (malicious refactoring) | High novelty: can the tool’s own purpose be inverted? |
| 3rd | #1 (vulnerability as fix) | Tests semantic inversion pattern broadly |
| 4th | #8 (multi-review escalation) | High potential, more setup required |
| 5th | #3 (test code framing) | Lower novelty but quick to test |
How to do it yourself
Time box: 10-15 minutes divergent, 10-15 minutes convergent.
Step 1: Set up
| Field | What to fill in |
|---|---|
| Target system | What are you testing? |
| ”How Might I” question | Frame the attack goal as an open question |
| Persona lens | Which attacker persona are you ideating as? Change personas between rounds. |
Step 2: Diverge (generate)
List attack approaches without filtering. Quantity over quality. No evaluation. Label each with its technique category.
Use the technique taxonomy as a checklist:
- Prompt-level: encoding, framing, persona, narrative, refusal suppression, output format, multi-turn, persuasion
- Structural: ICL exploitation, control plane confusion, meta-rule manipulation, capability inversion, cognitive load, defense evasion
- Infrastructure: agentic attacks, protocol exploitation, compositional primitives
Step 3: Cluster
Group similar ideas by theme. Name each cluster. This reveals the shape of your thinking before you start judging individual ideas.
Step 4: Coverage check
Count ideas per technique category. Any category with zero ideas is a blind spot. Spend 2 minutes generating at least one approach for each gap.
Gaps in structural and infrastructure categories are common. They often reveal the most interesting attack angles.
Step 5: Evaluate
Rate each approach on likelihood (will it work?), severity (how bad if it does?), and novelty (has this been tried?).
Step 6: Prioritize
Order approaches for testing. High likelihood + high severity goes first. High novelty goes early regardless.
What you should have
- A complete list of approaches (not just your defaults)
- Thematic clusters showing the shape of your attack thinking
- Coverage check showing gaps you’ve addressed
- Prioritized testing order with rationale
When to use this
- At the start of an engagement (generate attack coverage)
- When you’re stuck on one approach (force divergent thinking)
- When working with a team (structured brainstorming)
- After building a persona (ideate through their lens)
Evaluate your work
Look at your divergent list and your coverage check.
How many ideas came from technique categories you use regularly vs. categories you rarely touch? If most ideas cluster in 2-3 categories, you’re generating from habit. The exercise worked if it pushed you into categories you wouldn’t have visited on your own.
Also: look at your clusters. Did any cluster contain ideas from multiple technique categories? Those intersections are often where the most interesting attacks live. “Semantic inversion” in the example above combines framing, refusal suppression, and capability inversion. The cluster label reveals a strategy, not just a list.
Background
Adapted from diverge/converge (Stanford d.school), a core design thinking pattern. Divergent thinking generates options without judgment. Convergent thinking evaluates and prioritizes. Separating these phases prevents premature filtering: the idea you’d dismiss in evaluation might spark the idea that works.
Tools
Next: Prompt Anatomy