LLM-Based Agents for Software and Systems Security: Approaches, Applications, and Assessment

Motivation

• Security workflows require agents to inspect heterogeneous artifacts, form hypotheses, invoke tools, interpret outputs, revise plans, and communicate findings across multiple steps.Examples include vulnerability analysis, penetration testing, repair, and SOC operations.Source: §1 · pp. 1–2

Challenges

• The field is difficult to compare because “agent” is used inconsistently, security applications have sharply different risks, and task success omits evidence fidelity, scope, safety, and resource use.Assessment must consider whether agents avoid hallucinations, respect tool permissions, and consume practical time and money.Source: §1 · p. 2

Survey scope

• The survey systematically reviews 100 peer-reviewed papers published from January 2023 through March 2026 across Approach, Application, and Assessment dimensions.These dimensions cover agent designs, security tasks, datasets, metrics, safety measures, baselines, and experimental protocols.Source: §1 · p. 2

Contributions

• The survey derives and applies a taxonomy enabling structured comparison of agent designs, security tasks, datasets, metrics, and baselines across the literature.Its literature search and selection protocol yields a corpus spanning the emergence of the field.Source: §1 · p. 3

Central finding

• The central finding is that the field has built agents able to act, but not yet agents whose authority is bounded or whose behavior is auditable.The paper points toward evidence-centered architecture, risk-aware autonomy, realistic and reproducible benchmarks, trajectory-level assessment, and accountable human-agent collaboration.Source: §1 · p. 3

2.1 LLM-Based Agents

• LLM-based agents extend standalone models into iterative systems that perceive observations, reason, plan, invoke tools, and learn from feedback.Their observe–reason–act loop can repeat across tool outputs, code context, and alerts before producing a final result.Source: §2.1 · p. 3

2.2 Software and Systems Security

• Software and systems security spans vulnerability management, offensive security, defensive monitoring, low-level artifact analysis, and repair or hardening across the security lifecycle.These tasks combine heterogeneous artifacts and tools, while interactive offensive workflows particularly suit agents that can plan, execute, and adapt.Source: §2.2 · p. 4

2.3 Related Work

• The survey’s distinguishing scope combines LLM-based agents, software and systems security, and a three-aspect taxonomy covering approach, application, and assessment.Prior surveys generally address LLMs as task models, software-engineering agents, offensive or defensive domains, or security of the agents themselves rather than agents as security practitioners.Source: §2.3 · p. 5
• Unlike prior surveys, this work unifies offensive and defensive orientations across eleven task categories while characterizing how agents are constructed and assessed.Its construction taxonomy covers perception, memory, action space, orchestration, and self-improvement; its assessment taxonomy covers datasets, outcome and trajectory metrics, safety measures, and baselines.Source: §2.3 · pp. 5–6
• The survey specializes general agent taxonomies for security by covering sandboxed execution, scanner and CTF integration, scope containment, and prompt-injection robustness.Source: §2.3 · p. 6
• The survey is, to the authors’ knowledge, the first systematic review focused specifically on LLM-based agents—not standalone LLMs—as instruments of software and systems security.Source: §2.3 · p. 6
• Its unified taxonomy spans how security agents are built, which security problems they address, and how they are assessed.Source: §2.3 · p. 6
• Coupling these three aspects shows that autonomy has outpaced governance and that assessment practice has not kept pace with either.Source: §2.3 · p. 6

Research questions

• The survey examines how security agents are constructed and operated, which security tasks they address across the lifecycle, and how their behavior is assessed.These questions cover agent architecture, perception, memory, reasoning and planning, action space, orchestration, self-improvement, applications, datasets, and outcome and trajectory metrics.Source: §3 · p. 6

Literature search

• The systematic search combined keyword searches, forward and backward snowballing, and manual eligibility filtering to produce a final set of 100 peer-reviewed papers from January 2023 through March 2026.The time window targets the period when LLM-based agent systems became a visible research direction while keeping the scope focused on recent work.Source: §3 · p. 6

Taxonomy and attribution

• From the selected papers, the survey derives a taxonomy spanning approach, application, and assessment, then maps each paper to the taxonomy for cross-paper synthesis.The taxonomy covers agent design and operation, addressed security tasks, and the datasets, metrics, and experimental protocols used for assessment.Source: §3 · p. 6

Synthesis and analysis

• The attributed results are analyzed to identify limitations, open challenges, and future research directions for LLM-based agents in software and systems security.This analysis also supports comparisons of agent designs and applications and identifies how surveyed works assess agent behavior.Source: §3 · pp. 6–7

4 Literature Search

• The search targeted papers that explicitly used or developed LLM-based agents for security-related software or system tasks, rather than studies primarily examining the security of agents or LLMs.This scope was implemented through search, filtering, and manual inspection across the three phases.Source: §4 · p. 7

4.1 Phase 1

• The initial search combined agent-related terms with software and system security keywords across Google Scholar and major academic publication portals, returning 108 candidate papers.Source: §4.1 · p. 7

4.2 Phase 2

• Forward and backward snowballing from the 48 seed papers expanded the candidate pool to 144 papers while checking relevance to LLM-based agents and software or system security.Backward snowballing examined cited papers, whereas forward snowballing examined later papers citing the seeds.Source: §4.2 · p. 7

4.3 Phase 3

• Manual screening of the expanded candidate pool under defined inclusion and exclusion criteria yielded a final survey corpus of 100 papers.Included studies used or developed LLM-based agents for software/system security and fell within January 2023–March 2026; short, non-English, and exclusively preprint studies were excluded.Source: §4.3 · pp. 7–8

5 Survey Taxonomy Derivation

• The taxonomy organizes the survey around three high-level aspects: Approach, Application, and Assessment.Source: §5 · p. 8
• The authors identified candidate attributes from selected papers, then generalized and consolidated them into a reusable taxonomy summarized in Table 2.Source: §5 · p. 8

5.1 Attribute/Item Identification

• Attribute identification records recurring agent designs, security tasks, datasets, metrics, baselines, safety measurements, and process-level indicators.Source: §5.1 · p. 8

5.2 Attribute/Item Generalization

• Generalization merges similar terms, resolves overlaps, and normalizes paper-specific wording into broader items such as action space, vulnerability detection, and metric families.Examples include grouping tool invocation, shell execution, sandbox execution, and browser automation under agent action space.Source: §5.2 · p. 8

5.3.1 Approach.

• The Approach taxonomy has seven attributes covering architecture, perception, memory, reasoning and planning, action space, workflow and orchestration, and self-improvement.Together, these attributes treat an LLM security agent as an operational system rather than a single prompt-response model.Source: §5.3.1 · p. 10

5.3.2 Application.

• The Application taxonomy contains eleven task-oriented domains spanning vulnerability analysis, exploit development, penetration testing, repair, fuzzing, malware analysis, defense, and model robustness.Domains remain applicable across papers using different architectures, datasets, or tools because they are organized by task objective.Source: §5.3.2 · p. 10, exploit development & analysis · p. 10

5.3.3 Assessment.

• The Assessment taxonomy covers datasets and outcome, safety, process or trajectory, and comparative metrics because agents act through multi-step trajectories.Trajectory measures include tool calls, hallucinations, cost, iterations, artifacts, and explanations; comparisons may use tools, prior methods, humans, agents, or ablations.Source: §5.3.3 · pp. 10–11

• The survey applies its attribution framework to relevant literature and maps papers onto the taxonomy of LLM-based agents for software and systems security.Source: §6 · p. 11
• The section first reports venue statistics, then summarizes Approach, Application, and Assessment to address the survey’s three research questions.Source: §6 · p. 11
• Attribution records only capabilities explicitly described by each paper, leaving an attribute unmarked when the capability is optional and absent from the agent design.Source: §6 · p. 11

• The dataset contains 100 papers published across 73 distinct venues between 2023 and March 2026.Source: §6.1 · p. 11
• Fifteen recurring venues—13 conferences and two journals—account for 42 papers, while 58 venues contribute one paper each.Source: §6.1 · p. 11
• Security and privacy conferences form the largest recurring category: TrustCom contributes 5 papers, USENIX Security 4, and five security venues collectively represent 16% of papers.Source: §6.1 · p. 11
• General AI and machine-learning venues contribute 10 papers across NeurIPS, ICML, ICLR, and ICAART.Source: §6.1 · p. 11
• Software engineering and data-oriented venues contribute 3 papers each through ICSE and IEEE BigData, while MILCOM, ICMCIS, and IEEE Communications Magazine contribute 7 combined.Source: §6.1 · p. 11

6.2.1 Agent architecture.

• Surveyed agents span single-agent workflows and increasingly collaborative multi-agent designs, including task-specialized, hierarchical, and peer-to-peer coordination.Single agents handle end-to-end interpretation, tool use, and security outcomes, while multi-agent systems divide subtasks, delegate vertically, or resolve disagreements through debate or voting.Source: §6.2.1 · p. 12
• Multi-agent reinforcement learning in AutoRestTest improves coverage by 12–27% over single-agent baselines through specialized API-testing agents [44].Its API, dependency, parameter, and value agents optimize orthogonal testing dimensions.Source: §6.2.1 · p. 12
• Modular pipelines are the dominant internal organization, separating strategic decision-making from concrete action through planner/executor modules, while verifier/critic modules recur across security-agent architectures.PentestAgent uses intelligence gathering, vulnerability analysis, and exploitation, while PatchAgent couples fault localization and patch generation with a verifier that tests candidate patches.Source: §6.2.1 · pp. 13–14
• Other architectures combine LLMs with fine-tuned components, reinforcement learning, guardrail or policy-enforcement layers, and deliberate mixtures-of-agents ensembles that aggregate diverse model responses.Source: §6.2.1 · p. 14
• The backbone LLM may act only as a generator or serve as the central planner, tool user, observer interpreter, judge, verifier, or general-purpose agent backbone.Actor-only designs bound the LLM to local artifacts or actions, whereas planner-plus-actor designs assign it broader workflow control.Source: §6.2.1 · p. 15
• Agent architectures span autonomous operators that plan, use tools, generate outputs, and validate results; critic/verifier roles that assess other components; and all-in-one loops that merge these responsibilities.RepairAgent plans tool use, retrieves repair ingredients, generates patches, and validates candidate repairs, while RepoAudit’s validator checks data-flow facts and path-condition satisfiability [31].Source: §6.2.1 · p. 15

6.2.2 Agent memory.

• Agent memory combines in-context and task-progress state with external short-term traces, persistent stores, knowledge graphs, parametric knowledge, and security-specific artifacts.These memories support reading, writing, and reflection: agents retrieve prior information, record outputs, and revise plans or behavior from execution feedback, as in ClearAgent, PropertyGPT [51], and RefPentester [18].Source: §6.2.2 · pp. 15–17

6.2.3 Agent perception.

• Perception draws primarily on source code, but also compiled binaries, disassembly, and decompiled output, transforming these artifacts into reasoning-ready context for security tasks.Source-code perception can include concrete data-flow paths, while binary-facing perception is needed when source is unavailable or the task inherently targets binaries.Source: §6.2.3 · p. 18
• Agents combine natural-language intent with structured, machine-checkable data and may inspect binary representations through analysis interfaces rather than relying only on source code.ClearAgent exposes binary representations and supports iterative inspection of functions, control-flow blocks, and candidate vulnerability locations.Source: §6.2.3 · pp. 18–20
• Perception mechanisms range from direct ingestion and retrieval to summarization, semantic embeddings, and tool-mediated observation that makes perception part of an action loop.ClearAgent obtains analysis context through tools, RepairAgent uses code-search and validation feedback, and Cognitive SOC distills alert evidence into attributed narratives.Source: §6.2.3 · p. 20

6.2.4 Agent reasoning & planning.

• ReAct is a natural fit for interactive security because agents repeatedly reason, act, observe feedback, and select what to inspect, execute, or query next [62].AutoPT applies this iterative process to web penetration testing, while BountyBench includes inspection, command execution, and vulnerability handling in the loop.Source: §6.2.4 · pp. 21–22

6.2.4 Agent reasoning & planning

• Other planning designs include explicit chain-of-thought, reflection and Reflexion, prompt chaining, few-shot guidance, self-repair, and least-to-most task decomposition.These approaches interpret noisy observations, convert failures into reusable guidance, calibrate outputs, revise artifacts using validation feedback, and separate high-level strategy from command execution [29, 44, 51].Source: §6.2.4 · p. 22
• Hypothesis-driven and graph-based reasoning support validation of suspected vulnerabilities and relational, multi-hop, path-dependent attack logic [31] [51].RepoAudit [31] validates data-flow facts into bug reports, PropertyGPT [51] checks generated properties, and graphs represent preconditions, dependencies, attack steps, or environment structure.Source: §6.2.4 · p. 22

6.2.4 Agent reasoning & planning.

• Dynamic/reactive planning is the dominant strategy, with agents revising subsequent actions in response to observations, failed attempts, tool outputs, or environmental changes.The survey distinguishes contingency-driven iteration from generic multi-step execution and treats under-specified planning as a separate category rather than evidence of no planning.Source: §6.2.4 · p. 23
• Other planning approaches include hierarchical task decomposition, backtracking to earlier choices, confidence-based branching, majority voting, and human-in-the-loop checkpoints.These mechanisms decompose objectives, abandon unsupported paths, use disagreement as evidence, or reserve sensitive decisions for human validation.Source: §6.2.4 · pp. 23–24

6.2.5 Agent action space.

• Agent action spaces range from conventional software-analysis utilities to security platforms, multi-agent coordination mechanisms, and human-facing review steps.Table 8 summarizes this breadth, including static and dynamic analysis, code execution, information retrieval, security-operation platforms, cloud and cyber-range tools, and review actions.Source: §6.2.5 · p. 24, Table 8 · p. 24
• External tools mediate security reasoning through path analysis, formal verification, binary inspection, fuzzing, debugging, sandboxed execution, retrieval, and workflow integration.For example, RepoAudit validates suspected bugs with demand-driven data-flow evidence, PropertyGPT checks generated properties through compilation and a prover, and ClearAgent validates candidate bugs through binary-analysis interfaces.Source: §6.2.5 · pp. 24–25
• Security agents use domain-infrastructure actions, inter-agent coordination, and human interaction for guidance, execution support, and review.These actions extend beyond generic programming tools and support defensible coordination and analyst oversight.Source: §6.2.5 · p. 26

6.2.6 Agent workflow & orchestration. Agent workflow and orchestration

• Workflows range from sequential, parallel, iterative, hierarchical, adversarial, and mixed topologies, with planner, executor, verifier, critic, and orchestrator roles.Human involvement spans autonomous execution, monitoring or approval, decision-point intervention, and continuing collaboration.Source: §6.2.6 · pp. 26–27
• Mixed workflows can sequence increasingly difficult tasks, dispatch specialized components, iterate on stored successful strategies, and combine generation with validation.CurriculumPT exemplifies this combination, while RepairAgent [10] and PropertyGPT [51] pair proposed outputs with execution or verification feedback.Source: §6.2.6 · p. 28

6.2.7 Agent self-improvement & learning.

• Self-improvement includes in-session adaptation from execution traces and critique, example-guided correction, and cross-session reuse of successful trajectories.AutoPentester [29] and RefPentester [18] adjust later penetration-testing steps from prior results, while Cyber-Zero preserves reusable strategies beyond a single run.Source: §6.2.7 · p. 29
• Self-improvement methods reuse cybersecurity trajectories from public CTF writeups and simulated personas as training experience for later agents.Cyber-Zero uses synthesized trajectories to train open-weight cybersecurity agents, while Qin et al. [71] update instruction data to adapt security-strategy generation to changing or unknown threats.Source: §6.2.7 · p. 29
• Reinforcement-learning approaches define rewards around objectives including API fault discovery, attack progress, service preservation, threat mitigation, mission impact, and recovery [44].AutoRestTest coordinates API, dependency, parameter, and value agents using REST API feedback and multi-agent reinforcement learning to improve fault detection [44].Source: §6.2.7 · p. 29
• Environment-based reinforcement learning repeatedly improves policies in cyber ranges, simulators, network-security games, and API-testing environments [44].Rigaki et al. study LLM agents through repeated prompt-exploit-observe cycles, while Loevenich et al. combine DRL, augmented LLM components, and knowledge-graph support for autonomous cyber defense.Source: §6.2.7 · pp. 29–30

6.3 Survey Result: Application

• The survey groups applications into eleven level-1 categories, six of which each represent more than 10% of surveyed papers and receive individual taxonomy tables.The remaining lower-frequency categories share a single table and are organized using level-2 task groupings.Source: §6.3 · p. 30

6.3.1 Vulnerability detection & analysis.

• Vulnerability detection and analysis is one of the largest application areas, with agents supporting vulnerability discovery, localization, classification, prioritization, and validation across source code, smart contracts, binaries, APIs, and infrastructure.On a benchmark of 879 CVEs, JITVUL shows ReAct-style agents outperform raw.Source: §6.3.1 · pp. 30–31
• The cited results report 34 zero-day vulnerabilities (23 CVEs assigned) across 20 popular open-source LLM-agent applications, 12 smart-contract zero-days, and agents often failing to synthesise workable commands.Agents are procedurally fluent in the workflow but frequently fail to synthesise commands that work against targets; one cited result achieves 78.4% precision at roughly $2.54 per project.Source: §6.3.1 · p. 31

6.3.2 Exploit development & analysis. These agents, as summarized

• 4.3× improvement over single-agent baselines was achieved on 14 real zero-day vulnerabilities by HPTSA’s planning agent dispatching specialist subagents.HPTSA treats exploit synthesis as a primary objective rather than subsuming it under penetration testing.Source: §6.3.2 · p. 32
• Exploit-development agents cover payload crafting, exploit chaining, exploit detection, and reverse engineering, but only one paper addresses exploit analysis as a precursor to defensive countermeasures.Exploit chaining combines vulnerability primitives with cybersecurity knowledge graphs to reason about preconditions and privilege transitions; VVF-AI [48] filters false positives and ZT-ICAS [69] detects exploitable weaknesses while hardening the scanner against adversarial manipulation.Source: §6.3.2 · pp. 32–33

6.3.3 Penetration testing & red-teaming. Agents in this cate-

• Penetration-testing agents support reconnaissance, exploitation, privilege escalation, and end-to-end campaigns, with one system outperforming PentestGPT by 27% in subtask completion while requiring substantially less human intervention.Other systems use MITRE ATT&CK attack chains, multi-agent orchestration, knowledge self-reflection, workflow management, and curriculum-based progression.Source: §6.3.3 · p. 33
• CTF-oriented agents reached state-of-the-art results on 390 challenges across NYU CTF, Intercode-CTF, and CyBench using interactive debugging and persistent network-client tools.CTFKnow [40] supplies a 3,992-question benchmark measuring technical CTF knowledge.Source: §6.3.3 · p. 34
• Post-access capabilities remain underdeveloped: only two papers address lateral movement, work on exfiltration is sparse, and no paper addresses persistence.These phases are substantially less developed than initial-access and reconnaissance capabilities.Source: §6.3.3 · p. 35

6.3.4 Vulnerability repair & hardening.

• Vulnerability repair and hardening agents validate fixes through tests, formal properties, proof-of-concept inputs, compilation, static analysis, and provers, while also generating preventive policies.PropertyGPT [51] uses an iterative verification loop; LLM2Policy, the IaC agent, and the cloud agent address hardening or policy enforcement.Source: §6.3.4 · p. 35

6.3.5 Intrusion & threat detection, incident response.

• Intrusion and incident-response agents cover telemetry analysis, alert triage, investigation, attribution, forensics, threat hunting, and automated defensive actions.Examples include structured alert narratives with 99.6% evidence linkage, attack-chain reconstruction, autonomous forensic investigation, and LLM-driven SOAR orchestration.Source: §6.3.5 · pp. 36–38
• 99.78% average F1 was achieved by Clouseau across 21 DARPA OpTC and ATLAS APT scenarios while reconstructing attack chains without prior training or predefined heuristics.The surveyed corpus also reports 96.94% accuracy for TrustNet scam-website detection and 93.6% detection accuracy for a cross-domain alert-triage agent.Source: §6.3.5 · pp. 37–38

6.3.6 Threat intelligence & security operations (SecOps).

• SecOps agents automate human-in-the-loop workflows including threat-intelligence ingestion, reporting, policy generation, and analyst support.These applications are summarized in Table 16 and span the surveyed SecOps literature.Source: §6.3.6 · p. 38
• Threat-intelligence and SecOps agents synthesize heterogeneous security information, extract CTI structures, generate policies and vulnerability reports, answer security questions, and draft CVE or VEX advisories.Examples include contextual recommendation across email-verification, log-analysis, and IP-scanning agents, knowledge-graph construction, zero-trust policy generation, and plan-and-execute VEX justification over SBOMs, source, and documentation.Source: §6.3.6 · p. 38

6.3.7 Other (Lower-frequency) security domains.

• Lower-frequency applications broaden beyond dominant vulnerability and offensive-security workflows to model-attack evaluation, fuzzing, reverse engineering, malware analysis, and access-control assessment.These categories are consolidated in Table 17 and represent a small share of the corpus while indicating breadth across emerging security applications.Source: §6.3.7 · p. 39, Table 17 · p. 39
• ConcoLLMic achieves 115–233% higher coverage than KLEE across twelve real-world subjects, while agents remain focused on reasoning-heavy fuzzing rather than infrastructure.Multi-agent fuzzing also uses dense retrieval over protocol RFCs, but work on harness, seed-input, and coverage-guided orchestration is absent.Source: §6.3.7 · pp. 39–40
• Malware applications cover detection, classification, behavior analysis, and evasion, but LAMLAD reaches a 97% attack success rate in an average of three queries and malware-generation work is absent.MAD-Agent orchestrates static analysis, dynamic sandbox analysis, and threat intelligence, whereas LAMLAD uses a dual-agent manipulator/analyzer loop for Android APKs.Source: §6.3.7 · p. 40
• Access-control assessment has only LLM2Policy, which analyzes firewall and ACL policies and generates fine-grained zero-trust policies from Kubernetes manifests, while authentication and authorization testing remain untouched.Reverse-engineering agents expose binary representations, construct vulnerability-triggering inputs, and extract protocol state machines, while robustness work evaluates prompt injection, jailbreaks, poisoning, and other adversarial attacks.Source: §6.3.7 · p. 40

6.4.1 Metric.

• Assessment coding leaves 29 process rows, 70 safety rows, six task-effectiveness rows, and four comparative rows unspecified for their respective scopes.Blank entries indicate that papers report no measure in that table’s scope, not that they lack assessment altogether; six task-effectiveness blanks include four safety-focused studies [15], Cognitive SOC, and an attack-chain demonstration.Source: §6.4.1 · p. 40
• Task-effectiveness assessment uses ten metric families that judge outcomes rather than how agents reasoned or used tools.Families include accuracy and classification, precision/recall/F1, error rates, success and completion, finding yield, and correctness or validity.Source: §6.4.1 · p. 40, Table 18 · p. 41
• Precision, recall, and F1 dominate detection-style tasks, while Agent4Vul reports F1 improvements over 19 baselines across four smart-contract vulnerability types.These measures expose different operational costs: precision reflects trustworthiness of reported findings, whereas recall or detection rate reflects missed issues.Source: §6.4.1 · pp. 41–42
• Success and completion metrics evaluate executable or benchmark-defined endpoints, including exploit or attack success, testing completion, patch success, test passing, remediation completion, and successful policy enforcement.Bench assesses agents against real-world critical-severity CVEs in sandboxed web applications and scores exploitation completion against a reference target. BountyBench assesses detect, exploit, and patch tasks over real bug-bounty issues.Source: §6.4.1 · p. 42
• Finding-yield metrics connect generated properties to concrete vulnerability discovery by counting security artifacts, while PropertyGPT [51] reports precision and recall alongside known CVEs, historical attack incidents, and zero-day bugs.Source: §6.4.1 · p. 42

6.4.1 Metric

• Coverage metrics measure how much target space an agent explores, while time-oriented metrics assess task speed; MultiFuzz [62] compares branches and protocol states with NSFuzz, AFLNet, and ChatAFL.The surveyed metrics also include cumulative reward and mission or service availability.Source: §6.4.1 · p. 43
• Agentic-process metrics evaluate steps, tool calls, hallucinations, resource use, iterations, intermediate artifacts, explanations, and economic value beyond final success.These measures matter because final scores can hide fabricated evidence, wasted iterations, weak artifacts, or unauditable explanations; Table 19 groups them into eight families.Source: §6.4.1 · pp. 43–44
• Tool-call accuracy is rare but diagnostic, distinguishing reasoning failures from execution failures such as selecting irrelevant scanners, malformed commands, or wrong application components.CVE-Bench foregrounds assessment of agents interacting with sandboxed web applications and concrete attack targets.Source: §6.4.1 · p. 44
• Hallucination metrics measure unsupported claims, fabricated evidence, invalid vulnerability explanations, and inconsistent security reasoning; such findings can cause false alarms, unsafe patches, or incorrect incident narratives.Cognitive SOC assesses evidence-backed security narratives with evidence linkage and citation coverage.Source: §6.4.1 · pp. 44–45
• Cost and token-efficiency metrics track token usage, wall-clock time, monetary cost, and assessment-time reductions across interactive security workflows.RepoAudit [31] reports an average of 0.44 hours and $2.54 per project auditing real-world codebases.Source: §6.4.1 · p. 45

6.4.1 Metric.

• Artifact-correctness metrics distinguish invalid or malformed generated artifacts from failures caused by non-vulnerable targets or other downstream conditions.They assess whether outputs are well-formed, executable, or semantically faithful before measuring security outcomes.Source: §6.4.1 · p. 45
• Report and explanation metrics assess whether outputs are traceable, complete, understandable, useful, and supported by evidence linkage and citation coverage.In SOAR-style systems, explanations must justify investigation verdicts or response recommendations before analysts act.Source: §6.4.1 · p. 45
• PropertyGPT [51] reports an $8,256 bounty for a previously unknown bug found through generated properties, while BountyBench combines success rates with dollar-valued outcomes.Economic metrics make practical vulnerability impact more interpretable than binary detection, exploitation, or patch labels alone.Source: §6.4.1 · p. 45
• Safety and reliability assessment covers seven metric families: containment, robustness, consistency, attack success, defense effectiveness, utility tradeoffs, and overhead.Examples include authorized-scope containment, prompt-injection resistance, repeated-run stability, attack success across prompt/context/memory layers, defense outcomes, preserved utility, and latency or compute costs.Source: §6.4.1 · pp. 46–47
• Comparative and baseline metrics relate agents to traditional tools, learned methods, non-agent LLMs, humans, other agents, or ablated variants, with six comparison families in Table 21.Four blank rows represent papers lacking a matching comparator, limiting interpretation across benchmarks, vulnerability classes, and environments.Source: §6.4.1 · pp. 47–48
• Assessments compare agentic systems with traditional non-AI tools, prior ML/DL methods, humans, and other agent systems; BountyBench assesses 10 agents across detect, exploit, and patch.Source: §6.4.1 · pp. 48–49
• Agent assessments most directly test agentic value against plain LLMs by removing planning, memory, tool feedback, role decomposition, or critic stages.These baselines distinguish gains from agent design rather than stronger underlying language models.Source: §6.4.1 · p. 48
• Ablations expose which components drive performance because the agent label can conceal independent choices such as dependency graphs, loss terms, and self-reflection.AutoRestTest [44], AgentPoison [15], and VulnGPT each disable or remove selected components to isolate their contributions.Source: §6.4.1 · p. 49

6.4.2 Dataset.

• Datasets are characterized by origin, security task, realism, label quality, scale, modality, coverage, and accessibility, with unspecified properties left un inferred.Origins include production systems, competitions, threat feeds, curated public artifacts, and controlled or generated sources.Source: §6.4.2 · p. 49
• Real-world datasets capture operational structure, whereas synthetic and controlled sources provide measurable vulnerabilities, attack paths, state transitions, and outcomes but may reduce messiness.BountyBench covers 25 real-world systems, while controlled tasks make intended flags, exploit conditions, network states, or defense outcomes knowable.Source: §6.4.2 · p. 50

6.4.2 Dataset

• Dataset coverage spans vulnerability detection, penetration testing, smart contracts, repair, cyber defense, fuzzing, agent security, malware, OSINT, SOC operations, and other security tasks.The taxonomy distinguishes similarly realistic artifacts by the security capability assessed and includes named benchmark families where possible.Source: §6.4.2 · p. 50, Table 23 · p. 51
• Dataset characterization uses realism, label quality, scale, artifact type, vulnerability coverage, and accessibility because results may not be directly comparable even within one application.Table 24 applies supported axes to each paper, while unreported values remain unspecified.Source: §6.4.2 · p. 53, Table 24 · p. 54
• Real-world datasets improve ecological validity, whereas synthetic and semi-synthetic datasets improve control, repeatability, and safety.The surveyed datasets span fully synthetic, semi-synthetic, and fully real-world settings.Source: §6.4.2 · p. 53
• Large datasets are relatively rare outside vulnerability-detection corpora and smart-contract analysis because agentic assessments require live environments, tool interaction, sandboxing, or human validation.This creates a recurring trade-off in which scale is exchanged for realism and measurement depth.Source: §6.4.2 · p. 53
• Artifact type shapes required capabilities: code emphasizes semantic program reasoning, binaries require lower-level analysis, and network/log data emphasize temporal correlation and environment state.Network/log data appear across cyber defense, intrusion detection, protocol fuzzing, penetration testing, SOC alerting, and web-security tasks.Source: §6.4.2 · p. 53

6.4.2 Dataset.

• Subtask performance across vulnerability categories is more informative than a single aggregate score.The surveyed targets span OWASP risk categories and multiple CWE items while assessing detection, exploitation, and patching tasks.Source: §6.4.2 · p. 55
• Assessment datasets are classified as fully public, access-controlled, restricted, proprietary or internal, or unspecified based on their disclosure conditions.Some datasets require registration or platform access, while others cannot be fully released because of environments, challenge assets, or collected data.Source: §6.4.2 · p. 55
• Publicly released source artifacts do not imply that authors’ complete assessment datasets are publicly available.Accessibility is recorded as unspecified when access conditions are not disclosed.Source: §6.4.2 · p. 55

7.1 Agentic Approach to Software/Systems Security

• Security agents now plan, act, observe, and revise, but architecture and workflow design are more mature than uncertainty handling, safety controls, human governance, and long-term learning.Source: §7.1 · p. 55

7.1.1 Limitations and Challenges of Existing Works.

• Surveyed systems are operationally modular but rarely make verification, policy enforcement, role boundaries, and failure modes auditable.Modular pipelines appear in 91% of papers, while explicit critic/verifier and guardrail layers appear in 15% and 13%, respectively.Source: §7.1.1 · p. 55
• Memory and perception consume diverse information but remain shallow, weakly curated, and vulnerable to adversarial or misleading inputs.Read operations appear in 61% of papers versus explicit writes in 7%; direct LLM ingestion is universal, while retrieval-augmented perception appears in 30%.Source: §7.1.1 · pp. 55–56
• Reasoning is dominated by reactive planning, while explicit uncertainty mechanisms and human checkpoints remain uncommon and many paradigms go unspecified.Dynamic/reactive planning appears in 80% of papers, compared with confidence-based branching in 23% and human-in-the-loop checkpoints in 4%.Source: §7.1.1 · p. 56
• Autonomy has outpaced governance: fully autonomous workflows appear in 95% of papers, whereas human-on-the-loop and human-in-the-loop workflows appear in 8% and 5%.Self-improvement is also sparse, with within-session feedback in 32% of papers but successful-trajectory storage in 3% and fine-tuning-data updates in 2%.Source: §7.1.1 · p. 56

7.1.2 Future Research Directions.

• Future research should make agents auditable and bounded through explicit role separation, managed memory with provenance, adversarially robust perception, uncertainty-aware recovery, and security-native tool integration.Recommended controls include authorization and scope checks, governed memory updates and contamination defenses, prompt-injection filtering, confidence-based branching, rollback, clarification, and reliable tool-output validation.Source: §7.1.2 · pp. 56–57
• Typed interfaces and trajectory logs should record tool-call accuracy, permission boundaries, and side effects to make agent behavior reproducible, auditable, and constrainable, extending the sound-tool-in-the-loop design of RepoAudit [31].Cloud/IaC platforms and cyber ranges should use typed interfaces rather than free-form commands.Source: §7.1.2 · p. 57
• Human involvement should be risk-based: autonomy fits sandboxed benchmarks, low-risk analysis, and offline reports, whereas real-world workflows often require approval gates and review of high-risk actions.Interfaces should expose evidence, uncertainty, planned actions, and alternatives; PentestGPT illustrates shifting between human-on-the-loop and human-in-the-loop roles within one workflow.Source: §7.1.2 · p. 57
• Agents should learn across tasks by storing successful and failed trajectories with metadata, retrieving similar cases, and using them for fine-tuning or preference data when appropriate.Reusable structures include exploit chains, failed commands, false-positive patterns, patch templates, alert-triage rationales, and tool-specific recovery strategies; Cyber-Zero provides a trajectory-synthesis precedent beyond CTF writeups.Source: §7.1.2 · p. 57
• Reinforcement learning and environment-based improvement are promising for API testing, cyber ranges, autonomous defense, and attack simulation, but reward design must avoid unsafe shortcuts.The stated long-term goal is security agents that improve from experience while preserving auditability, scope control, and reproducibility.Source: §7.1.2 · p. 58

7.2 Applications of Agentic Approaches in Software/Systems Security

• Agents now address diverse software and systems security tasks, but applications remain concentrated around vulnerability detection, exploitation, penetration testing, and repair.This breadth spans multiple security subfields, while defensive, low-level, and governance-heavy tasks remain less mature.Source: §7.2 · p. 58

7.2.1 Limitations and Challenges of Existing Works

• Existing applications are fragmented across lifecycle stages, with BountyBench among the few designs explicitly connecting detection, exploitation, and patching.Many agents stop at findings, proof of compromise, patch generation, or evidence synthesis rather than supporting verification, remediation, validation, reporting, and monitoring.Source: §7.2.1 · p. 58
• Applications are strongest with natural language, source code, or familiar commands, but weaker for specialized representations, stateful execution, production constraints, and operational safety.Benchmarks often use CTFs, reproduced CVEs, synthetic networks, repositories, or curated tasks, while real deployments require integration with approval chains, legal limits, noisy telemetry, and human accountability.Source: §7.2.1 · p. 59

7.2.2 Future Research Directions

• Future research should broaden applications toward recurring defensive and governance work, connect tasks into lifecycle-aware workflows, and build domain-specific agents with explicit evidence, acceptance, and safety requirements.Recommended systems include auditable supply-chain, access-control, cloud, compliance, SOC, malware, binary-analysis, and fuzzing agents that define authorization scope, approval gates, logging, and release constraints.Source: §7.2.2 · pp. 59–60

7.2.2 Future Research Directions.

• Future applications should report environmental assumptions, integration requirements, failure modes, and adaptation mechanisms to clarify transfer limits across organizations.Examples include curated open-source projects versus proprietary monorepos and SOC summarizers facing different logging schemas and playbooks.Source: §7.2.2 · p. 60
• Cross-domain studies could transfer techniques across tasks, such as penetration-testing methods for asset discovery and evidence-linking methods for vulnerability-report generation.Source: §7.2.2 · p. 60
• The long-term goal is to determine which application patterns generalize across security tasks and which require domain-specific design.Source: §7.2.2 · p. 60

7.3 Assessment of Agentic Approaches in Security Applications

• Assessment covers task effectiveness, trajectories, safety, reliability, baselines, and datasets, but task outcomes remain more common than tool-call quality, safety, reproducibility, or human utility.Task-level success, classification, time, and resource metrics are relatively common, whereas process-level and safety measures remain sparse.Source: §7.3 · p. 60, §7.3.1 · p. 60

7.3.1 Limitations and Challenges of Existing Works.

• Success/completion appears in 51% of papers, while precision/recall/F1, time/responsiveness, and accuracy/classification appear in 34%, 25%, and 23%, respectively.These metrics are necessary but insufficient because agents can reach correct answers through brittle, costly, unsafe, hallucinated, or unauditable behavior, while useful intermediate progress can be hidden by final-task failure.Source: §7.3.1 · p. 60
• Process metrics remain sparse: cost/token efficiency appears in 32% of papers, steps to completion in 21%, and tool-call accuracy in only 1%.Hallucination rate and report/explanation metrics each appear in 11%, iteration count in 10%, artifact correctness in 3%, and economic/bounty value in 2%.Source: §7.3.1 · p. 61
• Safety assessment is especially limited: consistency appears in 18% of papers, attack success in 10%, defense success in 8%, prompt-injection robustness in 6%, and scope containment in 5%.Adversarial assessment is not routine despite agents inspecting untrusted artifacts, executing commands, and interacting with sandboxes; datasets also trade realism against reproducibility and often lack strong ground-truth oracles.Source: §7.3.1 · p. 61

7.3.2 Future Research Directions.

• Future protocols should report task effectiveness, trajectory quality, safety and reliability, and cost and reproducibility as a multidimensional profile rather than a single score.Benchmarks should release traces, validation oracles, partial-credit rubrics, and reproducible environments while assessing failures, unsafe actions, prompt injection, poisoning, scope containment, consistency, and utility-security tradeoffs.Source: §7.3.2 · pp. 61–62
• Comparative assessment should strengthen non-agent baselines, controlled agent-to-agent comparisons, ablations, broader task datasets, and explicit reporting of token use, time, monetary cost, assumptions, and run variance.Comparisons must control model, budget, tool access, and environment so improvements can be attributed to agent architecture rather than underlying resources or privileged access.Source: §7.3.2 · p. 62

7.4 Cross-Cutting Future Research Directions

• Security-agent research should co-design architecture, target application, and assessment because technical choices constrain feasible tasks, application context determines relevant risks and evidence, and assessment determines trustworthiness and reproducibility.Different tasks require distinct authority boundaries, evidence models, success conditions, and failure handling.Source: §7.4 · p. 63, §7.4.1 · p. 63

7.4.2 Evidence-Centered and Auditable Agentic Security

• Agents should maintain explicit evidence graphs or ledgers that distinguish facts, hypotheses, generated text, retrieved knowledge, and validated findings while recording provenance, confidence, validation, and downstream use.Benchmarks should assess whether evidence chains are complete, faithful, and minimally sufficient, not only whether final answers are correct.Source: §7.4.2 · p. 63

7.4.3 Risk-Aware Autonomy and Governance

• Autonomy should be risk-aware: low-risk summarization may be fully autonomous, medium-risk triage may require human-on-the-loop review, and high-risk actions should require explicit approval or policy verification.Designs and benchmarks should expose authorization, rollback, human approval, and policy-enforcement controls and test them under erroneous and adversarial conditions.Source: §7.4.3 · pp. 63–64

7.4.4 Realistic, Reproducible, and Safe Benchmark Ecosystems

• Benchmark ecosystems should jointly provide realism, reproducibility, and safety through executable instrumented environments, stable setups and oracles, scope boundaries, sanitized artifacts, and disclosure policies.Interactive benchmarks should preserve trajectories because agent behavior is defined by the path from observation to action, not only the final output.Source: §7.4.4 · p. 64

7.4.5 Cost, Scalability, and Resource Governance

• Assessments should report token cost, wall-clock time, tool calls, infrastructure requirements, memory growth, and run variance, while agents learn budget-aware planning and adaptive execution.Resource policies should be evaluated jointly against security effectiveness and consumption because excessive cost or latency can preclude continuous workflows.Source: §7.4.5 · p. 64

7.4.6 Human-Agent Collaboration as a Security Interface

• Human involvement should be designed as a security interface exposing uncertainty, evidence, alternatives, and planned actions while measuring decision quality, workload, trust calibration, escalation, and accountability.Humans should be able to correct agent state, mark evidence trust, constrain actions, and inspect recommendations.Source: §7.4.6 · pp. 64–65

7.4.7 Toward Generalizable Security-Agent Engineering Principles

• The field needs reusable principles identifying cross-task capabilities, such as evidence tracking, tool validation, provenance, risk-based approval, and cost-aware planning, versus domain-specific representations and tools.Controlled comparisons across applications can reveal when multi-agent designs, retrieval, verifiers, fine-tuning, or human checkpoints improve robustness or reduce false positives.Source: §7.4.7 · p. 65

7.4.7 Toward Generalizable Security-Agent Engineering Principles.

• The longer-term goal is to move from isolated prototypes to an engineering discipline for LLM-based security agents.Source: §7.4.7 · p. 65
• This discipline should develop patterns, benchmarks, reporting standards, and safety practices that improve safety without eliminating utility.Source: §7.4.7 · p. 65
• These elements should connect approach, application, and assessment into one coherent research agenda.Source: §7.4.7 · p. 65

Survey taxonomy derivation

• The Approach–Application–Assessment taxonomy reflects recurring corpus distinctions but remains an evolving synthesis whose abstraction levels and future attributes could differ across researchers.Potential additions include long-term memory governance, agent supply-chain risk, tool-permission models, and deployment-time monitoring.Source: §8 · p. 66

Paper attribution

• Multi-label paper attribution is necessary for multi-component systems but involves judgment calls, uneven reporting, and best-effort characterization rather than definitive implementation audits.The survey coded explicit descriptions and allowed multiple supported mappings, while retaining blanks when metric families remained unspecified and accounting for overlapping publications.Source: §8 · p. 66

Survey result analysis

• Results across papers are often incomparable because models, architectures, tools, prompts, environments, budgets, benchmarks, and attempts vary, while changing systems can impair reproducibility.The analysis therefore emphasizes recurring gaps rather than ranking systems, including limited safety assessment, weak trajectory reporting, uneven baselines, vulnerability-centric applications, and insufficient human governance.Source: §8 · pp. 66–67

• The survey covers 100 peer-reviewed papers published between January 2023 and March 2026 across Approach, Application, and Assessment.Source: §9 · p. 67
• Agents increasingly use modular, tool-mediated, autonomous workflows: 91% adopt modular pipelines, 88% assign the backbone LLM planner-and-actor duties, and 95% support full autonomy.Source: §9 · p. 67
• Boundedness and inspection remain uncommon, with explicit critics or verifiers in 15% of systems, guardrails in 13%, and human review points in 13%.Source: §9 · p. 67
• Assessment emphasizes outcomes—success or completion in 51% of papers and precision/recall/F1 in 34%—while hallucination rate appears in 11%, scope containment in 5%, and tool-call accuracy in 1%.Applications also concentrate on the vulnerability lifecycle and offensive assessment, while post-access phases, low-level artifact analysis, access-control review, and supply-chain security remain comparatively undeveloped.Source: §9 · p. 67
• Security agents should be studied as operational systems whose evidence gathering, tool use, state, authority boundaries, error recovery, human communication, adversarial behavior, safety, cost, and oversight are assessed alongside outcomes.The open problem is building agents whose authority is bounded and whose behavior is auditable through co-designed architectures, applications, and assessments.Source: §9 · p. 67