GitHub's Agentic Autofix Is Now Generally Available, and Metered

GitHub's agentic autofix for code scanning alerts is generally available, and the part that will reach a budget line before it reaches a pull request is the billing. Fixing an alert this way consumes AI Credits from the Code Security budget plus GitHub Actions minutes, and it replaces the free Generate Fix option. Teams that have been triaging CodeQL findings with a suggested patch at no marginal cost are now paying per fix, on a feature that can be pointed at 25 alerts at once.

The change was announced in the GitHub changelog on 15 October. It is generally available rather than in preview, and it is limited to a specific set of customers: GitHub Code Security and GitHub Advanced Security customers on GitHub Enterprise Cloud, including GHEC with data residency. If that is not your plan, the feature is not available to you and the rest of this article is a preview of a bill you are not yet receiving.

The flow, and why the validation step is the interesting part

The workflow starts when you assign a code-scanning alert to Copilot. From there it explores the files relevant to the alert, proposes a fix, reruns CodeQL to validate the change, iterates on the result, and opens a draft pull request with a summary of the fix and the validation steps it ran. The output is a draft, which means a human still approves it, and the pull request carries its own evidence rather than asking a reviewer to take the fix on trust.

Rerunning CodeQL is what separates this from a language model suggesting an edit. The agent has to produce a change that makes the specific query stop firing, and it has the scanner available to tell it whether it succeeded. For the common case, a tainted input or a missing sanitisation call or an injection sink that needs a parameterised query, that loop is exactly the check a reviewer would otherwise run by hand, and it happens before anyone is asked to look.

Two constraints are worth knowing before you plan around it. Autofix operates on the repository's default branch only, so an alert that exists only on a pull request or another branch cannot be assigned to Copilot at all. And the 25-alert limit is a per-run figure: you can select up to 25 alerts for Copilot to fix together in a single pull request, which is a deliberate bundling rather than 25 independent pull requests. That bundling saves review overhead and makes the cost of a single campaign easy to trigger.

The draft status is also doing real work in that flow. A draft pull request does not request review, does not trigger the same merge expectations and does not announce itself as ready, so the agent's output arrives as something to look at rather than something to approve. For a team that already gets more pull requests than it can review, that difference decides whether the feature reduces queue pressure or adds to it. Nothing merges without a person, and the person is choosing when to look.

The billing change is the consequence

Everything above is a better version of a feature that existed. The billing is what is new in a way that affects people who never touch the feature directly. The usage appears as the Advanced Security product in enterprise billing, and SKU-level budgets are available for it. Remediation has become metered work: what used to be a free suggested patch now costs AI Credits and Actions minutes per fix.

The reason to care is the combination of metering and bulk. A security manager working through a campaign can select a batch of alerts and set the agent going, and that action now has a price attached to it that scales with the batch. The cost is defensible on any reasonable reading, since the alternative is an engineer spending hours on the same fixes, but it is a variable cost that did not exist last month, and it arrives on the same budget as the security product rather than somewhere a platform team might notice it first.

There is a second-order effect that enterprise teams should think about before enabling anything. Because usage lands under the Advanced Security product with SKU-level budgets, it is visible to the people who own that budget and not necessarily to the engineers who trigger the runs. Anyone with permission to assign an alert is spending money. That is a normal arrangement for cloud resources and an unusual one for a security triage queue, and the gap between who spends and who sees the spend is worth closing deliberately rather than discovering at the end of a quarter.

Turning it on takes three decisions, not one

The gating is layered, and each layer is a different person's job. An enterprise admin has to enable the new Agentic autofix policy in Advanced Security policies. After that, organisation and repository admins can enable it for their scope. And a Copilot billing method has to exist, because the AI Credits are drawn against it.

Each of those is a place where the feature silently does not work for somebody. The pattern to avoid is an enterprise admin enabling the policy and assuming the feature is now on everywhere; the repository-level enablement is separate, and a team that never flips it will keep triaging alerts by hand while someone above them believes the rollout is done.

For teams that drive this from automation rather than the interface, the trigger is an API assignment. The assignee is a bot account, and the payload is unremarkable:

PATCH /repos/{owner}/{repo}/code-scanning/alerts/{alert_number}
{
  "assignees": ["copilot-swe-agent[bot]"]
}

That single field is the whole spend control, which is the point. If any part of your tooling can patch a code-scanning alert, whether that is a custom triage script, a scheduled job or an internal dashboard, then it can also start a metered fix, whether or not whoever wrote it was thinking about billing at the time. Audit who holds that permission before you enable the policy, not after.

What to do before you enable it

Set a budget first. SKU-level budgets exist for exactly this, and the order of operations matters: a budget configured after a 25-alert run is a report rather than a control. Decide what a month of remediation is worth in AI Credits before the first batch runs, and pick the number from the size of your alert backlog rather than from what feels reasonable. If you have 400 open findings, the ceiling is a different number from a repository with twelve.

Then decide the default-branch rule in advance. Autofix only works on the default branch, so if your workflow is to let findings accumulate on feature branches and address them before merge, this feature does not fit that workflow and no amount of configuration will make it. Teams in that position should work out whether moving remediation to the default branch is acceptable, or whether autofix is a tool for the subset of findings that already exist there.

Work out who may assign alerts, and whether that permission is the same thing as permission to spend. In many organisations today, triage is delegated broadly because the expensive action after triage was human time rather than a metered API call. That assumption is now wrong. It is worth an explicit conversation with whoever owns the security budget about who should be able to start a batch, and whether a bulk run needs a second person to approve it.

Finally, tell the people who will notice the invoice. The Advanced Security line item is about to start moving for reasons that have nothing to do with new tooling being purchased, and the first person to see it will probably be in finance. A one-line note about why that number changed is considerably cheaper than the conversation that happens without one.

What this says about security remediation as a product

The shift here is bigger than one feature. GitHub has taken the work of fixing a finding, previously an engineer reading a scanner report and writing a patch, and turned it into a metered service inside the platform that found the issue. The validation loop is what makes that credible, because it means the output is checked against the same scanner that raised the alert rather than against a reviewer's patience.

For teams, the practical consequence is that remediation now has a price per unit and a queue that can be processed at a rate you choose. That is a real improvement over remediation being unbounded human effort, and it also means the security budget is now a place where a runaway script can do measurable damage. Both of those statements are true at the same time, and the teams that get value from this will be the ones that treated the second one as a configuration task rather than a rounding error.