Claude Code Security Review Receipts

Claude Code should not approve its own security work. Use it to widen code review, collect evidence, and make a human reviewer faster, especially on pull requests that touch auth, secrets, dependencies, data export, or production permissions.

In Claude Code training, I treat a Claude Code PR review as a bounded review pass, not as a replacement for the reviewer. The useful output is a receipt: what the agent inspected, what it could access, what it found, what it did not check, and who owns the final decision. That habit belongs in your Team conventions, because one person’s careful prompt does not scale by itself.

Set the review boundary before the agent starts

Start with scope. Tell Claude Code which diff, branch, or commit range to inspect, and tell it which systems are off limits.

For a security pass, I usually want read access to the repository and test output. I do not want write access to production systems, secret stores, payment dashboards, or customer data while the review is still exploratory.

MCP servers connect Claude Code to external systems such as GitHub, docs, and internal tools. That is useful, but it also means the security review has its own security boundary. If the hard part is access design, plan that boundary before the review using Plan a Claude Code MCP Configuration.

A short CLAUDE.md note can point Claude Code at the team’s review standard, but the review result should live with the pull request. Review evidence belongs where the next reviewer will actually look.

Run the review in four passes

Use the same order each time. Consistency matters more than a clever prompt.

1. Ask Claude Code to summarize the security-sensitive surfaces in the diff: auth, authorization, input parsing, data exposure, secrets, dependency changes, migrations, logging, background jobs, and CI changes.
2. Ask it to trace the main user or system path through the changed files and name any trust boundary it crosses.
3. Ask it to inspect tests, configuration, and lockfiles for gaps or unexpected permission changes.
4. Ask it to write a review receipt with file references, commands run, findings, uncertainty, and a human decision.

That final step is the Review part of our methodology: the human owns the call, and the assistant has to show its work. A Claude Code review agent that cannot produce evidence is just another unchecked reviewer.

Capture evidence a teammate can check

The receipt should be easy to verify without replaying the whole chat. A teammate should be able to open the PR, check the cited files, rerun the commands, and understand why an issue was marked blocking or non-blocking.

A concrete GitHub PR workflow looks like this: the PR changes an OAuth callback, adds a database migration, and edits a deploy workflow. I would ask Claude Code to cite the callback handler, the migration, the tests around account linking, and the workflow file. I would also ask it to say whether it inspected logs for accidental token output.

Do not accept vague lines like “security looks good.” Ask for the path, the assumption, and the evidence. If the model is unsure, that uncertainty is part of the receipt.

Keep integrations narrow during review

Hooks can help by recording what commands ran before the receipt was produced. As of November 2026, Claude Code documents hooks as a way to run commands at lifecycle points, so they are a good fit for repeatable checks such as tests, linting, or a local secret scan.

Skills can package the review routine so the team does not rebuild the same instructions each time. Keep the skill small: scope, review passes, receipt format, and escalation rules. Do not bury product-specific secrets or live credentials inside the skill.

There is a tradeoff here. More integrations can give Claude Code better context, but every extra system makes the review boundary harder to explain. For a security review, I prefer a smaller context window with clear access over a powerful setup that nobody can audit.

Paste this review receipt into the PR

Use this as a starting point for a Claude Code security review comment. Keep it short enough that a busy reviewer will read it.

## Claude Code security review receipt

PR:
Reviewer:
Date:
Commit range reviewed:

## Scope reviewed
- Changed files inspected:
- Security-sensitive areas touched:
- External systems or MCP servers available during review:
- External systems intentionally not available:

## Commands and checks run
- Command:
  - Result:
  - Notes:

## Findings
| Severity | File or area | Finding | Evidence | Owner |
|---|---|---|---|---|
| Blocker / High / Medium / Low |  |  |  |  |

## Trust boundaries checked
- User input:
- Auth or authorization:
- Secrets or tokens:
- Data export or logging:
- Dependency or build changes:

## Limits of this review
- Code paths not inspected:
- Tests not run:
- Assumptions made:
- Questions for the human reviewer:

## Human decision
- Merge approved:
- Changes requested:
- Follow-up issue required:
- Final reviewer:

Decide when to block the PR

Block the PR when Claude Code finds a plausible path to data exposure, privilege escalation, secret leakage, unsafe deployment behavior, or a dependency change nobody can justify. Also block when the receipt cannot explain what was reviewed.

Do not block just because the model sounds worried. Ask it to point to the file, the path, and the failing assumption. If it cannot, turn the comment into a question for the human reviewer instead of a verdict.

This keeps the Claude Code code review useful without making it theatrical. The assistant can be strict about evidence, while the engineer stays responsible for the merge decision.

Further reading

• Claude Code docs
• Claude Code skills
• Claude Code hooks

Try it on one pull request

Pick one security-sensitive PR this week and require the receipt before merge. For a live exercise, bring that workflow to hands-on Claude Code security review training and turn it into a team convention.