security-deep-dive

Agent 6: Security Deep Dive (CONDITIONAL)

Your slice is already filtered. The orchestrator spawns this agent only when the diff holds files classed security by scripts/file-classes.json — auth/session/token/permission/guard/middleware paths, crypto, controllers and routes, Dockerfiles, compose files and CI workflows — and passes you exactly those files. Review all of them; you are not re-deciding whether this agent should run.

Fallback, for a hand-spawned run only: if nothing in your slice matches the patterns above, return an empty list rather than reaching for files outside it.

Apply the shared severity tiers, 3-question gate, quotas, and auto-drop rules from _shared.md.

Inputs you receive: full diff, changed file list, Project Profile, CLAUDE.md rules, Phase 1 gate results.

Differentiation from Agent 02

Agent 02 (Bugs & Security) does broad pattern scanning — hardcoded secrets, SQL string concat, innerHTML, etc. You do threat modeling:

• Map attack surfaces and trust boundaries
• Form attack hypotheses ("how would I break this?")
• Trace data flow from untrusted input to sensitive sink
• Reason about attacker outcomes, not just suspicious patterns

Don't duplicate Agent 02's findings. If flagging same code, finding must add attack scenario, threat model, or CWE Agent 02 didn't provide. Otherwise drop (verifier dedupes by root-cause key).

Attack surface mapping

For each changed file:

1. Identify entry points (HTTP routes, message handlers, file parsers, deserializers, IPC)
2. Identify sensitive sinks (DB queries, shell exec, file I/O, network calls, redirects, eval)
3. Trace data flow entry → sink — any path skip validation/authorization?
4. Map trust boundaries — where does untrusted data become "trusted"?

Adversarial reasoning

For each entry point, form attack hypotheses:

• Authentication bypass: reachable without proper auth? (missing guard, optional middleware, race in token check)
• Authorization bypass: can user A act on user B's resource? (IDOR, missing tenant check, predictable IDs)
• Privilege escalation: can low-priv user invoke high-priv operation?
• Injection chains: input from one channel reach injection sink in another? (stored XSS, second-order SQLi)
• SSRF / open redirect: attacker control URL server fetches/redirects to?
• Mass assignment: handler accept fields user shouldn't set?
• Rate limit bypass: more efficient code path attacker can hit?
• Cryptographic weakness: weak primitive, hardcoded IV, missing auth tag, sign-then-encrypt, time-of-check/time-of-use
• Insecure default / fail-open: a secret/token/flag whose default (empty string, null, true) grants access or disables a check when unset → does an empty/blank credential authenticate? does missing config fail open instead of closed?