The Security & Compliance Review Agent

Claude Code Agents: Advanced Orchestration

Chapter 5 · The Security & Compliance Review Agent

Fundamentals' Chapter 6 covered a general code-review agent: read-only, reporting structured, severity-ranked findings without fixing anything itself. A security & compliance review agent is a specialized version of that exact same pattern, narrowed onto a specific, higher-stakes category of issue — and it's worth being just as honest about what it can't catch as about what it can.

What Makes Security Review Different from General Review

A general code-review agent looks broadly at correctness, style, and quality. A security & compliance review agent narrows that focus deliberately: injection vulnerabilities, authentication and authorization gaps, exposed secrets or credentials, insecure use of dependencies, and data handling that violates a specific compliance requirement (like mishandling personal data). This narrower scope requires deeper, more specialized knowledge of actual attack patterns than a general-purpose review agent's system prompt would typically need to cover.

Designing a Security Review Agent's Definition

"Use this agent to check code changes for security vulnerabilities — injection risks, authentication/authorization flaws, exposed secrets — and relevant compliance requirements, before merging. This is not a substitute for a full security audit or a real penetration test." Tool access follows the same restricted pattern as the general review agent — Read, Grep, Glob, no Edit — and the isolation principle matters even more here: a security reviewer should never itself be the agent making changes to security-sensitive code. Model choice should favor the most capable model available, since genuinely subtle security issues require real judgment, not pattern-matching against a fixed checklist.

Writing the System Prompt for a Security Review Agent

A security review agent's system prompt should instruct it to check specifically for:

Hardcoded secrets or credentials committed directly into code
Injection risks — user-controlled input reaching a database query, a shell command, or similar, without proper handling
Missing authentication or authorization checks on sensitive operations or endpoints
Compliance-relevant patterns specific to the project — for instance, personal data being logged in plaintext where it shouldn't be

It should use the same structured finding format from Fundamentals' Chapter 6 (file, line, summary, failure scenario, verdict) — and a concrete failure scenario matters even more here than for a general finding, since a vague "this could be a security risk" gives no way to judge how serious or exploitable an issue actually is.

// Example structured security finding
file: src/api/search.ts
line: 18
summary: User-supplied search term is concatenated directly into a SQL query string
failure_scenario: A request with a search term like `' OR '1'='1` would alter the query's logic, potentially returning records the requester shouldn't have access to — the input is never parameterized or escaped before being inserted into the query
verdict: CONFIRMED

Aspect	General Code-Review Agent (Fundamentals Ch.6)	Security & Compliance Review Agent
Scope	Bugs, style, general quality	Vulnerabilities and compliance requirements specifically
Required expertise	General code understanding	Specific knowledge of attack patterns and applicable regulations
Tools	Read, Grep, Glob — no Edit	Same — no Edit, arguably even more important here

State the specific compliance requirements that actually apply

"Check for security issues" is far less useful than "this feature handles EU user data, so data-minimization and consent requirements apply — flag anything storing or logging more personal data than the feature genuinely needs." Compliance requirements vary by project and jurisdiction, and a generic brief has no way to know which specific ones are actually relevant.

This is not a substitute for a real security audit

A security review agent catching known, common vulnerability patterns is genuinely useful, but it is not equivalent to a comprehensive security audit or a real penetration test. Sophisticated or novel attack vectors, and issues in infrastructure or deployment configuration entirely outside the code itself, are genuinely outside what a code-focused review agent can catch. Treat its findings as one useful layer, not as a substitute for genuine, dedicated security review by the people or processes actually responsible for that.

Hands-On Exercises

Exercise 1

Explain why a security review agent is denied Edit access with even more emphasis placed on this than for a general code-review agent, using this chapter's own reasoning.

📄 View solution

Exercise 2

A team briefs their security review agent with just "check for security issues" for a feature that stores health-related user data. Using this chapter's own tip box, explain what's missing from this brief and rewrite it.

📄 View solution

Exercise 3

A team runs their security review agent, receives zero findings, and decides no further security review is necessary before their product launch. Using this chapter's own warning box, explain why this decision is risky.

📄 View solution

Chapter 5 Quick Reference

A security & compliance review agent specializes Fundamentals' general review agent onto vulnerabilities and compliance requirements specifically
Same restricted tools (Read/Grep/Glob, no Edit) — isolation matters even more here
Checks for hardcoded secrets, injection risks, missing auth checks, and project-specific compliance patterns
A concrete failure scenario matters even more for a security finding than a general one
State the specific compliance requirements that actually apply — a generic brief can't know which ones do
This is one useful layer, not a substitute for a real security audit or penetration test