Red Team

Switch sides. Become the attacker, the competitor, the failure mode, or Murphy's Law — and try to break the thing the user just built, on purpose.

When to use

• Right before shipping, launching, publishing, or signing.
• Security/abuse review: "how would someone exploit this?"
• A strategy or plan that an opponent (competitor, regulator, adversary) could counter.
• A claim or argument going in front of a hostile audience.
• Anything where the cost of a missed weakness is high and rises after commitment.

When NOT to use

• Early brainstorming, where attacking ideas kills the generative phase. Diverge first, red-team later.
• When the user needs encouragement to start, not reasons to stop.
• Trivial, reversible decisions where the failure cost is near zero.

The method

1. Define the target and the win condition precisely. What exactly are you attacking, and what counts as "broken"? "The plan fails" is vague; "an attacker reads another user's data" or "the launch misses its date" is a target.
2. Pick your adversaries and put on each mask in turn. Run distinct passes, e.g.:
   • The malicious attacker — wants to exploit, steal, abuse, or cheat.
   • The competitor — wants to out-maneuver, copy, or undercut you.
   • Reality / Murphy — no intent, just everything that can fail will: outages, edge cases, bad inputs, scale, time.
   • The hostile critic — wants to discredit the argument publicly.
3. For each mask, ask "how do I win against this?" Generate concrete attacks, not vague worries. Name the exact input, move, or condition.
4. Probe the seams. Attacks live at boundaries: trust boundaries, handoffs, assumptions, "this will never happen," default configs, the unhappy path, the 10x-load path, the malicious-input path.
5. For each attack, rate severity × likelihood. A devastating-but-impossible attack and an annoying-but-certain one are different problems. Sort by the product.
6. Steelman the defense, then attack again. For the top attacks, imagine the best fix, then try to break that. Stop when remaining attacks are low-severity or genuinely hard.
7. Deliver the kill list. Ranked attacks, each with: the exact exploit, why it works, severity × likelihood, and the cheapest mitigation.

What good looks like

• Specific, reproducible attacks — a concrete input/move, not "security could be better."
• At least one finding the user clearly hadn't considered.
• Honest severity ratings, including downgrading scary-sounding but trivial issues.
• Every finding paired with a mitigation, so it's actionable, not just discouraging.
• Coverage across multiple adversary types, not just one favorite angle.

Anti-patterns

• Vague FUD: "this might not scale" with no scenario. Name the load and the breaking point.
• Attacking the person, not the work. Red-team the artifact, never the author.
• Only finding flaws you already know how to fix. Push into uncomfortable territory.
• No prioritization: a flat list of 30 issues is as useless as none. Rank them.
• Forgetting the boring adversary: most real failures are Murphy, not a genius hacker.

Example

Target: a referral feature giving $10 credit per signup. Win condition: extract money without real referrals. Attacker mask: "I script 10,000 throwaway emails, self-refer, cash out $100k in credit." Seam probed: the trust boundary assumes one human per email. Reality mask: "two legit users refer each other in a loop." Severity × likelihood: high × high — this will be hit on day one. Mitigation: credit only unlocks after the referred account makes a verified action with cost (a real payment), not at signup. Re-attack the fix: "I make one real $1 purchase to unlock $10" — so cap credit at the verified spend. Kill list delivered, ranked, with the cheapest patch first.