GitHub announced on July 29, 2026 that Copilot code review can use agent skills and MCP integrations. The feature can give a review agent repository-specific instructions and access to internal tools, which may improve the relevance of a review. It also expands the security boundary: a review is no longer only a model reading a diff. It can now interpret local instructions, call tools, retrieve data, and potentially influence what reviewers trust.
GitHub documents the feature availability and configuration model. This article provides CodeRiskTools editorial guidance for evaluating the boundary; it does not claim that we independently tested GitHub’s hosted implementation, any particular MCP server, or every agent skill. Treat a completed review as evidence within a human merge process, not as a security guarantee.
What agent skills and MCP change
An agent skill is repository or organization context that can shape how a review is performed. MCP can expose tools or resources to an AI client through a defined protocol. Together, they can make a review more useful: a team might provide coding standards, a dependency inventory, a threat-model template, or a read-only issue tracker lookup. The same mechanisms can also create new trust paths if instructions are unreviewed, tools are over-permissioned, or retrieved content is treated as policy.
| Surface | Question to answer | Evidence to retain |
|---|---|---|
| Skill files | Who can edit the instructions and which branches or repositories load them? | Commit SHA, ownership rule, diff, review record, and effective scope |
| MCP tools | What actions, data, network destinations, and credentials are available? | Tool inventory, schemas, authorization, server identity, and access logs |
| Retrieved context | Can issue text, documents, tool output, or repository data contain attacker-controlled instructions? | Source, trust classification, delimiters, filtering, and test cases |
| Review result | Can a reviewer distinguish model output from verified facts? | Diff, tool calls, findings, tests, reviewer, and final decision |
Start with a bounded read-only design
Use the smallest useful tool set first. A read-only dependency lookup or repository metadata query is easier to inspect than a server that can modify files, open tickets, rotate credentials, or deploy artifacts. Separate tools by trust and consequence. A review agent should not need production secrets merely to explain a pull request, and it should not be able to approve its own recommendation.
- Allow only named repositories, branches, and data sources.
- Prefer read-only credentials with short lifetime and narrow scope.
- Keep production, customer, and private incident data outside the default review context.
- Log tool name, request identity, authorization decision, result class, and timestamp without logging secrets.
- Require a human decision before any write, merge, deployment, or exception.
Review the skill file like executable policy
Markdown is not automatically harmless because it is not a program. Instructions can change which files the agent reads, which tools it invokes, and how it frames a finding. Require an owner, code review, branch protection, and a clear precedence rule for repository, organization, and user instructions. Pin the review to the exact commit under review. If a pending review changes its skill file or tool configuration, invalidate the old decision and rerun the gate.
Look for instructions that ask the agent to ignore prior constraints, reveal hidden context, suppress a finding, treat external text as authoritative, or call a tool outside the stated task. These are review signals, not proof of compromise. The safe response is to preserve the evidence, isolate the changed instruction, and require an accountable maintainer to decide whether it is intended.
Test MCP boundaries with hostile but harmless inputs
- Inventory tools and resources. Record names, input schemas, output types, network access, filesystem access, credentials, and side effects.
- Classify every input. Mark pull-request text, issue content, repository files, dependency metadata, and tool output as untrusted unless a separate control proves otherwise.
- Attempt prompt injection safely. In a disposable repository, place harmless instructions in a comment, fixture, issue, and tool response that ask the agent to ignore policy or disclose a test marker.
- Verify authorization. Confirm the agent cannot convert that text into a privileged tool call, secret request, write operation, or approval.
- Check output provenance. Make the review show whether a statement came from the diff, a tool, a repository instruction, or model inference.
- Revoke and replay. Remove the tool permission or skill instruction, rerun the same commit, and confirm the capability disappears rather than silently failing open.
Keep review evidence separate from review opinion
A trustworthy record distinguishes facts from interpretation. Facts include the commit SHA, changed files, skill files loaded, MCP server identity, tool calls, returned records, check conclusions, and test commands. Opinion includes severity, exploitability, residual risk, and merge recommendation. Do not let a generated summary replace the underlying diff or tool evidence. When a tool is unavailable, say so; do not convert a missing result into a pass.
Failure modes to catch before enabling the feature
| Failure mode | Why it matters | Safer response |
|---|---|---|
| Unreviewed skill file in a contributor-controlled change | Review behavior can change with the code under review | Apply trusted-branch ownership and review instruction changes separately |
| MCP server has broad write access | A prompt or tool response can lead to consequential side effects | Split read and write servers; require a separate human approval |
| Tool output is treated as policy | External content can steer the agent or conceal a finding | Label provenance and treat outputs as untrusted data |
| Review says “no issues” without scope | Readers may infer coverage the configured tools never provided | Report languages, files, tools, versions, skips, and limitations |
| Logs capture secrets or private records | The evidence trail becomes a new disclosure path | Redact at collection and restrict retention and access |
FAQ
Does MCP make Copilot code review unsafe?
No single feature determines the result. MCP can be useful when servers, tools, credentials, inputs, and side effects are bounded and independently authorized. It increases the number of surfaces that need review.
Should repository instructions be trusted automatically?
No. Treat them as code-adjacent policy. Confirm who can change them, which revision was loaded, whether they can influence tool use, and whether the final reviewer saw the effective instructions.
Can a read-only MCP server still create risk?
Yes. Read access can expose secrets, private source, customer data, or sensitive issue content. It can also return attacker-controlled text that influences the review. Read-only reduces side effects but does not remove confidentiality and prompt-injection concerns.
What should block a merge?
Block when the exact revision, effective instructions, tool scope, provenance, findings, or test evidence is unclear. A missing security check is not a clean result.
Official sources and next step
- GitHub Changelog: Copilot code review agent skills and MCP — vendor announcement for general availability.
- GitHub Docs: repository custom instructions — official guidance for instruction files and scope.
- GitHub Docs: security hardening for GitHub Actions — least-privilege and secret-handling context for automation.
- Model Context Protocol specification — protocol reference; verify the current version before implementation.
For a compact starting point, use the free 5-point AI code review checklist. For a local, intent-bound review before merge, see the documented scope of the AI Change Firewall. Use the single CodeRiskTools comparison hub for scope context; none of these resources replaces human authorization or provider controls.
Approve the boundary, not just the answer
Before enabling agent skills or MCP, bind the review to an exact revision, trusted instructions, minimal tools, safe inputs, provenance, and an accountable human decision.
