Agents Please code review guide: Secure Setup Guide

The Agents Please code review guide is designed for teams using an AI agent to inspect pull requests, repositories, or isolated code samples. The goal is not to replace reviewers. It is to make review preparation faster, surface security-sensitive paths, and give human engineers a clearer list of questions to investigate.

Begin with a narrow review boundary. Identify the branch, commit, changed files, programming languages, test commands, and directories the agent may access. A restricted scope makes results easier to audit and reduces the chance that unrelated legacy code overwhelms the review.

Review boundaries

What a useful review should answer

A strong AI-assisted review should help answer five questions:

• What changed, and which behavior does it affect?
• Where does untrusted input enter the system?
• Which functions, services, or permissions receive that input?
• What evidence supports each reported issue?
• What test or patch would reduce the risk?

A report that only lists generic concerns is less useful than a shorter report with file paths, affected symbols, data-flow reasoning, and a practical verification step.

Preparation determines whether an agent produces actionable analysis or a noisy collection of guesses. Before starting, write a short review brief in plain language. Include the feature goal, expected trust boundaries, known sensitive operations, and areas that must not be modified.

For a web service, the brief may identify authentication, authorization, file uploads, background jobs, third-party requests, database writes, and model or prompt integrations. For a library, it may emphasize unsafe parsers, serialization, dependency changes, and public API compatibility.

Review brief template

A practical instruction set

Use instructions that separate discovery, reasoning, and reporting:

1. Map the changed code and its direct callers.
2. Identify external input, sensitive data, privileged operations, and network requests.
3. Trace suspicious values through validation, transformation, storage, and output.
4. Report only issues supported by code evidence.
5. Distinguish confirmed defects, plausible concerns, and questions for the author.
6. Suggest tests without applying changes unless explicitly authorized.

This structure also helps prevent a common failure mode: the agent notices a dangerous pattern but does not check whether a validator, framework control, or upstream permission already prevents exploitation.

AI code review becomes more effective when findings are ranked by exploitability and impact rather than by how alarming the wording sounds. A missing comment and a user-controlled server-side request should not receive equal attention.

Start with pathways that connect untrusted input to privileged or externally visible behavior. Common examples include request parameters reaching database queries, uploaded content reaching parsers, configurable URLs reaching HTTP clients, or user text being inserted into instructions for another model.

Finding classification

Risk triage matrix

When reviewing a suspected vulnerability, ask the agent to show the complete chain:

• Source: Where does the value originate?
• Transformation: Is it decoded, parsed, concatenated, or normalized?
• Control: What validation, authorization, encoding, or allowlist applies?
• Sink: Which operation uses the value?
• Impact: What could an attacker or malfunctioning user cause?
• Verification: What safe test demonstrates the claim?

For example, an outbound request is not automatically a server-side request forgery issue. The reviewer must establish whether an attacker can influence the destination, whether private or metadata addresses are reachable, whether redirects are controlled, and whether the application has an approved destination policy.

Similarly, a string inserted into a prompt is not automatically a successful prompt injection. The review should identify the model boundary, the authority of the generated output, the available tools, and whether untrusted content is clearly separated from system instructions.

A focused review should examine patterns that frequently create defects without assuming every match is exploitable. The following categories are useful starting points for an Agents Please workflow.

Patch review standards

A proposed fix should address the cause rather than only hide the reported symptom. Check whether it:

• Validates input at the correct trust boundary.
• Preserves expected behavior for legitimate users.
• Applies authorization to every relevant code path.
• Handles failures without leaking sensitive details.
• Includes a regression test that would fail without the fix.
• Avoids introducing a second bypass through alternate endpoints or background jobs.

The review is not complete when the agent produces a report. It is complete when the team has decided which findings are valid, assigned owners, applied appropriate fixes, and verified that the change behaves safely.

Keep accepted findings separate from unresolved questions. This prevents a long report from obscuring the small number of issues that block release. It also creates a useful history for future reviewers who may encounter the same code path.

Review completion table

A useful final report is concise but specific. For each accepted issue, include the affected component, risk, evidence, recommended fix, owner, and verification status. For each rejected issue, record the control or assumption that made it invalid. This reduces repeated investigation during later pull requests.

If the same false positive appears often, improve the review instructions or add repository guidance. If the same real defect appears repeatedly, invest in a shared helper, framework control, lint rule, test fixture, or architectural change instead of relying on repeated manual detection.