Agentic autofix: When GitHub’s AI fixes security findings and you review the draft

Imagine your IT team receives a list of open warnings from a security scanner: a possible SQL injection here, an unsafe file access there, 25 findings in total. Nobody wants to spend afternoons working through that list, which is exactly why such findings sit untouched for weeks in many companies. On October 15, 2026, GitHub declared a feature generally available in its official changelog that targets this very spot: “Agentic autofix” for code scanning alerts.

The flow is quickly told. An alert is assigned to the AI agent Copilot. The agent looks at the affected files, proposes a fix, runs the scanner CodeQL again to check whether the alert really goes away, and finally opens a draft pull request. A human reads that draft and decides. This article sets out what the source documents, which prerequisites apply, what it means for a company with ten to 250 employees, and why the real value of this announcement lies not in the code but in the pattern behind it.

What GitHub published on October 15, 2026

The primary source is the entry “Agentic autofix for code scanning alerts general availability” in the GitHub changelog dated October 15, 2026. The key statements, as far as they appear there:

• The feature is available to customers of GitHub Code Security and GitHub Advanced Security on GitHub Enterprise Cloud, explicitly including Enterprise Cloud with data residency, meaning data storage in a chosen region.
• A code scanning alert is assigned to Copilot. Copilot examines the relevant files, creates a fix proposal and validates it by running CodeQL again. It iterates where needed.
• Copilot then opens a draft pull request with a summary, a rationale and validation steps. Further changes can be requested through comments on the pull request or in the repository’s “Agents” tab.
• You can assign a single alert on the default branch. Alternatively, you can select up to 25 alerts in the alert list to be handled together in one pull request, or use a security campaign. The REST API is also possible. Alerts that occur only in pull requests or other branches cannot be assigned.
• The former free “Generate Fix” button is replaced by “Assign to Copilot”.

Three prerequisites are named in the source. First, an enterprise administrator must enable the “Agentic autofix” policy in the Advanced Security policies. Second, an organization or repository administrator can then switch the feature on in the code security settings. Third, a Copilot billing method must be in place.

There is also a cost statement: usage consumes AI credits from the code security budget as well as GitHub Actions minutes. AI credit usage appears in enterprise billing under “AI usage” as the product “Advanced Security”, and budgets can be set per SKU. The source does not say what a single fix costs. You should therefore not adopt any such figure from anywhere as a given.

Availability: what “generally available” really means here

“Generally available” sounds like a button anyone can press. That is not the case here. The status is GA, but the feature is tied to prerequisites many mid-sized companies do not meet: an Enterprise Cloud contract with GitHub, plus Code Security or Advanced Security, plus an enabled policy and a billing method on file. If you manage your code on a smaller plan, or not on GitHub at all, you cannot simply switch on autofix today.

On region, the source says Enterprise Cloud with data residency is included. The entry names no country restriction. It also contains no explicit statement about Germany, Austria or Switzerland. Put honestly: for customers who have the named packages, there is no visible regional exclusion. Nothing more can be derived from the source.

For your assessment this means: for companies with a suitable GitHub contract, agentic autofix is now a feature their IT can evaluate and introduce. For everyone else, the pattern is coming your way, also in other tools, and you can prepare for it now. We come to that below.

The pattern behind the announcement: the agent checks itself, the human decides

What stands out is not that an AI writes code. That has been routine for a while. What stands out is the order of steps: first a proposal, then an independent check against an existing tool, then refinement, and only at the end a result prepared for humans, with summary, rationale and validation steps. The human does not receive “here is a change”, but “here is a change, here is why, and here is how we checked that it works”.

An agent that tests its result against an independent checking tool and hands the human the rationale is far easier to control than one that only reports “done”.

This pattern is not limited to software. Think of an agent that pre-sorts incoming invoices, prepares quote drafts or answers customer inquiries. The same question arises everywhere: is there a second, independent checking tool against which the agent tests its own result before a human sees it? And does the human get enough information to decide quickly and safely, rather than just nodding along?

A clean distinction matters here. CodeQL re-checking the agent’s fix is an internal quality loop. It is not a human approval. The source explicitly describes the pull request as a draft that lands in a review. That is the point where a human decides whether the change reaches your product. This step remains indispensable, especially for code that touches customer data, payments or production control.

What this means for a company with 10 to 250 employees

Three things matter from a management perspective.

First: unattended security findings are a risk that can be reduced. If the first draft of a fix no longer has to be written by hand by a developer, the hurdle to touching findings at all drops. That is a plausible benefit. The source gives no reliable figure for how many hours this saves, and we do not invent one here. If you want to do the math, do it with your own numbers: how many open findings sit in the backlog today, and how much time does one finding cost on average?

Second: the review work does not disappear, it shifts. Instead of writing code, your developer now reads drafts. That can be faster, but it requires someone to have the time and the competence. A draft nobody reads seriously is worse than none, because it creates a feeling of security without delivering it.

Third: costs depend on usage. AI credits and Actions minutes keep running. That is no argument against the feature, but it is a reason to set a budget up front. The source explicitly notes that budgets can be set per SKU.

Assignment: the Code-Operator

On amazing-agents.com we describe our Code-Operator as the agent for bugs, fixes and pull requests with your approval. The pattern in GitHub’s announcement fits that picture exactly: the agent prepares the work, a human approves. We stress the assignment deliberately because it hits the core of what matters. A feature like GitHub’s agentic autofix is one example of how a vendor builds this division of labor into its product. Whether you use it or build your own process, the basic question stays the same.

Agent with limits and an approval step: without and with

To make the difference tangible, consider a thought experiment with two variants of the same flow.

Without an approval step: The agent detects a security finding, writes a fix and merges it directly into production code. The internal check by the scanner says the finding is gone. What it does not say: whether the change breaks something elsewhere, whether it makes sense functionally, or whether it touches rights the agent should never have touched. The error only surfaces when a customer reports it.

With an approval step: The agent detects the finding, prepares the proposal, checks it against the scanner and presents a draft with rationale and validation steps. A human reads it, asks follow-up questions in the comment field if needed, and decides whether the change is adopted. The agent has done the legwork, the responsibility stays with you.

This second flow corresponds to what the source describes, and to how we design agents in general: with clearly named limits, meaning what the agent may and may not do, and an approval step before anything that has external effect or is hard to reverse.

How we proceed in the audit

We do not claim figures from customer projects here, but describe how we approach the question when you want to introduce an agent for technical processes. In the free strategy call we typically proceed in five steps:

1. Record the process. We ask you to show how security findings, error reports or change requests are handled today: who sees them, who works on them, how long it takes.
2. Separate the tasks. We distinguish what an agent can prepare (proposal, summary, check) from what a human must decide (adoption, publication, payment).
3. Define the checking tool. We clarify against which independent tool the agent tests its result. In GitHub’s case that is CodeQL.
4. Name the approval step. We define who approves, in which format the result is presented to them and what happens if nobody responds.
5. Fix limits and costs. We record what the agent may access and set a budget for usage-based costs.

The result is not an off-the-shelf product but a process plan with which you, alone or together with us, can decide whether and where an agent makes sense.

What you should prepare now

Even if your company does not meet the prerequisites for GitHub’s autofix today, preparation pays off. The following steps work regardless of the tool.

1. Take stock of open findings. Have your IT compile how many security or error reports are open today and how old the oldest are. Without this number, no benefit can be estimated.
2. Clarify the contract situation. Ask your IT or service provider which GitHub plan you have and whether Code Security or Advanced Security is included. If not, that is a decision with cost implications that you should make deliberately.
3. Define review responsibility. Name a person and a deputy who read agent drafts. Decide how much time is set aside for it.
4. Mark critical areas. Decide for which code an agent may at most make suggestions, such as payments, credentials or personal data, and write it down.
5. Clarify budget and data protection. Set a cap for usage-based costs and have your data protection officer check which data the agent processes.

What the source does not say

A clean assessment includes what is not documented. The source gives no figure for how often the agent actually fixes an alert correctly. It names no time saved and no cost per fix. It says nothing about how the agent behaves with code outside the languages CodeQL supports. And, as noted above, it says nothing explicit about Germany, Austria or Switzerland. Anyone introducing autofix should therefore start with a small, manageable area and observe how many drafts can actually be adopted without rework.

Conclusion

Agentic autofix is a real, generally available feature for companies with a suitable GitHub contract. For everyone else it is a preview. The pattern behind it is transferable and worth understanding: the agent does the groundwork, checks itself against an independent tool and presents the human with a traceable result. The decision stays with the human. That is the difference between an agent with limits and an approval step and an automatism that, in doubt, produces errors faster than any human could.

Sources

• GitHub Changelog: “Agentic autofix for code scanning alerts general availability”, October 15, 2026, github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability
• Amazing Agents: description of the Code-Operator, amazing-agents.com