Adversarial Security

A multi-pass security auditing system that produces high-confidence vulnerability assessments by introducing structured adversarial critique stages. Audits pass through an iterative pipeline of reconnaissance, red-team attack, remediation planning, and optional external validation — producing output optimized for exploitability, impact, and actionable remediation.

When to Load

Load this skill when any of these apply:

• Running a security audit against an entire repository
• Performing threat modeling for a new or existing codebase
• The user asks for an adversarial security review or red-team analysis
• The user says "security audit", "threat model", "find vulnerabilities",

"adversarial security", or "red team this repo"

• Preparing a security posture report for a release or compliance review
• You want to reduce blind spots in your own security assessment

Auto-Detection

Before starting, auto-detect the project type by scanning the repository:

The MCP-Specific Security category (Category 10) is always evaluated with graceful degradation. If the target is not an MCP server, findings in this category are reported as informational rather than skipped entirely. The rationale: even non-MCP projects may expose tool-like interfaces, schema descriptions, or configuration metadata that could be poisoned.

When signals overlap (e.g., an MCP server that is also a CLI tool), combine the extra categories from all matching types.

Adversarial Protocol

This skill follows the standard dual-agent adversarial pattern (Agent A: The Threat Modeler, Agent B: The Red Team). For the core pipeline rules, phase definitions, and agent switching protocols, read: [references/adversarial-base-protocol.md](references/adversarial-base-protocol.md)

For the security-specific protocol with review dimensions, scoring weights, and output templates, read: [references/multi-pass-security-protocol.md](references/multi-pass-security-protocol.md)

Audit Categories

The 10 security categories audited during Phase 1 (Reconnaissance) and challenged during Phase 2 (Red Team) are:

1. Dependency Vulnerabilities
2. Secret & Credential Exposure
3. Input Validation & Injection
4. Authentication & Authorization
5. Transport & Network Security
6. Docker Security
7. CI/CD Pipeline Security
8. Error Handling & Information Disclosure
9. Supply Chain
10. MCP-Specific Security (graceful degradation for non-MCP targets)

For the full checklist with CWE IDs, vulnerable patterns, and secure patterns, read references/audit-categories.md.

External Validation (Phase 4)

Phase 4 triggers an independent validation pass using the GitHub CLI (gh copilot). The copilot subcommand is built into modern gh CLI — no separate extension is needed. This provides a fundamentally different model's perspective on the audit, reducing confirmation bias that persists even after adversarial self-review.

For prompt templates and integration details, read references/copilot-security-prompts.md.

Prerequisites: gh CLI v2.x+ with gh auth status passing. If gh copilot is not available, skip Phase 4 gracefully and note the skip in the journal entry.

Read references/copilot-usage.md for critical non-interactive execution requirements.

Feedback Loop & Documentation

Every phase creates a journal entry with structured tags and entry types. This builds a searchable audit trail that informs future security reviews.

For journal templates, tag conventions, cross-session learning patterns, and retrospective templates, read references/feedback-loop.md.

Journal Opt-Out

See references/journal-opt-out.md for instructions on how to handle explicit opt-outs from journaling.

Consolidated Report

The final deliverable is a single consolidated artifact merging all four phases into one document, following the template in references/multi-pass-security-protocol.md § Final Report Assembly. Do NOT produce separate artifacts per phase — the user should receive one comprehensive document with all findings, remediations, and external validation results. Before sharing output outside the audit context, redact or generalize specific exploit details and avoid including live credentials or internal hostnames.

Configuration

Audit Depth Profiles

• Recon: Scan for critical and high-severity issues only (Categories 2,

3, 4). Best for quick triage or low-risk utility repos.

• Standard: Full 10-category audit with all review dimensions. Default

for most repositories.

• Paranoid: Extended audit with additional focus on:
• Supply chain deep dive (lockfile integrity, install scripts, typosquatting)
• Cross-project impact (shared dependencies, ecosystem blast radius)
• Advanced attack vectors (prototype pollution chains, ReDoS, timing attacks)
• Historical git analysis (secrets that were committed then removed)

Synergies