Run a security review with a subagent

Have Claude Code hand a security review of one directory to a subagent, so the reading stays out of your session and you get a ranked list of findings.

Task: Run a security review with a subagent · Other tasks

Fill in the details

Directory or file to review (required)

A path relative to the project root. Smaller scopes give more thorough reviews.

Threats to look at closely

Optional. Name the risks you care most about for this code.

What this code does and who can reach it

Optional. Who calls the code, and which parts are exposed to the internet.

How far to follow the code

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

Use a subagent to review [fill in: Directory or file to review] for security issues and report what it finds.

Scope: that path, plus the helpers it calls and the code that calls it.

Brief the subagent with these rules:
- Read only. Do not edit files, install packages, or run code against live systems or real data.
- Check for issues such as missing authentication or access checks, injection, unsafe handling of user input, secrets in code, and insecure data handling.
- Report only issues with a plausible way to be exploited or to leak data. Leave out style points.
- For each finding: file and line, what an attacker could do, how confident it is, and a suggested fix. Mark anything it suspects but could not confirm in the code.

When the subagent reports back, give me:
1. Findings, grouped as high, medium and low risk, most serious first.
2. Parts of the scope it did not review, and why.
3. Questions about how the code is deployed or used that would change a finding.

Do not apply any fixes. I will choose which findings to address.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

You want a security pass over one area of the code, such as an API layer or an upload handler, without filling your main session with every file the review reads.
You are about to ship a change to code that handles user input or access control and want a focused second look first.
You need findings you can act on: a location, an impact and a fix for each, ranked so you know where to start.

When not to use it

You need a formal audit, a penetration test or a compliance sign-off. A model review can help you prepare, but it does not replace those.
You want the same security reviewer every time, with fixed rules. Define a custom subagent in .claude/agents/ and commit it, so your team can call it by name.
The scope is the whole repository. Split the review by directory or by threat; a single broad review spreads its attention thin.

Why this structure

The opening line asks for a subagent explicitly. A subagent works in its own context window and returns a summary, so the long reading a security review needs does not crowd out the rest of your session.
The prompt contains a brief for the subagent. Unless it is a fork, which inherits the parent conversation, a subagent starts in a fresh context window without your conversation history, so the rules it needs, read-only and what counts as a finding, are written out for Claude to pass on.
The scope choice sets how far the review follows the code. Many access and input problems sit in a helper or a caller just outside the directory you named.
The rule to report only plausible exploits matters because a reviewer asked to find problems will usually find some. It aims to keep the list to issues worth fixing.
Each finding needs a location, an impact, a confidence and a fix, and unconfirmed ones are marked, so you can check the serious ones first and discard weak ones quickly.
The closing line keeps fixes out of the review. You read the findings, decide, and then ask for the changes you want.

Example input (fictional)

Directory or file to review

src/api/

Threats to look at closely

access checks on admin routes and handling of uploaded files

What this code does and who can reach it

Public REST API used by the mobile app. Admin routes are behind a session check.

How far to follow the code

that path, plus the helpers it calls and the code that calls it

Follow-ups to send Claude

Fix the high-risk findings one at a time. For each, add a test that fails before the fix and passes after, and run the tests.
Turn this review into a project subagent in .claude/agents/ named security-reviewer, with read-only tools and the rules above.
Use a subagent to check whether the same patterns as the high-risk findings appear anywhere else in the codebase.

Common mistakes

Naming the whole repository as the path. The review gets shallow; pick the code that faces users or handles access first.
Leaving out who can reach the code. An issue in an internal admin tool and the same issue on a public endpoint carry very different risk.
Fixing every finding without reading it. Some will be false alarms or depend on deployment details Claude could not see; confirm each one in the code first.

Code review prompt: Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.
Review a pull request: Give Claude Code a pull request number; it reads the diff and the code around it, summarizes what changed and lists concerns, without posting anything.
Review a Terraform plan before applying: Paste Terraform plan output into Claude Code and get a plain-language account of what will change and what could break, before you run apply.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
Claude Code best practices: Create custom subagents (Anthropic documentation)
Claude Code best practices: Add an adversarial review step (Anthropic documentation)
Claude Code docs: Subagents, what loads at startup (Anthropic documentation)