Assumption Mapping

You’re about to test an enterprise chatbot. You have four hours. You start with encoding attacks. Base64, rot13, Unicode substitutions. An hour passes. Nothing works.

Then you realize: you never checked whether the system has input filters at all. You assumed it did because that’s what you’ve seen before. You spent an hour attacking a defense that might not exist.

Most failed red team engagements fail because of untested assumptions, not weak techniques. This exercise forces those assumptions into the open before you waste time on the wrong ones.

What it looks like when it’s done

Before the steps, here’s a completed example. This is the destination.

Setup

Field	Value
Target system	Enterprise chatbot with RAG over internal documentation
Attack goal	Extract confidential information from the knowledge base
Time box	20 minutes

Assumptions listed

#	Assumption
1	The chatbot has access to confidential HR documents
2	There’s a system prompt that restricts certain information
3	The RAG retrieval happens before any safety filtering
4	Direct questions about confidential topics will be refused
5	The system prompt is not visible to users
6	Indirect questions (framed as summaries) might bypass refusals
7	The chatbot doesn’t log or flag suspicious query patterns
8	Error messages might leak information about what documents exist

Mapped on the 2x2

Each assumption gets placed by two dimensions: importance (if wrong, does the attack fail?) and uncertainty (are you guessing or do you know?).

	Low Uncertainty	High Uncertainty
High Importance	Test Later: important but you’re confident	Test First: critical unknowns that could change everything
Low Importance	Ignore: low stakes and you’re confident	Monitor: uncertain but won’t change your approach

Assumption #	Importance	Uncertainty	Quadrant
1	H	M	Test Later
2	H	H	Test First
3	H	H	Test First
4	M	L	Ignore
5	M	M	Test Later
6	H	H	Test First
7	M	H	Monitor
8	L	H	Monitor

Pause here. Before reading the test results below, look at the three “Test First” assumptions. If you had to pick one to test first, which would you choose? What makes it the highest priority?

Testing priority

Priority	Assumption	How to test	Result
1	#3: RAG retrieval before safety filtering	Ask a borderline question, observe if the response references documents it then refuses to summarize	Confirmed: response said “Based on the Q3 salary review document…” before refusing to elaborate
2	#2: System prompt restricts certain information	Use prompt extraction techniques to surface the system prompt	Partial: extracted fragments mentioning “do not disclose compensation data”
3	#6: Indirect framing bypasses refusals	Ask “a summary of how the company approaches compensation” vs. “what are the salary bands”	Confirmed: summary request provided general framework, direct request was refused

What this revealed

Assumption #3 was the critical insight. The RAG system retrieves documents before safety filtering runs. Document names and metadata leak even when content is blocked. The entire attack strategy shifted from “bypass content restrictions” to “extract information through document references.”

That shift (from fighting the wrong defense to exploiting the real gap) is what assumption mapping produces.

How to do it yourself

Time box: 15-20 minutes for initial mapping.

Step 1: List your assumptions

Write down everything you’re assuming about the target. Don’t filter. Include assumptions about:

Defenses: What guardrails exist? How do they work? What triggers them?
Capabilities: What can the target do? What can’t it?
Context: What data does it have access to? What’s its deployment environment?
Behavior: How will it respond to specific inputs? What patterns does it follow?

Step 2: Map on the 2x2

Place each assumption by importance and uncertainty using the matrix from the example above. The goal is to find the Test First quadrant: high importance, high uncertainty. Those are the assumptions that could waste the most time if wrong.

Step 3: Prioritize and test

Take the Test First quadrant. For each assumption, write:

How you’ll test it (a specific action, not vague)
What result would confirm or reject it

Then test in priority order. Update results as you go.

What you should have

An explicit list of assumptions (no longer hidden)
A prioritized testing order
Clear next actions for reconnaissance or probing

When to use this

Before starting a new engagement (map assumptions about the target)
When an attack approach isn’t working (surface hidden assumptions)
When transitioning from recon to active testing (prioritize what to probe)
After a failed attack (identify which assumption was wrong)

Evaluate your work

Look at your completed assumption map.

How many assumptions are about the target’s defenses vs. about your own attack habits? If most of your assumptions describe what you expect to find (input filters, system prompts, content restrictions), you might be projecting your experience onto the target rather than analyzing it. The most valuable assumptions are the ones you didn’t realize you were making.

A strong assumption map has: assumptions that could genuinely be wrong (not just facts you already know), a clear Test First quadrant (if everything lands in Test Later, you’re probably too confident), and test plans specific enough to actually run.

Background

This exercise is adapted from assumption mapping (Strategyzer / Alexander Osterwalder), originally developed for business model validation. The 2x2 matrix (importance vs. uncertainty) is a prioritization tool. In business, it identifies which market assumptions to validate first. In red teaming, it identifies which defense assumptions to test first.

Tools

Use any 2x2 matrix tool:

Assumption Mapping, FigJam
Assumption Grid, Miro
Or the markdown tables above

Next: Attacker Persona