💻 computer science

Autonomous System Vulnerability Remediation: A Survey of Agentic AI, Reinforcement Learning, Benchmarks, and Operational Safety

This survey synthesizes emerging research on autonomous vulnerability remediation across diverse computing environments, organizing the literature into six key streams and a formal closed-loop task model to highlight critical themes, operational safety mechanisms, and significant research gaps in deploying agentic AI and reinforcement learning for secure system repair.

Original authors: Abanisenioluwa Orojo, Webster Elumelu, Emmanuelli El-Mahmoud, Erika Leal

Published 2026-07-14

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Abanisenioluwa Orojo, Webster Elumelu, Emmanuelli El-Mahmoud, Erika Leal

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine your computer network isn't just a bunch of wires and servers, but a giant, bustling city. In this city, "vulnerabilities" are like hidden cracks in the sidewalks or unlocked doors in buildings. Traditionally, when a security guard (a human) found a crack, they'd write it on a clipboard, wait for a manager to sign off, and then send a repair crew to fix it. This is slow, and sometimes the repair crew accidentally breaks a water pipe while fixing the sidewalk.

This paper is a survey—a big map—of a new, exciting idea: What if we gave the city a team of robot repair crews that can think, plan, and fix things themselves?

The Main Discovery: Robots That Can Actually Fix (Not Just Talk)

The authors, a team of researchers from Baylor University and Georgia Tech, looked at 470 different research papers to find the good stuff. After a strict filter, they found only 28 papers that actually showed robots doing the heavy lifting of fixing system cracks, not just pointing at them.

Their main finding is that we are moving from "static playbooks" (robot scripts that only do one thing if a specific alarm goes off) to Agentic AI. Think of Agentic AI as a robot that doesn't just follow a recipe; it can taste the soup, realize it needs salt, grab the salt shaker, add it, taste it again, and decide if it needs pepper.

These "agents" can:

Look around: Scan the system to see what's broken.
Think: Figure out why it's broken and what the best fix is.
Act: Actually change the settings, install a patch, or lock a door.
Check: Verify that the fix worked and didn't accidentally break the internet or the coffee machine.

What This Paper Says "No" To

The authors are very strict about what counts as a "robot repair crew." They explicitly rule out a few things that might sound cool but aren't quite there yet:

Just Detecting: If a robot just screams "There's a crack!" but doesn't fix it, that's not the focus. That's like a guard pointing at a hole but never calling a repairman.
Fixing Code Only: If a robot only fixes a typo in a single line of computer code (like a writer fixing a spelling mistake in a book), that's different. This paper is about fixing the whole building (the operating system, the cloud, the network), not just the words on a page.
Old-School Scripts: If a robot just runs a pre-written list of commands without thinking about the current situation (like a vending machine that only dispenses soda if you press button A), that's "automation," not "autonomy." The paper wants robots that can reason and adapt.

How Sure Are We? (The "Simulation" vs. "Real World" Check)

The authors are honest: this field is brand new. They are suggesting that this is the future, but they haven't proven it works perfectly in every real-world city yet.

The Good News: In simulations (like video game worlds called "Cyber Ranges" or "CybORG"), these robot agents are getting pretty good at playing defense. They can learn to block attackers and fix holes in a safe, fake environment.
The "Real World" Gap: When it comes to fixing real, live company servers or cloud systems, the evidence is still small. Some studies show robots can fix configuration files (like the settings for a Kubernetes container), but they often stop at "suggesting" the fix rather than applying it and checking if the service still works.
The Confidence Level: The paper says the evidence base is "coherent enough to survey" but "remains small." They aren't calling it a solved problem. They are saying, "We have a few working prototypes and some great ideas, but we need to make sure they don't accidentally crash the power grid before we let them run the whole city."

The Five Superpowers (and the Five Weaknesses)

To be a true "Autonomous System Repair" robot, the paper says it needs five superpowers. Currently, most robots only have a few of them:

State Acquisition: The robot needs to know exactly what the city looks like right now. Weakness: Often, the robot only sees a clean, perfect picture, not the messy, real-world data.
Grounding: The robot needs to know the rules (laws, policies, safety limits). Weakness: Sometimes the robot guesses (hallucinates) a fix that breaks the rules.
Planning: The robot needs a step-by-step plan. Weakness: Robots using Large Language Models (LLMs) are great at writing plans but sometimes make up steps that don't exist.
Guarded Execution: The robot needs to be careful when it touches things. Weakness: Many studies skip the "safety gate" where a human checks the plan before the robot acts.
Verification: The robot must check its work. Weakness: This is the biggest gap. Did the robot fix the hole, or did it just paint over it? Did it break the service while fixing the hole?

The "Safety Net" Problem

The paper emphasizes that if a robot tries to fix a server and accidentally shuts down the company's website, that's a disaster.

Rollback: The robot needs a "Undo" button that works instantly.
Human in the Loop: For big, scary changes, a human should probably give the "Go" signal. The paper suggests that the best future systems will be hybrids: a smart robot that does the thinking and the heavy lifting, but a human or a strict safety rule that holds the "kill switch."

The Bottom Line

The authors conclude that we are standing at the edge of a new era. We are moving from robots that just watch and report to robots that can fix and verify. But before we let them run our entire digital infrastructure, we need better "training grounds" (benchmarks) that test not just if the robot can fix the hole, but if it can do it without breaking the rest of the city.

They propose a new "Task Model" (a recipe for success) that includes steps like Observation, Diagnosis, Planning, Safety Gating, Execution, and Verification. If a robot skips any of these steps, it's not ready for the big leagues.

In short: The robots are learning to be mechanics, but they still need a human supervisor to make sure they don't take the car apart and leave the engine on the driveway. The future is bright, but the road is still under construction.

Technical Summary: Autonomous System Vulnerability Remediation

Problem Statement

Vulnerability remediation represents the critical operational intersection between cyber risk management and change management. While detection and prioritization have become highly automated, the final step of remediation remains slow and manual. This is due to the inherent tension between removing vulnerabilities (e.g., applying patches, hardening configurations) and maintaining service continuity. A patch may fix a Common Vulnerability and Exposures (CVE) but inadvertently break a service by invalidating dependencies, or configuration hardening may block legitimate workflows.

Current automation often relies on static playbooks or human-led patch queues. While Large Language Models (LLMs), Multi-Agent Systems (MAS), and Reinforcement Learning (RL) offer new capabilities for reasoning about system state and selecting defensive actions, the field lacks a unified understanding of how these technologies can safely execute system-level changes. Existing literature is fragmented, often conflating detection-only tasks, source-code repair (Automated Program Repair), or abstract cyber-defense simulations with the concrete requirements of enterprise system remediation. There is a need to define what constitutes "autonomous remediation" in a production context, where the target is a running system, network, or cloud configuration rather than isolated source code.

Methodology

This paper presents a survey of the emerging field of autonomous system vulnerability remediation. The authors employed a rigorous review protocol based on PICOS (Population, Intervention, Comparator, Outcome, Study type) criteria to screen a corpus of 470 records.

Inclusion Criteria: The study focused on system-level vulnerabilities (enterprise IT, cloud, containers, networks, OS) where agents perform adaptive reasoning to select, execute, and verify remediation actions. It required evidence of execution (not just recommendation) and comparative or empirical outcomes.
Exclusion Criteria: The authors excluded source-code repair (unless it involved system-level deployment), detection-only studies, static playbooks without adaptive reasoning, and non-empirical product marketing.
Screening Outcome: After screening, 28 records were identified as core evidence. These were categorized into six evidence streams:
1. LLM-based configuration and Infrastructure-as-Code (IaC) remediation.
2. Autonomous cyber-defense (ACD) agents in cyber ranges.
3. Reinforcement learning (RL) for vulnerability and patch management.
4. Agentic Security Orchestration, Automation, and Response (SOAR) and self-healing.
5. Traditional automation and human patching practices.
6. Benchmark infrastructure.

The authors synthesized these streams to identify recurring themes, formalize a task model, and analyze architectural patterns and safety mechanisms.

Key Contributions

1. Formal Task Model for Autonomous Repair

The paper proposes a closed-loop task model that formalizes autonomous system repair as a tuple $E = \langle S, F, K, P, A, C, V_s, V_o, H \rangle$ , representing System state, Findings, Knowledge, Policy, Actions, Constraints, Security Verifier, Operational Verifier, and Human approval.

This model defines a nine-step task family (T0–T9) that an agent must navigate:

Intake & State Reconstruction: Gathering asset graphs, logs, and scanner data.
Diagnosis & Scope: Identifying root causes and blast radius.
Intent Selection: Choosing between patching, configuring, isolating, or compensating.
Plan Synthesis: Generating executable plans with rollback strategies.
Safety Gating: Enforcing policy, maintenance windows, and approvals.
Execution: Applying changes via administrative tools.
Verification: Confirming vulnerability removal and service health.
Recovery: Executing rollbacks if verification fails.
Evidence: Capturing an auditable bundle of the entire process.

2. Capability Taxonomy

The authors decompose autonomous remediation into five core capabilities, analyzing how different evidence streams address them:

State Acquisition: Building a current view of assets and dependencies.
Grounding: Connecting observations to policy, knowledge graphs (e.g., ATT&CK, CVEs), and organizational constraints.
Planning: Selecting action sequences under risk and cost constraints (often using LLMs for context and RL/optimization for policy).
Guarded Execution: Applying changes with least-privilege, canary deployments, and rollback hooks.
Verification: Proving both security efficacy and service continuity.

3. Evidence Stream Synthesis

The survey maps the maturity of the field across six streams:

LLM/IaC Remediation: Shows high potential for generating concrete fixes (e.g., Kubernetes YAML, Terraform) but often lacks runtime service regression testing.
ACD Agents: Strong in sequential decision-making under adversarial pressure (e.g., CybORG, CAGE) but often abstracts away specific package management and service dependencies.
RL Patch Management: Effective for optimizing patch timing and resource allocation but rarely executes end-to-end system changes.
Agentic SOAR: Provides operational workflows for investigation and response but often blurs the line between incident containment and root-cause remediation.

4. Benchmark and Evaluation Agenda

The paper critiques current benchmarks for often rewarding security success in isolation (e.g., blocking an attack) while ignoring operational safety (e.g., service downtime). It advocates for joint scoring where a remediation is only successful if it removes the vulnerability and preserves service health. It highlights SysRepair-Bench as a promising direction that combines proof-of-concept exploit checks with service regression tests.

Results and Findings

Maturity Gradient: The field is fragmented. Traditional automation is mature but lacks adaptability. RL and cyber-range agents are strong on decision logic but weak on concrete system semantics. LLM-based IaC repair is close to practical application but struggles with runtime validation.
Safety Gaps: Most studies under-report safety mechanisms. Critical elements like rollback success rates, failed deployment rates, and "blast radius" estimation are rarely measured as first-class outcomes.
Hallucination Risks: In LLM-based remediation, generated fixes may pass static syntax checks but fail semantic correctness or break dependencies.
Human-in-the-Loop: The most credible deployment path involves human oversight not as a bottleneck, but as a safety gate for high-risk changes, with agents handling evidence preparation and low-risk execution.

Significance and Claims

The paper claims that autonomous system vulnerability remediation is an emerging, coherent field that requires a shift from "detection-only" or "static automation" to adaptive, closed-loop repair.

Its primary significance lies in:

Defining the Scope: It clearly distinguishes system-level remediation (changing running systems) from source-code repair and incident containment, establishing a precise boundary for research.
Formalizing the Problem: By introducing the closed-loop task model and the objective function (minimizing residual risk while maximizing service continuity), it provides a common vocabulary for evaluating disparate approaches.
Safety-First Perspective: It argues that for agents to change production systems, the field must move beyond "fixing bugs" to "proving safety." This requires rigorous verification, rollback semantics, and evidence bundles that support accountability.
Hybrid Architecture: The authors conclude that the most promising path forward is not a single model (e.g., pure LLM or pure RL) but a hybrid control plane. This architecture combines LLMs for context interpretation and exception handling with constrained planners, policy-as-code validators, and deterministic execution wrappers to ensure safety.

The paper concludes that while the evidence base is currently small, it is sufficient to identify a clear research agenda: developing benchmarks that test both security and service health, creating shared task schemas for interoperability, and building safety cases that treat autonomous remediation as a high-stakes control problem.