Using Perseus

Overview

Perseus is a rigorous, automated security assessment framework for Claude Code. It transforms the AI into a structured penetration tester.

Core Principle: Methodological rigor over ad-hoc guessing. We do not "look around"; we execute specific phases.

The Workflow

The assessment MUST follow this linear sequence. Do not skip phases.

Phase 1: Reconnaissance (/scan)

Goal: Map the attack surface.

• Action: Run Skill: perseus:scan (or /scan).
• Output: deliverables/code_analysis_deliverable.md (Target Knowledge Graph).
• Stop Condition: Do not proceed until you know what to attack.

Phase 2: Vulnerability Analysis (Audit)

Goal: Prove potential vulnerability.

• Action: Run Skill: perseus:audit.
• Logic: Launch 5 parallel specialists (Injection, XSS, Auth, Authz, SSRF).
• Method: "Negative Analysis" (Source -> Flow -> Sink -> Defense -> Verdict).
• Output: Specialized reports in deliverables/.

Phase 3: Exploitation (Exploit)

Goal: Verify impact (False Positive Filtering).

• Action: Run Skill: perseus:exploit.
• Safety: Use SAFE payloads only (whoami, alert(1), sleep).
• Output: Verified proofs in deliverables/exploitation_report.md.

Phase 4: Reporting (/report)

Goal: Communicate risk.

• Action: Run Skill: perseus:report (or /report).
• Output: Final SECURITY_REPORT.md with executive summary and risk scoring.

Optional: Specialists (/specialist)

Goal: Run all deep-dive specialists in parallel.

• Action: Run Skill: perseus-specialist (or /specialist).

Engagement Modes

Always select engagement mode before Phase 1. If user does not specify, default to PRODUCTION_SAFE.

Mode	Intended Environment	Verification Style
PRODUCTION_SAFE	Live production	Passive analysis + minimal non-disruptive verification
STAGING_ACTIVE	Staging/pre-prod	Targeted active verification with throttling
LAB_FULL	Isolated lab	Full dynamic verification for hard-to-reproduce findings
LAB_RED_TEAM	Dedicated security lab	Adversarial chain simulation with strict legal scope

Mode selection rule:

1. If environment is unclear, assume production and use PRODUCTION_SAFE.
2. If user requests aggressive testing, require explicit confirmation that target is staging/lab and authorized.
3. Record chosen mode in deliverables so report consumers understand test depth.

Critical Rules

1. No Hallucinations: Only report vulnerabilities you have verified via Audit or Exploit.
2. Safe Mode: Never execute destructive commands (e.g., rm, DROP TABLE).
3. Evidence-Based: Every finding must cite a specific File:Line or HTTP Request/Response.
4. Authorization Gate: Do not run active exploit validation on production without explicit approved test window.
5. Stability First: Keep verification low-rate and stop immediately if service degradation appears.
6. Lab Isolation for Red-Team Mode: LAB_RED_TEAM only on isolated test environment with non-production data.

How to Start

If the user asks for a security review, pentest, or audit, ALWAYS start with:

I will use the Perseus methodology to assess this codebase.
Starting Phase 1: Reconnaissance...
[Invoking /scan]