GitHub Copilot's agentic autofix reaches general availability to fix vulnerabilities

GitHub announced this Thursday (October 15, 2026) that agentic autofix for code scanning alerts has left the preview phase and reached general availability (GA). In practice, this changes the button that every team using GitHub Advanced Security already knows: where there used to be a generic "Generate Fix," now there's an "Assign to Copilot" that triggers an autonomous agent to resolve the vulnerability.

The difference between the two approaches is not subtle. The old "Generate Fix" suggested a one-off patch without validating whether it actually closed the alert. Agentic autofix does what a senior developer would do when picking up a security ticket: it understands the context, navigates the repository, applies the fix, and only then confirms whether it worked.

How the agent works, step by step

According to GitHub's changelog, assigning an alert to Copilot follows a four-step flow:

1. The agent explores the relevant files in the repository, not just the line where CodeQL flagged the issue.
2. It generates a proposed fix.
3. It reruns CodeQL to validate that the fix actually closes the alert.
4. It iterates if needed, until opening a draft pull request ready for review.

The pull request comes with a summary of the fix, an explanation of why it resolves the alert, and the validation steps Copilot carried out. This matters because it addresses a common criticism of earlier autofix tools: the human developer used to receive a diff without knowing whether it had been tested or was just a guess from the model.

If the fix isn't good enough, the process doesn't end at the PR. You can comment directly on the pull request or interact with the session in the repository's Agents tab to ask for adjustments, the same way you'd ask a colleague for an extra review.

Three ways to trigger the agent

Agentic autofix isn't limited to clicking individually on an alert. GitHub has released three ways to use it:

• Alert by alert: directly on the page of any code scanning alert on the repository's default branch, by assigning it to Copilot.
• In batch: from the repository's security alerts list (or a security campaign), selecting up to 25 alerts for Copilot to resolve together in a single pull request.
• Via API: using the REST endpoint for updating code scanning alerts, setting assignees to ["copilot-swe-agent[bot]"] (which opens the door to automating this in custom vulnerability management pipelines).

The batch option is the one that most changes the routine for teams dealing with accumulated security debt: instead of opening 25 separate pull requests for 25 variations of the same type of flaw, the team receives a single consolidated PR to review at once.

The limitation nobody should ignore: default branch only

Here's the point where the announcement is more honest than most "AI that fixes things on its own" features: agentic autofix only sees alerts detected on the repository's default branch. Alerts that appear only in open pull requests, or on other branches, can't be assigned to Copilot.

This means the flow doesn't replace the security review that already happens during code review of a feature branch: it acts afterward, once the code is already on the main branch and CodeQL has already run the full analysis. For anyone thinking of using this as a single line of defense, it's worth understanding that there's still a window where the vulnerability actually makes it into the default branch before any automatic fix is proposed.

Who can flip the switch (and what it costs)

Access to agentic autofix follows a three-tier permission chain, which is typical of GitHub's enterprise AI features:

Without the policy enabled at the enterprise level, the button simply doesn't show up for anyone below in the hierarchy. It's a cascading opt-in model, consistent with how GitHub has handled other agentic Copilot features since it started charging for AI usage separately from the base subscription.

The feature is available to GitHub Code Security and GitHub Advanced Security customers on GitHub Enterprise Cloud, including the data residency variant (relevant for companies under regulations that require processing to stay within a specific region).

The detail that will show up on the bill

Unlike the old "Generate Fix," which was free, agentic autofix consumes AI Credits from the Code Security budget and GitHub Actions minutes, since running the validation CodeQL multiple times during the agent's iteration uses CI infrastructure.

AI Credits usage shows up in the "AI usage" section of the enterprise's billing and licensing, listed under the "Advanced Security" product. Teams that want fine-grained cost control can set up SKU-level budgets specifically for Code Security AI credits, preventing a spike in alerts from turning into an unexpected spike in spending.

This changes the calculation of when it's worth using the batch feature: resolving 25 alerts at once can be more efficient in Actions minutes than 25 separate runs, but each iteration of the agent (exploring, proposing, revalidating) consumes credits, so trivial alerts might still be worth fixing manually.

Where humans remain irreplaceable

The agentic autofix pull request arrives as a draft, not as an automatic merge, and that's not a detail, it's the core design of the feature. GitHub is making it explicit that technical validation (CodeQL confirming the alert closed) doesn't replace the judgment of whoever decides whether the fix is the right one for that business context.

An agent might, for example, fix a SQL injection by swapping the query for a parameterized one that technically closes the alert, but that changes an edge-case behavior that only a developer familiar with that module would notice during review. The Agents tab and the PR comment channel exist precisely for this kind of fine-tuning, which the agent alone doesn't have the business context to get right on the first try.

For applied security teams, the real gain from GA isn't eliminating human review, it's reducing the work of triage and first-pass fixing, leaving the team's time focused on deciding whether the proposed solution is the right one, instead of writing the patch from scratch.