Copilot CLI security review moves AI code checks to the local diff

AI 요약

• What happened: GitHub added a dedicated /security-review command to Copilot CLI as an experimental public preview.
  • The command reviews local changes, returns high-confidence security findings, and attaches severity, confidence, and fix suggestions inside the terminal.
• Workflow shift: security review is moving closer to the pre-commit diff, before a developer writes the PR description or waits for CI.
• Watch: GitHub says the feature complements CodeQL, Dependabot, and secret scanning instead of replacing them.
  • Teams still need their own rules for false positives, cost, and when an AI finding should become a blocking gate.

GitHub announced a dedicated security review command for Copilot CLI on June 10, 2026. The command is /security-review. GitHub describes it as an experimental public preview that lets developers inspect local code changes from the terminal before they commit.

This is not a large model launch. For teams already using AI coding tools, it is a more practical product move. When an agent produces a diff and the first serious review happens in a pull request, the feedback loop is slow. CI-based SAST, secret scanning, and dependency checks may still run, but the developer has already written the PR description, requested review, and moved context elsewhere. GitHub is putting /security-review where the cost of asking a security question is lower: the local diff.

GitHub's announcement keeps the scope narrow. The command analyzes the current changes and returns high-confidence security findings. Each finding can include severity, confidence, and a suggested fix that can be applied without leaving the terminal. GitHub names injection flaws, cross-site scripting, insecure data handling, path traversal, and weak cryptography as examples of the vulnerability classes it is trying to catch. This is not a general "I dislike this style" review surface. It is a security-specific pass over the code the developer is about to submit.

That makes /security-review different from Copilot CLI's existing /review command. GitHub Docs describe /review as a general code review surface for code changes and pre-commit feedback. The new command narrows the purpose and output format to vulnerability detection. Instead of relying on a developer to prompt "act like a security reviewer," Copilot CLI now carries a product-level shortcut for that job.

GitHub also announced on June 10 that Copilot Chat can see Copilot cloud agent session logs. Chat can pull in what a cloud agent did in a PR, what it validated, and why it made a particular change. It can also search past agent sessions by topic, title, or recency. The two releases are separate, but they point in the same direction: Copilot is being shaped around generated work that can be reviewed, searched, and explained after the agent has acted.

The same pattern appears in GitHub's early June announcements. On June 2, GitHub introduced Copilot cloud agent automations, which can schedule tasks such as fixing nightly failing tests, triaging new issues, or opening weekly release-note PRs. On June 4, it opened the Agent tasks REST API in public preview for Copilot Pro, Pro+, and Max users. The API lets developers start cloud agent work and track progress from scripts or internal tools. /security-review becomes one checkpoint in a broader agent workflow: start work, produce a diff, inspect the diff, preserve logs, and then ask humans or CI to make the final call.

One of the most useful lines in the GitHub announcement is that the command "doesn't rely on GitHub code scanning, Dependabot, or GitHub secret scanning." That does not mean those systems are obsolete. GitHub presents the new command as a complementary, lightweight, on-demand review. Code scanning is strong at static analysis rules and SARIF workflows. Dependabot handles vulnerable dependencies and version updates. Secret scanning focuses on credentials. /security-review uses Copilot to read the current diff in context and ask whether the changed code resembles a high-risk vulnerability pattern.

That distinction matters for security teams and development teams. If a security organization treats /security-review as a CI gate, it will overstate what a preview command can do. A single AI review pass cannot replace SAST, SCA, secret scanning, threat modeling, or manual review for sensitive code paths. If developers dismiss it because CI will run later, they miss the point of a pre-commit tool. Its best position is not a final approval gate. It is an early question that can stop obviously risky code before it becomes a PR conversation.

GitHub's custom agent documentation for Copilot CLI shows that this direction did not appear from nowhere. Developers can create custom agents with .agent.md files, and GitHub uses a security expert agent as an example. That agent is described as looking for secret exposure, XSS, SQL injection, vulnerable dependencies, authentication bypass, and related issues. /security-review productizes part of that prompt pattern into a shorter command with default behavior.

For developers, the value is concrete. First, the review request has less friction. The developer does not have to rewrite a security prompt for every risky change. Second, the command is diff-centered. Reviewing only what changed is usually cheaper and less noisy than asking an AI to inspect an entire repository. Third, the suggested fixes live in the same terminal session where the developer is already editing, testing, and committing. That reduces the context switching between an IDE, the GitHub UI, a security dashboard, and a documentation tab.

The same qualities create limits. A local diff reviewer does not necessarily know the full permission model, deployment topology, data classification policy, runtime user, reverse proxy configuration, or object storage rules. A path traversal candidate may be critical in one service and mostly unreachable in another. A weak-looking cryptographic primitive may be present only for temporary legacy-protocol compatibility. Severity and confidence scores are useful because they give reviewers a triage signal, but they should not be treated as automatic approval or rejection rules.

Community discussion around the exact /security-review announcement was still limited after launch. Nearby Hacker News threads are more revealing than the small amount of immediate coverage. A recent discussion about AI agent permission fatigue focused on what happens when agents operate near a local checkout, a GitHub token, a development backend, or a VPN. Participants debated separate checkouts for agents, sandboxing, final human diff review, and the risk that generated scripts can run later outside the sandbox. That is the environment where a pre-commit security review command will actually be used.

Another Hacker News thread about Copilot usage-based billing surfaced a different concern: long AI reviews can produce false positives and cost surprises. One commenter described asking Copilot for a broad security review that ran for close to an hour and produced mostly false positives. That anecdote is not a product benchmark, but it explains why GitHub emphasizes high-confidence findings. Security review quality is not measured by the number of warnings. It is measured by whether developers keep the command in their workflow because the warnings are worth reading.

The competitive frame is also narrower than a generic AI security product race. Arm's Metis, Claude Code Security-style workflows, Snyk, Semgrep, CodeQL, and specialized review agents all attack adjacent problems. Some aim at deeper codebase inspection, SARIF triage, or security-research-style patching. GitHub's command has a smaller job: give Copilot CLI users an easy pre-commit security pass on the diff they are already about to submit. Specialist tools may own depth. GitHub is trying to own the workflow location.

Enterprises may be tempted to turn this into an immediate rule: every PR must show that /security-review ran. That may be useful later, but the first step should be measurement. Teams need to track which vulnerability classes produce real findings, how often results overlap with CodeQL or secret scanning, how many findings are false positives, and whether PR review time decreases. Without those numbers, a required AI review can become a ritual where developers paste a command output into a checklist and move on.

Individual developers can still use the feature sensibly today. It is most useful after touching authentication, file upload, URL redirects, template rendering, shell commands, SQL queries, path construction, encryption helpers, or data-handling code. It is less useful on every copy edit or CSS spacing change. AI tools are still poor at deciding when not to ask a question. The human developer still needs to recognize which diffs carry security risk.

GitHub's June release cluster shows Copilot moving from code generation into operations around generated work. Cloud agent automations let agents start tasks on a schedule. The Agent tasks REST API lets teams connect those tasks to internal portals and scripts. Copilot Chat's session-log support makes completed agent work explainable after the fact. /security-review is a checkpoint inside that chain. The agent writes or edits code, automation repeats the work, logs make the work inspectable, and a security pass moves closer to the authoring step.

That does not remove developer responsibility. It makes the responsibility more explicit. A person may not write every line, but someone still has to know which changes are risky, which tool should run at which point, and whether an AI finding should be accepted, ignored, escalated, or converted into a test. The value of /security-review is not that it replaces a security reviewer. It is that it forces the security question to appear earlier, before the PR queue and CI pipeline absorb a risky diff.

The practical checklist for Copilot CLI teams is therefore broader than "turn on the command." Re-map the roles of pre-commit review, PR review, code scanning, dependency updates, and secret scanning. Put /security-review at the front as a lightweight prompt for risky diffs. If the same finding appears repeatedly, move the lesson into repository instructions, a custom agent, a CodeQL query, or a regression test. If a finding is repeatedly wrong, document the exception so developers do not relearn the same triage every week.

GitHub is explicit that the command is experimental. That label is a usage hint, not only a warning. The right experiment is not whether an AI can shout more vulnerability names than a linter. The right experiment is whether a product can point to the exact diff that deserves a pause. As AI coding speeds up, the bottleneck is less likely to be generating code. It is deciding when generated code should stop, who should review it, and which signal is strong enough to block it.