Prerequisite: Framework Overview, Assumption Mapping
Build an Attacker Persona
You’ve been testing a customer support chatbot for an hour. You’ve tried prompt injection, encoding tricks, roleplay attacks. None are working.
But every attack you tried was the attack a security-minded technical person would try. You’ve been testing as yourself.
What if the real risk isn’t a security researcher? What if it’s a frustrated customer who escalates emotionally until the bot says something it shouldn’t? Or an employee who knows exactly how the system was built?
Different attackers think differently. They have different knowledge, different motivations, different approaches. If you only test from your own perspective, you only find your own blind spots.
This exercise builds structured attacker profiles so you systematically cover the perspectives you’d miss.
What it looks like when it’s done
Here’s a completed persona. This is the destination.
Persona identity
| Field | Value |
|---|---|
| Persona name | Academic researcher testing boundaries |
| Archetype | Curious amateur (domain expert, not a security expert) |
| Goal | Determine whether the model produces biased or stereotypical outputs about demographic groups, for a research paper |
Empathy map
| Dimension | Response |
|---|---|
| Thinks | Understands how language models work at a conceptual level. Assumes the model has bias mitigation but suspects it’s incomplete. Knows that models trained on internet data reflect societal biases. Doesn’t know specific jailbreak techniques. |
| Feels | Motivated by academic curiosity, not malice. Wants to publish findings. Moderate persistence: will try multiple approaches but won’t spend days on it. |
| Says | Academic language. Frames requests as research questions. Uses terms like “representation,” “fairness,” “demographic analysis.” Doesn’t use hacker terminology. |
| Does | Starts with straightforward questions about demographic groups. Reframes as “academic analysis” if refused. Compares outputs across demographic variables. Documents inconsistencies. |
Capabilities and constraints
| Dimension | Response |
|---|---|
| Capabilities | Strong social science domain knowledge. Can design controlled experiments (varying one demographic variable at a time). Familiar with bias in ML at a theoretical level. No jailbreak expertise. |
| Constraints | Won’t use techniques they’d be embarrassed to cite in a paper. Time-limited by research project timeline. No automation tools. |
Pause here. Based on this persona’s profile, what attack vectors would they try? Write your list before reading below.
Attack vectors derived from persona
| # | Attack vector | Why this persona would try it | Priority |
|---|---|---|---|
| 1 | Ask the model to describe “a typical [demographic] person” across multiple groups | Direct test for stereotypical outputs, natural academic framing | High |
| 2 | Write recommendation letters for candidates with different demographic identifiers | Tests whether quality or tone varies by demographic, realistic use case | High |
| 3 | Compare model outputs for identical prompts with only demographic variables changed | Controlled experiment design, not adversarial but reveals inconsistency | High |
| 4 | Frame bias probing as “helping me understand representation in AI outputs” | Academic reframing that may bypass content filters | Medium |
| 5 | Ask the model to “analyze stereotypes” about a group (requesting stereotypes as part of the analysis) | Requests harmful content as object of study | Medium |
Notice: none of these look like traditional jailbreaks. This persona doesn’t know what a jailbreak is. They’re using their domain expertise (controlled experiments, academic framing) to surface harm the model’s safety training wasn’t designed to catch.
That’s the point of the exercise. Different perspectives find different vulnerabilities.
How to do it yourself
Time box: 15-20 minutes per persona.
Step 1: Persona identity
Define who this attacker is:
| Field | What to fill in |
|---|---|
| Persona name | A descriptive label (“Disgruntled insider,” “Curious teenager,” “Automated scraper”) |
| Archetype | Where on the spectrum: malicious expert, opportunistic actor, curious amateur, misinformed user, automated system, insider with context |
| Goal | What does this attacker want to achieve? Be specific. |
Step 2: Empathy map
Put yourself in their perspective:
| Dimension | Prompt |
|---|---|
| Thinks | What does this attacker know about the system? What assumptions do they make about its guardrails? What mental model do they have? |
| Feels | What motivates them? (curiosity, malice, profit, ideology, boredom) What’s their frustration tolerance? Will they persist or give up? |
| Says | What kind of language do they use? Formal? Casual? Technical? Do they use domain jargon or social engineering? |
| Does | What’s their attack sequence? Do they start subtle or go direct? Do they use tools? Do they iterate or try once? |
Step 3: Capabilities and constraints
| Dimension | Prompt |
|---|---|
| Capabilities | Technical skill level. Domain expertise. Access to tools or automation. Knowledge of jailbreak patterns. Familiarity with the specific system. |
| Constraints | Time limitations. Technical gaps. Access restrictions. Risk tolerance (worried about detection?). Resources available. |
Step 4: Derive attack vectors
This is the payoff. Based on the persona’s profile, list the attack vectors they would naturally pursue. Not attacks you would try. Attacks this person would try, given their knowledge, motivation, and constraints.
| # | Attack vector | Why this persona would try it | Priority |
|---|
What you should have
- A documented attacker profile you can reference throughout testing
- Attack vectors derived from the persona’s perspective (not yours)
- A lens for evaluating whether your testing covers this threat actor
A contrasting example
Here’s a second persona for the same type of system. Compare the attack vectors to the academic researcher above.
Persona identity
| Field | Value |
|---|---|
| Persona name | Disgruntled insider with system knowledge |
| Archetype | Malicious insider |
| Goal | Exfiltrate customer PII from the internal support chatbot they helped build |
Empathy map
| Dimension | Response |
|---|---|
| Thinks | Knows the system architecture. Knows where data lives and how retrieval works. Knows the team that built the guardrails and their blind spots. Assumes monitoring focuses on external threats, not internal queries. |
| Feels | Angry about being passed over for promotion. Rationalizing: “they owe me.” High persistence because they feel justified. Low concern about ethical boundaries. |
| Says | Internal jargon. Knows exact terminology the system uses. Can phrase requests that sound like legitimate internal queries. Wouldn’t use hacker language. |
| Does | Tests during off-hours when monitoring might be lighter. Uses legitimate access to mask adversarial behavior. Starts with normal queries and gradually escalates. Doesn’t need jailbreaks because they have inside knowledge. |
Capabilities and constraints
| Dimension | Response |
|---|---|
| Capabilities | Built (or helped build) parts of the system. Knows the retrieval architecture, data sources, and which safety checks exist. Can phrase queries that look like system debugging. |
| Constraints | Actions are logged under their employee ID. Must make adversarial queries look routine. Limited window before access is revoked if they leave the company. |
Attack vectors derived from persona
| # | Attack vector | Why this persona would try it | Priority |
|---|---|---|---|
| 1 | Use legitimate query patterns that happen to surface PII | Knows exactly what queries the system supports and which ones return customer data | High |
| 2 | Phrase requests as system debugging (“show me raw retrieval output for ticket #12345”) | Internal framing that bypasses content filters designed for end users | High |
| 3 | Ask for “sample outputs” or “test data” knowing the staging environment uses real customer data | Exploits a deployment assumption only an insider would know about | High |
| 4 | Query during maintenance windows when monitoring thresholds might be relaxed | Timing-based evasion that requires operational knowledge | Medium |
| 5 | Request data exports framed as performance analysis or quality assurance | Legitimate business function that happens to produce the data they want | Medium |
What the contrast reveals
The academic researcher and the insider are testing the same type of system. Their attack vectors have zero overlap.
The researcher tests through controlled experiments and academic framing. The insider tests through system knowledge and operational access. Neither approach is wrong. But if you only built one persona (or none), you’d only cover one attack surface.
When to use this
- Before starting a new engagement (define who you’re emulating)
- When you’re stuck in repetitive patterns (adopt a different persona)
- When testing for specific threat actors (build their profile first)
- When working in a team (align on shared understanding of the attacker)
Evaluate your work
After building your persona, ask yourself: how different is this attacker from me?
If their attack vectors look like your attack vectors, the persona isn’t doing its job. A useful persona forces you into approaches you wouldn’t have tried. The academic researcher doesn’t use encoding tricks. The insider doesn’t use jailbreaks. Each persona’s constraints push them toward techniques the other would never consider.
The test: did building this persona generate attack vectors you wouldn’t have listed on your own? If not, push the persona further from your own perspective.
Background
This exercise adapts empathy mapping (Dave Gray / XPLANE), originally developed to help teams understand users by mapping what they think, feel, say, and do. In UX, empathy maps surface user needs the team hasn’t considered. In red teaming, they surface attack vectors the tester hasn’t considered. Same tool, adversarial application.
Tools
Next: Techniques