adversarial-reasoning

# Adversarial Reasoning (AR) Validate and stress-test solutions by systematically attacking them. ## When to Use - Solution already exists and needs validation - High-stakes decisions requiring robustness - Security or reliability critical - Before committing to irreversible actions - Pre-deployment validation ## Prerequisite AR requires a proposed solution to attack. If no solution exists, use ToT or BoT first. ## STRIKE Framework ### S - Surface Attack Vectors Identify all possible ways the solution could fail: - Edge cases - Adversarial inputs - Environmental factors - Dependency failures - Human factors ### T - Test Systematically For each attack vector, design and execute tests: - Unit-level attacks - Integration-level attacks - System-level attacks - Chaos engineering approaches ### R - Rate Severity Score each vulnerability found: - **Critical**: Solution fundamentally broken - **High**: Major functionality impacted - **Medium**: Degraded experience - **Low**: Minor issues ### I - Identify Mitigations For each vulnerability: - Can it be fixed? - What's the mitigation cost? - Is the residual risk acceptable? ### K - Kill or Keep Decision Based on findings: - **KILL**: Too many critical issues - **REVISE**: Fixable issues found - **KEEP**: Robust enough to proceed ### E - Evidence Documentation Document all findings for future reference. ## Output Template ```markdown ## AR Validation: [Solution Name] ### Solution Under Test [Brief description of the proposed solution] ### Attack Surface Analysis #### Attack Vector 1: [name] - **Attack**: [how to break it] - **Result**: [what happened] - **Severity**: [Critical/High/Medium/Low] - **Mitigation**: [fix or accept] #### Attack Vector 2: [name] ... ### Vulnerability Summary | Vector | Severity | Exploitable | Mitigation | |--------|----------|-------------|------------| | [name] | High | Yes | [action] | | [name] | Medium | No | Accept | ### Stress Test Results - Load test: [result] - Failure injection: [result] - Edge cases: [result] ### Verdict **[KILL / REVISE / KEEP]** Confidence: X% ### Required Changes (if REVISE) 1. [change 1] 2. [change 2] ### Residual Risks (if KEEP) - [risk 1]: [acceptance rationale] ``` ## Example **Solution**: JWT authentication for API **Attack Vectors Tested**: 1. Token expiration bypass → PASSED (properly enforced) 2. Algorithm confusion attack → FAILED (accepts "none") 3. Secret key brute force → PASSED (256-bit key) 4. Token replay attack → PARTIAL (no jti claim) **Verdict**: REVISE - Fix algorithm validation - Add jti claim for replay protection Then: KEEP with 85% confidence