AWS uses AI agent to triage Linux kernel CVEs that power EC2

A problem that grew from 2 to 16 CVEs a day

In a talk in early October 2026 at the Linux Plumbers Conference, in Prague, AWS engineers Dylan Johnson and Justinien Bouron detailed how the team that maintains the Linux kernel used in EC2's infrastructure decides which vulnerabilities matter. It's a different kernel from Amazon Linux and from the kernels customers run inside their own instances: it's the one that underpins AWS's virtualization layer beneath the workloads.

The volume of Linux kernel CVEs shifted after the project became a CVE Numbering Authority (CNA) in February 2024, starting to publish its own identifiers instead of relying on third parties. Before that, AWS saw about 2 kernel CVEs a week. Afterward, the pace rose to about 16 a day, with a peak of 848 CVEs published on August 15, 2026. The kernel CVE documentation itself acknowledges that the project doesn't know how each system uses the code, so it's up to each user to decide what applies to them.

The pipeline: filter, agent, human review

AWS's process has three stages, and only the middle one uses AI:

1. Automatic filter (no AI). A script reads the JSON record of each CVE, compares the affected version and listed source files against AWS's actual kernel configuration, and discards what doesn't apply. Bouron said this eliminates about 70% of incoming CVEs, but was careful to note that the percentage depends heavily on how the kernel is configured in each environment.
2. AI agent. What remains goes to an agent that receives AWS's kernel source tree, each platform's configuration, a description of the environment and threat model, and a proprietary severity scale. It returns a table with the affected subsystem, vulnerability type, and attack vector. The team deliberately ignores CVSS, because the standard score isn't specific to AWS's environment.
3. Human review. Two engineers typically review the table produced by the agent before any decision turns into action.

The speed gap between machine and human is the data point that stands out most in the slides: the agent takes about 3.4 seconds per CVE, versus minutes of human work. Bouron said manual review is currently the slowest stage in the pipeline, and that the team doesn't intend to eliminate it.

"A pretty fancy classifier," not a judge

Johnson summed up the agent's role directly:

We're really using it as a very fancy classifier.

Dylan Johnson, AWS engineer

Bouron went further in explaining why human review remains mandatory:

We don't want to hinge our entire security posture on the output of an LLM agent.

Justinien Bouron, AWS engineer

When asked about the agent's accuracy, Bouron estimated, without presenting a formal assessment, that between 5% and 10% of the agent's decisions were problematic. That's a meaningful margin of error for whoever decides which vulnerabilities in the kernel of one of the world's largest public clouds deserve immediate action, and it's exactly why the team kept humans in the loop, even with the speed gain.

Turning off kernel features to shrink the attack surface

Beyond filtering and classifying CVEs, AWS also actively disables kernel features it doesn't use, reducing how many CVEs even apply to its environment. Bouron described this approach as "deceptively difficult": the slides list more than 32,000 configuration options, and disabling the wrong one can produce bugs or performance regressions that only surface months later. It's an advantage AWS has from controlling a closed internal environment, something Johnson acknowledged is harder to replicate in a general-purpose distribution.

Why AWS wants to move to newer LTS branches

The data presented reinforces the team's case for speeding up adoption of newer LTS (long-term support) branches. For CVEs affecting the six branches studied, the median time between a mainline fix and its arrival in the LTS release was 31.8 days for Linux 5.10 and 18.1 days for 6.18. As of September 16, 2026, there were 1,709 known unfixed CVEs on the 5.10 branch, versus 229 on 6.18. These are per-branch counts, and they don't indicate how many of those CVEs actually affect AWS's specific kernel.

Doing your own backport of fixes also carries built-in risk: Bouron pointed out that CVE records usually cite only the final commit that fixed the bug, without listing prerequisite commits. A team that applies only the indicated commit can remain vulnerable even after patching.

AWS has been shortening its own migration cycle between kernel versions:

During the migration from 5.10 to 6.12, 43% of tracked issues were resolved in userspace, when workloads depended on old kernel behavior. Johnson said the team will now run stable kernels in a test environment continuously throughout the year, migrating the fleet as soon as each new LTS ships.

What other companies are doing

Microsoft presented, at the same conference, a similar pipeline for Azure Linux: the triage verdict comes from a rules table, and AI only suggests entries for that table. The Azure team also uses agents for backporting and reported that a build-and-test loop raised the success rate of that task from about 50% to 80%.

CodeMender, from Google DeepMind (covered by InfoQ in October 2025), instead focuses on writing the fixes themselves, not on triaging CVEs. According to the project's announcement, human researchers review every patch before it moves upstream. These are three different responses to the same problem: a volume of CVEs growing faster than human teams can review on their own.

What remains open

AWS hasn't open-sourced the tools' code. Asked about this, Johnson said the team would like to explore the possibility of sharing the filter tool, the non-AI part of the pipeline, but gave no timeline or commitment. Berend de Boer, CTO of Process Focus, commented on LinkedIn about the scale of work involved in maintaining this kind of infrastructure:

Focus on what makes your business valuable to your customers.

Berend de Boer, CTO of Process Focus

For those running workloads on EC2, the pipeline described isn't something the customer configures or sees running: it's AWS handling the layer beneath the instance. But the design matters as a practical reference for any team that today receives a flood of CVEs and tries to decide what actually applies to its environment: AWS's lesson is to use AI to classify at scale, keep human review on what decides action, and not outsource the final decision to the model.