A pull request fixes an authorization bug by moving a tenant check into a shared middleware function. The unit tests pass, and the automated reviewer praises clearer error handling. A human reviewer then notices that one background job bypasses the middleware and can still read another tenant’s records. This does not make Copilot code review useless; it shows why AI suggestions must join a layered review process that checks business invariants, threat boundaries, and independent tests.
The official Copilot code-review documentation explains AI-generated pull-request feedback and supported review surfaces. GH-300 includes code review, coding assistance, pull-request summaries and customizable review standards. Product policies affect whether automatic reviews are enabled and whether specific integrations are allowed. A review comment is evidence of a possible issue, not an automatic approval to merge.
Define review success before asking for comments
A good review begins with the change's intent. For the tenant middleware patch, write down which request paths are affected, how tenant ownership must be verified, and which callers might not use HTTP middleware at all. Without those conditions, an automated review may focus on null checks and naming while missing the security property the change was supposed to enforce.
A pull-request description should distinguish accepted behavior changes from incidental refactoring. Reviewers then have a stable target for examining whether each modified file is necessary. The source-based software security lifecycle is helpful here: security review should test the intended control, not merely assess surface-level code style.
Use Copilot review for breadth, not authority
An automated reviewer can identify suspicious conditions, error handling, repetitive code, missing tests, or performance concerns. It can also produce false positives or miss context that lies outside the visible diff. Treat each suggestion as a hypothesis: determine what code path triggers it, whether the finding is reproducible, and which test or design rule supports the proposed fix.
Avoid applying every suggested change in one batch. A recommendation to change an exception to a generic catch could suppress errors needed for incident diagnosis. A suggestion to cache authorization results could extend access after revocation. Check the proposed mitigation against actual service-level expectations rather than accepting it because the explanation is persuasive.
Understand the default review and approval boundary
Depending on settings, Copilot may leave comments that do not count toward required human approvals; enabled options and organization policy can change this behavior. Review the actual branch-protection and review configuration, not a generic claim that “the bot approved it.” GitHub's how-to for review requests explains supported request and re-review workflows.
Protected branches should retain independent CI and appropriate reviewer permissions. A comment from Copilot is not equivalent to running deployment tests, signing an artifact, or confirming legal approval. If a repository enables additional automation, record what it can actually do and how a maintainer can stop an unsafe merge.
Customize review criteria without hiding the diff
Repository or path-specific instructions can ask reviewers to consider compatibility, test style, or known security-sensitive directories. For example, a payment service might require explicit checks for idempotency keys and logged secrets. Such instructions can increase relevance, but they do not make the AI aware of every private policy or runtime behavior. Make critical controls enforceable in code and CI as well.
The instructions and MCP analysis describes how structured context can improve reviews while introducing new data and permission boundaries. An MCP tool that exposes a separate issue tracker can add useful context; it can also return untrusted issue descriptions. Treat retrieved content as evidence, not as an instruction to run commands.
Include tests for the security property, not just the implementation
For tenant isolation, create a test with two synthetic customers and an authenticated background worker. Confirm that a request for the other tenant's data fails, even when the same worker can access its own tenant. Test the API path and the background-job path separately. Then add regression coverage for the original exploit mechanism.
Ask Copilot to identify untested edge cases, but review the expected outcomes independently. A generated test that asserts the vulnerable behavior will pass both before and after an inadequate fix. The test-generation discipline explains why tests are only meaningful when they capture the business requirement, not merely re-express current code.
Resolve disagreements through evidence
If a reviewer says a loop can divide by zero, construct a representative input and check the branch guard. If it warns about a high-severity vulnerability, confirm the exploit path, service permissions, and any compensating controls. A false positive should be explained and resolved, not ignored without context; a true positive needs a verified fix and review.
Run a re-review after substantive changes where the repository supports it. Compare what changed in the diff and ensure prior comments still apply. The most productive review process uses AI to surface candidate problems, human expertise to evaluate risk, and automated tests to prove properties that can be checked mechanically.
Protect supply-chain and deployment boundaries
A pull request can change dependency versions, workflows, package scripts, permissions, secrets handling, and release configuration. These can be more dangerous than a code line that appears within the product interface. Inspect CI workflow and dependency changes with the same rigor as application logic, especially when an agent generated them. Preserve branch rules and secret scanning as independent gates.
GH-300 readiness is the ability to describe what Copilot code review contributes and what it cannot guarantee. Useful AI feedback shortens discovery time, but accountability still belongs to the team that understands the threat model, approves the change, and operates the resulting software.