Prompt template
A security code review prompt that traces the real attack path.
This template gives a coding agent the trust boundaries, sensitive assets, runtime, and existing controls it needs before reviewing a change. It keeps unsupported security claims out of the findings and makes exploitability explicit.
Reviewed September 22, 2026 · Templates and examples use fictitious data.
When to use this security review prompt
Use it for changes involving authentication, authorization, personal or financial data, file handling, user-controlled URLs, command execution, rendering, webhooks, or third-party dependencies. Keep the review boundary narrow enough that the agent can trace inputs into sensitive operations instead of returning a generic security checklist.
This is a code-visible review. It can identify a missing authorization check or unsafe data flow when the relevant implementation is available, but it cannot prove how production infrastructure is configured without corresponding evidence.
Reusable template
Security code review prompt
# Security review for {{change}}
## Context
- Project: {{project}}
- Language, framework, and runtime: {{language_runtime}}
- Trust boundaries and entry points: {{trust_boundaries}}
- Sensitive data or privileged operations: {{sensitive_data}}
- Existing security controls: {{known_controls}}
<instructions>
Inspect the changed code and the affected call paths. Trace untrusted input across trust boundaries into authentication, authorization, data access, command execution, rendering, logging, and external dependencies.
Report only findings supported by code or supplied evidence. Separate exploitable defects from defense-in-depth improvements. For each finding, explain the preconditions, affected asset, abuse path, impact, and smallest practical correction. Do not expose real secrets or claim that a control exists unless it is visible in the evidence.
</instructions>
<output_format>
1. Security boundary map
2. Findings ordered by severity and exploitability
3. Evidence and abuse scenario for each finding
4. Recommended correction and security regression test
5. Unverified risks and the checks needed to resolve them
</output_format>Context that changes the security result
{{change}}
The diff, pull request, endpoint, worker, or component that defines the review boundary.
{{trust_boundaries}}
Where data moves between users, services, tenants, privilege levels, or external systems.
{{sensitive_data}}
Credentials, personal data, payment information, private files, or privileged operations at risk.
{{known_controls}}
Visible validation, authorization, encryption, rate limiting, isolation, and monitoring already in place.
Filled example: a file download endpoint
Change: Add GET /documents/:id/download to a multi-tenant API.
Runtime: TypeScript, Node.js, PostgreSQL, and object storage with signed URLs.
Trust boundaries: Browser to API, API to database, and API to object storage.
Sensitive data: Private customer documents and tenant identifiers.
Known controls: Session authentication middleware and a ten-minute signed URL.
A useful review should trace how the requested document is scoped to the authenticated tenant before a signed URL is created. It should not report “missing encryption” unless the supplied code or configuration supports that claim.
What a useful finding contains
- A precise code path and the boundary it crosses.
- The attacker prerequisites and affected asset.
- Impact separated from likelihood and exploitability.
- A correction that fits the current architecture.
- A regression test that reproduces the abuse scenario.
Keep the review honest
Do not paste credentials, production tokens, or personal data into the prompt. A code review is not a penetration test, dependency audit, or infrastructure assessment. Keep unverified risks labeled and validate high-severity findings independently before acting on them.