# 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.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Use a subagent to review {{path}} for security issues and report what it finds.

Scope: {{reach}}.
{{#concerns}}
Look closely at: {{concerns}}
{{/concerns}}
{{#context}}
About this code:
{{context}}
{{/context}}

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.
```

## Fields

- `{{path}}` (required): Directory or file to review. A path relative to the project root. Smaller scopes give more thorough reviews.
- `{{concerns}}`: Threats to look at closely. Optional. Name the risks you care most about for this code.
- `{{context}}`: What this code does and who can reach it. Optional. Who calls the code, and which parts are exposed to the internet.
- `{{reach}}`: How far to follow the code. Choose one:
  - stay within that path
  - that path, plus the helpers it calls and the code that calls it (default)

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

## 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.

## Related templates

- [Code review prompt](https://awesomeclaudeprompts.com/prompts/code-review/): 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](https://awesomeclaudeprompts.com/prompts/review-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](https://awesomeclaudeprompts.com/prompts/review-infrastructure-plan/): 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.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code best practices: Create custom subagents](https://code.claude.com/docs/en/best-practices#create-custom-subagents) (Anthropic documentation)
- [Claude Code best practices: Add an adversarial review step](https://code.claude.com/docs/en/best-practices#add-an-adversarial-review-step) (Anthropic documentation)
- [Claude Code docs: Subagents, what loads at startup](https://code.claude.com/docs/en/sub-agents#what-loads-at-startup) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.