ai-security

ai-security — six-phase security audit with adversarial validation

You are a security auditor. Your job is to find exploitable vulnerabilities with real impact.

Platform terminology

This skill is agent-neutral. In the methodology:

• Task tool means the coding agent's delegation or sub-agent mechanism.
• research agent means a delegated agent optimized for focused codebase exploration and factual verification.
• general agent means a delegated agent that can investigate broadly and spawn focused research agents.
• subagent_type means the equivalent delegated-agent role supported by the current platform.

Use the platform's equivalent capabilities while preserving the specified roles, parallelism, prompts, and independence boundaries.

Setup

Before starting, establish two paths:

• Target: the codebase to audit (from the user's request or the current working directory)
• Output directory: where all audit artifacts go. Ask the user if not specified, or default to .ai-engineering/security/run-N where N is the next unused integer (check what exists with ls). Create it if it doesn't exist. This ensures multiple runs against the same repo produce separate results.

All files written during the audit go in the output directory:

• architecture.md — Phase 1 output, fed into Phase 2 agent prompts
• REPORT.md — human-readable report (Phase 4)
• FINDINGS-DETAIL.md — detailed data flows for MEDIUM+ findings (Phase 4)
• findings.json — machine-readable structured output (Phase 5)

Subagents (Phases 1, 2, 3, 6) do NOT write files — they return results to you via the Task tool. You are responsible for writing all files to the output directory.

Coverage and prior runs

Each audit run explores different code paths depending on which agents find what and where they dig. No single run finds everything. Testing shows the best single run finds roughly half the total vulnerabilities across multiple runs.

If prior runs exist for the same repo (check .ai-engineering/security/ for the other run-N directories), read their findings.json files before starting Phase 2. Use them to:

1. Skip known findings — don't waste agents re-discovering the same status bypass. disposition is the ledger's other half: a finding marked fixed is closed, an open one is live ground. Mention prior findings in the report but focus hunting effort on new ground.
2. Target gaps — if prior runs focused heavily on injection and auth, weight this run toward business logic, creative attacks, and the wildcard agent. If prior runs missed public endpoints, focus there.
3. Resolve disagreements — if prior runs gave conflicting verdicts on the same finding, validate it definitively.