Agentic Autofix: six gates for accepting a security patch

On October 15, 2026, GitHub announced the general availability of Agentic Autofix for code scanning alerts. When an alert is assigned to Copilot, a session explores related files, generates a proposal, reruns CodeQL, iterates if needed, and opens a draft pull request. It can also group up to 25 alerts from the default branch into one assignment. This matters for teams with vulnerability backlogs: the unit of automation is no longer an isolated suggestion, but an investigation that crosses the repository and delivers a reviewable change.

The news was one Lima calendar day old when consulted on October 16. The announcement establishes the product contract and its date, not the quality of every patch or measured savings. The central distinction is this: if the query that raised an alert no longer finds its pattern, there is remediation evidence for that detector. There is not yet enough evidence that the root cause is fixed, that another path does not retain the risk, that compatibility remains intact, or that the change belongs in production. The draft pull request is a deliberate boundary: the agent prepares evidence; the team retains the decision.

Agentic remediation operates with two different oracles. The first is static: the CodeQL query describes a dangerous property and checks whether the change removes the detected flow. The second is the software's actual contract: tests, types, interfaces, business behavior, observability, and operating expectations. The first oracle can be strong without covering the second. Replacing a vulnerable command construction, for example, may close an injection path while breaking legitimate arguments, observability, or cross-platform support. No rerun of a single query proves those properties by itself.

GitHub's documentation makes the boundary explicit: Agentic Autofix works on a best-effort basis and revalidates with the code scanning suite. It cannot confirm closure for alerts raised by custom queries, the security-extended suite, or third-party tools. The suites are not interchangeable either: default prioritizes high precision, while security-extended adds lower-precision and lower-severity queries that may produce more false positives. Before a pilot, every alert needs to retain its provider, query, suite, configuration, and rule revision. Without that provenance, “CodeQL passed” may describe a different analysis from the one that found the problem.

The gates do not require the same cost for every repository. A low-impact internal service may use a short battery; a shared library, authentication, or payments require negative tests, compatibility checks, and specialist review. The non-negotiable part is that every gate has an owner, a verifiable artifact, and a blocking criterion before bulk assignments are enabled.

Imagine a service that receives a file name and builds a conversion command through concatenation. CodeQL detects untrusted input reaching an interpreter. The agent replaces the string with a call using separate arguments, reruns the query, and opens a pull request. The provenance gate passes because the same query and configuration were used. The cause gate also appears to pass: a test with shell separators no longer executes a second command.

Review finds two effects outside the detector. On Windows, the selected library interprets quoting differently; on Linux, the process no longer inherits a variable required by the converter. A cross-platform integration test fails, and a legitimate path stops processing names with spaces. The patch was not useless: it removed a real vulnerability. But it was not yet acceptable because the second oracle—the operating contract—did not pass. The team adjusts the API, adds negative and positive cases, and keeps the fix in a small PR.

This example is hypothetical and does not describe a Wasyra customer, incident, or result. Its purpose is to show why the correct agent state is “candidate validated against a detector,” not “vulnerability resolved.” That label reduces automation theater by exposing what was checked and what remains under human responsibility.

Start with a narrow lane: one or two high-precision query families, repositories with reliable tests, components without critical data, and a group of security and domain reviewers. Even though the product permits up to 25 alerts per pull request, the pilot should favor small changes. Grouping reduces sessions, but it also mixes causes, expands the diff, and makes it ambiguous which change closed, broke, or made each path more expensive. The learning unit is an attributable fix, not the volume of moved alerts.

Define exclusions before organization-wide enablement: generated code, cryptography, authentication, data migrations, public APIs, and untested components may require manual handling from the start. GitHub applies cascading controls: the enterprise allows, the organization enables, and the repository can opt out subject to the higher policy. People with write access can assign alerts once the repository is enabled. The decision is therefore not only technical; it also determines who can consume sessions, create proposals, and fill the review queue.

Budget two resources: Code Security AI Credits and GitHub Actions minutes. The useful cost is not per started session, but per accepted remediation that remains stable after merge. Record assigned alerts, opened PRs, accepted PRs, human review time, retries, CI failures, rollbacks, and reopened alerts. Without separate denominators, a drop in generation time can hide a larger increase in review effort or regressions.

Separate speed, quality, and coverage. For speed, measure time from assignment to PR and from PR to decision; the second exposes human load. For quality, use acceptance without substantial rewriting, new CI failures, rollbacks, incidents, and alert reopening. For coverage, record how many eligible alerts belong to queries the mechanism can revalidate and how many fall outside due to suite, provider, branch, or policy. Do not make closure rate the only target: a team can improve it by selecting only trivial fixes.

Run a parallel sample with comparable human remediation or, at minimum, preserve the historical baseline by query family. The comparison should control for severity, language, repository size, and alert age. Review operational false negatives: changes that pass the detector and CI but fail after deployment. No vendor benchmark in the consulted sources establishes a success rate for your code, queries, or controls; any adoption threshold must come from your own pilot.

An agent with repository access receives potentially sensitive context and may modify multiple files to resolve an alert. Custom instructions help steer the change, but they do not replace least privilege, branch protection, required review, secrets outside the environment, and network boundaries. There is also a risk of invisible debt: a patch may add a dependency, duplicate validation, degrade performance, or move the problem to another layer. The diff, session logs, and evidence for each gate should be retained for audit without copying secrets into observability.

Adopt when the pilot demonstrates three things at once: it reduces total time to a decision, maintains or improves post-merge quality, and does not create a review queue that displaces more valuable work. Scale by query families and repository classes, not with a global switch. Stop or narrow scope when rewrites, regressions, rollbacks, failed sessions, or cost per stable fix rise. General availability means the product is ready for supported use; it does not mean your organization already has an acceptance contract.

The practical conclusion is sober: let the agent investigate, propose, and gather evidence, but have the organization define what “fixed” means. If you need to design that lane—permissions, evaluations, CI, review, and observability—Wasyra's custom agent service can turn the six gates into a flow matched to your risk, without confusing it with the Agents Wasyra product.