The implementer is the best-placed attacker: they know which identifier the lookup really keys on and which field the client can really set. Each iteration mounts one concrete attack on a trust assumption — register a lookalike vanity handle, send a forged value for a server-owned field, replay a deleted account's identity, claim someone else's artifact — and records it in an attack ledger. A successful attack becomes a fix (match on immutable IDs instead of renameable handles, mark server-set fields non-client-writable), then the attack is re-mounted to prove it now fails. Distinct from silent-failure-hunt (error handling): this attacks TRUST and authorization assumptions.
Loop
- Goal
- every trust assumption in the feature has at least one mounted attack recorded in ATTACKS.md, and every attack is defeated by a fix or proven infeasible
- Exit when
- ATTACKS.md exists, covers every trust assumption, and has zero unchecked attacks — each checked off as defeated by a verified fix or proven infeasible
Check between iterations
test -f ATTACKS.md && grep -c '^- \[ \]' ATTACKS.md || echo NO_LEDGER
$
Kickoff prompt
Start the "Red-Team Your Own Feature" loop.
Goal: every trust assumption in the feature has at least one mounted attack recorded in ATTACKS.md, and every attack is defeated by a fix or proven infeasible
Max iterations: 8
Between iterations run: test -f ATTACKS.md && grep -c '^- \[ \]' ATTACKS.md || echo NO_LEDGER
Exit when: ATTACKS.md exists, covers every trust assumption, and has zero unchecked attacks — each checked off as defeated by a verified fix or proven infeasible
Step 1: Write ATTACKS.md listing the feature's trust assumptions (who is matched on what identifier, which fields the client can set), then mount the first attack and record whether it succeeds.
›