Securing code written with GitHub Copilot: a review checklist

Copilot offers inline suggestions, chat, and agents that can make multi-file changes. GitHub's documentation describes the Copilot cloud agent as an asynchronous agent that can create branches, write code and open pull requests in response to assigned issues. Which of these you use decides how much code arrives without you typing it, and therefore how much you need to read.

Copilot does not change your app's trust boundary. Code that ships to the browser is public, and access control has to live in server-side code and database rules. What Copilot changes is the speed at which unreviewed code can reach your main branch. The boundary to guard is the merge.

GitHub's responsible use documentation is explicit. It says suggestions can look valid without being correct, that code may not always be secure, and that you should always review suggestions before accepting them and validate them afterwards. For the cloud agent it says you are ultimately responsible for reviewing and validating what it generates.

These searches look for secret-shaped strings and risky patterns in files and in git history. A completion can copy a key from an open file into another file, so search the whole tree and not only the files you remember editing. Adjust the patterns and the audit command to your stack.

git ls-files | grep -E "\.env|\.pem$|credentials"
grep -rnE "sk_live_|AKIA|BEGIN PRIVATE KEY|service_role" --exclude-dir=node_modules --exclude-dir=.git .
git log --all -p -S"sk_live_" | head -50

grep -rnE "query\(.*\+|query\(`.*\$\{" --include="*.ts" --include="*.js" src
npm audit

GitHub documents several built-in controls for the cloud agent. It only has access to the repository where it is creating a pull request. It can push only to a single branch, so it cannot push directly to your default branch. Actions workflows triggered by its pull requests require approval from a user with write access before they run. A firewall is enabled by default to limit data leaving its environment. During generation it analyses new code using CodeQL, secret scanning and dependency analysis and attempts to resolve issues.

Those controls limit what the agent can do to your repository. They do not decide whether the feature it built checks permissions correctly. A pull request can pass automated scanning and still return another customer's invoice to anyone who changes an id in the URL. That class of bug is found by reading the diff and by the two-account test.

GitHub's documentation describes push protection as blocking pushes that contain secrets before they reach the repository. It says push protection for users is enabled by default and stops you from pushing secrets to public repositories, while push protection for repositories requires GitHub Secret Protection and is disabled by default until an administrator enables it. Confirm both settings on your own account and repository, because a private repository is not covered by the user-level setting.

Push protection detects supported secret formats. It will not notice a hard-coded admin password or a home-made token, so it supports the manual searches above and does not replace them.

• Accepting a long suggestion because the first lines looked right.
• Approving an agent pull request on the strength of green checks without reading the diff.
• Approving workflow runs on a pull request that edits the workflow files, without reading those edits first.
• Keeping a real .env file open in the editor while working, then finding its values in a suggestion elsewhere.
• Installing a suggested package without checking that it exists under that exact name and is maintained.
• Letting chat fix a permissions error by removing the permission check.
• Assuming content exclusion applies everywhere. GitHub's docs list modes where it does not.

Require a human review on the default branch, repeat the searches before each release and keep two test accounts for regression checks. Pass condition: no secret in the tree or its history, every agent pull request has a human reviewer, and the running app refuses anonymous and cross-user requests.