Malware Detection with Autonomous Agents: A Review of Functional Roles, Datasets, and Coordination Readiness

1. Introduction

The rapid evolution of malware poses a significant challenge to modern cybersecurity systems. Contemporary malware exhibits advanced capabilities such as polymorphism, obfuscation, and adaptive behaviour, enabling evasion of traditional detection mechanisms Aslan Samet (2020); Gaber et al. (2024). As a result, static signature-based approaches are no longer sufficient for detecting novel or zero-day threats Mira (2024); Aslan Samet (2020). To address these challenges, Machine Learning (ML) and Deep Learning (DL) techniques have become central to malware detection research. These approaches enable systems to learn patterns from large datasets and generalise to previously unseen threats Tayyab et al. (2022); Bensaoud et al. (2024). Existing methods rely on a variety of feature representations, including static features, dynamic behavioural information, graph-based representations, and multimodal analysis techniques. In particular, DL-based methods have demonstrated strong performance by automatically extracting complex feature representations from raw data Bensaoud et al. (2024); Gaber et al. (2024). This body of work is now mature and has been surveyed extensively.

More recently, LLMs and agent-based abstractions have begun to reshape how detection systems are designed. Rather than serving as a single monolithic classifier, an LLM can act as a reasoning component that selects tools, fuses evidence, generates human-readable explanations, and coordinates with other agents across multiple steps. Multi Agent Systems (MASs) extend this idea by distributing detection across cooperating components capable of perception, reasoning, and adaptive response Bougueroua et al. (2021); Saeed et al. (2025).

From a systems perspective, malware detection can be understood as a multi-stage pipeline involving data acquisition, feature extraction, detection, correlation, and response. Most existing work optimises individual stages such as feature extraction, classification, or behavioural analysis in isolation. Comparatively little attention is given to how these stages combine into complete detection systems and how far that pipeline can be covered by autonomous and cooperating components. Existing literature rarely analyses the relationships between datasets, feature representations, learning approaches, and system architectures in an integrated manner, and rarely asks which stages of the pipeline are already agentised and which still await it.

Scope of this review

This review focuses on the LLM-agent strand of malware detection and analysis. We examine implemented systems in which LLMs or agent abstractions drive detection or analysis, and we treat the broad and already well-surveyed body of standalone ML and DL detectors as the substrate on which these systems are built rather than as primary subjects of review. To assess how far this pipeline is positioned for agent-based operation, we adopt a role-based view drawn from classical agent theory and recent LLM-agent taxonomies Jiang et al. (2026); Sapkota et al. (2026); Ali et al. (2025), organising our analysis around the four functional roles an agent-based detection pipeline must fulfil. These are perception, which acquires and represents program artefacts and behaviour; reasoning and decision-making, which produces and adjudicates a detection verdict; adaptive monitoring, which observes runtime behaviour and revises analysis over time; and collaborative learning, which distributes detection across cooperating components. Two adjacent areas are out of scope. We do not survey intrusion detection or network traffic analysis, and we do not survey the offensive use of LLMs for malware generation, both of which have been addressed elsewhere (Jelodar et al. 2026).

Research Gap. Existing surveys extensively analyse malware datasets, feature representations, and detection methods individually. However, there is currently limited structured analysis of how these components interact within larger malware detection pipelines, how existing approaches support adaptive and distributed operation, and to what extent current methods are suitable for integration into coordinated agent-based architectures.

Contribution

Rather than cataloguing detectors in isolation, this review treats malware detection as a coordinated, multi-stage system and asks how far the existing literature is positioned to support agent-based operation. Concretely, it contributes:

• a comparison of prior surveys against the core dimensions of malware detection, showing that no existing survey consolidates the agent-based strand for malware detection specifically (Table 3);
• a modality-based taxonomy of the datasets in active use across the reviewed corpus (Figure 3);
• a dataset-to-method usage map that exposes how strongly method choice is conditioned by data modality (Figure 4), together with three cross-cutting findings on the dataset landscape (Findings 1-3, Section 4);
• a pipeline-stage coverage matrix for the agent-based systems in the corpus, making visible where coverage thins toward dynamic analysis and autonomous response (Figure 5);
• an agentisation-readiness assessment that maps these four functional roles of an agent pipeline, which are: perception, reasoning and decision-making, adaptive monitoring, and collaborative learning, onto existing method families, with an explicit ordering of which detectors are easiest and which are hardest to agentise and
• a set of open problems for the security of multi-agent detection pipelines, an emerging concern that the agentisation of malware analysis raises in its own right (Section 7).

The central takeaway is that the technical ingredients for coordinated malware detection are already widespread: three of the four agent roles are served, in isolated form, by mature methods throughout the corpus, so the principal open problem is one of integration and orchestration rather than the invention of new detectors. Collaboration is the single exception and the clearest gap.

Structure of this review

The remainder of this paper is organised as follows. Section 2 describes the search, screening, and categorisation methodology. Section 3 describes the development of malware detection and positions this review against related surveys. Section 4 turns from surveys to the primary corpus, analysing the dataset-method landscape. Section 5 analyses the agentisation roles targeted by the same corpus. Section 6 discusses the results. Section 7 turns the focus towards future developments of agent and multi-agent malware detection. Section 8 draws the threads together

2. Methodology

This literature review follows a structured methodology comprising literature collection, screening, categorisation, and qualitative analysis, in line with the commonly used PRISMA scheme Page et al. (2021). The goal of the methodology is to systematically identify existing malware detection approaches and analyse how datasets, which can also be a primary contribution, feature representations, detection methods, and architectural designs contribute to adaptive and agent-oriented malware detection systems.

2.1. Search Strategy

The literature was sourced from the commonly used databases of Scopus, IEEE and ACM. In addition, a Google Scholar search was conducted to identify any additional relevant publications not found in the database searches. Since many redundancies already occurred across these four paper sources, we decided to omit a Web of Science search. The search queries were designed to capture research related to agent-based and agentic malware detection, dedicated malware datasets, and multi-agent systems. The search terms used in this work are listed in Table 1. For the database search, all results were considered for the subsequent screening and selection process. For the Google Scholar search, the top 200 results for each query were collected to obtain a reasonably sized corpus for screening. The search was conducted on July 2nd 2026, and only papers published between 2020 and the search date were included to maintain a clear focus on the current state of agent-based malware detection.

2.2. Screening and Selection

The screening and selection steps follow a clearly structured plan:

1.

For each database and scholar corpus, the title and abstract were manually screened by one of the authors to assess the relevance of each publication according to the inclusion and exclusion criteria listed in Table 2. The results of this initial screening were then discussed between the initial screener and the other authors.

2.

In cases where the initial step was inconclusive regarding relevance, the full text was considered and discussed among the authors to reach a final decision.

3.

All relevant results were collected, deduplicated and categorised into three main groups, which emerged naturally during the screening process: review work, which contains literature reviews adjacent to this work, original work, encompassing publications that contribute some novel method or analysis axis, and datasets, where works presenting dedicated datasets are collected.

4.

The precise numbers for each selection step can be found in Figure 1, which summarises the screening process in detail, showing that 64 unique works were considered relevant to this review.

The Scholar search returned a few reviews and surveys on ML and DL approaches to malware detection and analysis. These reviews do not appear in the related surveys, but they provide a useful tool for highlighting the background of malware detection and were thus used in an introductory role in Section 3. Consequently, these papers are also not listed as unique results in Figure 1 since they do not contribute to the analytical sections of this work.

The papers from the original work and dataset categories form the primary corpus analysed in Section 4 and Section 5, namely implementation-focused method or system papers and dataset-description papers. There are also a few papers that are relevant to agentisation considerations more broadly, but do not fit into the main scope focusing on malware detection. Examples are works on attacks on MAS or using LLMs offensively for malware creation. The contents of these papers are considered in the future work in Section 7.

Figure 2 displays a summary of the retained corpus according to publication outlet and publication year. Notably, most relevant publications appeared in IEEE journals, with other outlets falling significantly behind. Regarding publication year, an upward trend is evident, indicating the growing importance of agent-based malware detection.

Table A1 in the appendix lists every source analysed in this review, grouped into the three roles they play. The first role collects reviews of LLM and agentic methods, against which this work is positioned, in Section 3.2. The second lists papers whose primary contribution is a dataset, analysed in Section 4.1. The third is the corpus of 64 primary detection studies that carries Sections 4 and 5.

2.3. Analysis Dimensions

To enable a structured comparison across the selected literature, the analysed papers are evaluated according to several core dimensions. Consistent with the scope set out in Section 1, standalone ML and DL detectors are treated as the tools on which agent-based systems build rather than as the primary object of analysis, and the review focuses on LLM-based and agent-oriented approaches.

The analysis is organised along two dimensions. The first is the detection pipeline, spanning data ingestion, static and dynamic analysis, feature extraction, detection, correlation and reasoning, and response. For each system we record which stages are covered, which are partial, and which are absent. The second is the set of four functional roles an agent pipeline must fulfil: perception, reasoning and decision-making, adaptive monitoring, and collaborative learning. For each method, we record which roles it already realises and, on that basis, how readily it could be used within an agent architecture.

In addition to technical characteristics, practical aspects of dataset usage are considered. This includes dataset accessibility, availability, recency, and usage context within the analysed literature. The goal is to provide a structured overview of currently relevant malware detection datasets and their role in supporting existing and future agent-oriented malware detection systems.

3. Background and Related Work

This section first shows the trajectory of detection approaches found in the body of survey literature (Section 3.1) and then, secondly, presents the most recent reviews that address LLM-based and agentic malware detection directly (Section 3.2). These reviews are directly related to this work and thus provide the option to show where we position our work in relation to them. The primary study evidence is examined further down in Section 4 and Section 5.

3.1. The Trajectory of Malware Detection

A large body of survey literature already consolidates malware detection from the ML and DL perspective. We synthesise from it the progression that motivates the agentic turn and treat it as background rather than as a strand to be extended.

From signatures to learning

Early detection relied on handcrafted signatures, heuristic rules, and statistical anomaly detection. Comparative reviews agree that such methods are fast and efficient for known malware but fail against obfuscated, polymorphic, and metamorphic variants, and that no single signature- or heuristic-based approach can detect all malware as complexity grows Aslan Samet (2020); Gaber et al. (2024); Tayyab et al. (2022). This limitation drove the shift to ML, which introduced automated data-driven classification using Support Vector Machines (SVMs), Random Forests, decision trees, and ensemble methods Gyamfi et al. (2023); Aslan Samet (2020); Wu et al. (2025). A recurring counterpoint in this literature is that the learning-based classifiers replacing signatures are themselves fragile, since surveys of adversarial machine learning on Android malware find that no defence is robust against all evasion attacks and that the resulting arms race is unresolved Bhusal Rastogi (2025).

DL then became dominant by automatically learning representations from raw data, with Convolutional Neural Networks (CNNs), Recurrent Neural Networks (RNNs), transformers, autoencoders, and generative adversarial approaches surveyed for malware image classification, API sequence modelling, and cross-platform detection Bensaoud et al. (2024). Tayyab et al. (2022) organise the field into primitive, conventional ML, and DL trends and argue that DL dominates through automatic feature engineering while suffering from small and outdated datasets, evasion techniques, and heavy computational demands.

Hybrid and multimodal systems

To improve robustness against obfuscation and zero-day variants, reviews increasingly emphasise hybrid and multimodal systems that combine static and dynamic analysis, behavioural monitoring, and network telemetry Pavlenko Ivanov (2025). Gaber et al. (2024) argue that feature authenticity depends on the analysis tool and that dynamic binary instrumentation resists obfuscation better than static analysis, while no clear winner emerges between ML and DL once datasets and features are controlled. Aslan Samet (2020) reach a compatible conclusion, finding that no single approach detects all malware and recommending that behavioural, model-checking, and cloud-based approaches be combined for unknown and complex threats. This work identifies a gradual architectural transition from isolated classifiers toward coordinated multi-stage detection.

Distributed and collaborative detection

A recurring theme is that offline, purely static detection is insufficient for dynamic and evasive malware, motivating runtime analysis, continuous monitoring, and the distribution of detection across cooperating nodes. Mira (2024) surveys the progression from static programs using conventional algorithms to systems that incorporate virtual machines, cloud computing, and agent-based technologies. Bougueroua et al. (2021) argue that multi-agent architectures provide the cooperation, autonomy, and data-correlation mechanisms needed for scalable real-time detection, proposing a three-part taxonomy over architecture, agent technology, and decision technique. Complementary work surveys decentralised and federated learning as a response to the limits of centralised ML for large-scale data, though it treats agents as distributed learning participants rather than as autonomous detectors Ahmed et al. (2024). Across all three works, collaboration and distribution emerge as the capabilities most clearly associated with agent architectures rather than with standalone detectors, and that the classical agents described here are more than just LLM-based reasoners.

Toward autonomous and agentic detection

The most recent surveys begin to describe a further shift from distributed detection toward autonomous, goal-driven agents. Tadesse Mbaziira (2025) examine malware analysis through cognitive architectures such as ACT-R and agent-based BDI models and argue that malware itself is increasingly autonomous and persistent, thereby motivating agentic defenders.

Recurring gaps

Across this literature, a consistent set of unresolved problems recurs. These are dataset currency and quality, label scarcity, weak generalisation to novel and evasive malware, adversarial vulnerability, and above all, the absence of commonly accepted benchmarks that would permit fair comparison Aslan Samet (2020); Tayyab et al. (2022); Gaber et al. (2024); Bensaoud et al. (2024); Bougueroua et al. (2021). None of these surveys, however, consolidates the agent-based strand of malware detection. Where classical agents appear, they are treated as one mechanism among many Mira (2024); Gyamfi et al. (2023); Ahmed et al. (2024), and where the field turns toward autonomy, it remains explicitly theoretical without real-world deployment and malware-specific only in part Tadesse Mbaziira (2025).

3.2. Related Surveys

A distinct and very recent group of reviews addresses LLM-based and agentic approaches directly. Table 3 compares them against the core dimensions of this review, together with two discriminating questions: whether the survey is specific to malware detection, and whether it consolidates the agent-based strand for malware detection. They fall into LLM-for-malware reviews and agentic-cybersecurity reviews, and neither group occupies the niche this review fills.

LLM-for-malware reviews

Champie Elish (2026) provide the first systematic taxonomy of LLM-based malware detection and report that fine-tuned and hybrid transformer architectures deliver the strongest performance, while stating that the field is fragmented and lacks adversarial-robustness testing, privacy mechanisms, and real-world validation. Their framing is explicit that no prior review had consolidated LLM-based malware detection into a unified taxonomy, yet agentic operation is gestured at only through mentions of endpoint agents and automated defence pipelines rather than consolidated as a paradigm. Albalooshi et al. (2025) survey LLMs such as GPT-4o, BERT, and Gemini for detecting obfuscated and zero-day malware and catalogue frameworks including AppPoet and MalParse, but do not treat agent-based or multi-agent detection at all. Jelodar et al. (2026) offer the broadest of these, spanning code analysis, malware analysis, and reverse engineering, and are the only ones to mention multi-step autonomous LLM systems such as Auto-GPT and AUTOATTACKER, though these appear largely on the offensive side and the review does not frame the field’s evolution toward multi-agent detection. Ahi Valizadeh (2025) stand slightly apart, surveying the dual-use risks of generative Artificial Intelligence (AI) with an emphasis on AI-generated malware rather than on detection architecture. Across all four the shared limitation is the same. They consolidate models and tasks but not systems, and the agentic strand is left implicit. Ramírez-Martínez et al. (2026) categorises the development of agentic and generative AI for ransomware detection. While they find that most agent-based solutions deliver remarkable numbers in training settings, it is hard to verify these results due to the lack of real-world applications and available data suitable for out-of-training evaluation.

Agentic-cybersecurity reviews

A parallel group surveys agentic AI for cybersecurity broadly. These provide the richest treatment of agent architectures, coordination, and pipeline security but are not specific to malware detection. Lazer et al. (2026); Shahriar et al. (2025) give substantive consolidations of agentic security, covering multi-agent architectures, distributed operation, and the expanded attack surface that autonomy introduces, including prompt injection, memory poisoning, and cascading failures across agents. Vinay (2026) traces an architectural evolution from single-LLM reasoners through role-based multi-agent teams to autonomous security-operations pipelines. H. Xu et al. (2025) survey LLM applications across the full breadth of cybersecurity and devote a substantive section to autonomous agents and multi-agent systems, framing them as an emerging paradigm shift from isolated single-task models toward coordinated pipelines, and are among the few to name an agentic malware-analysis system directly. Regarding datasets, industrial or real-world datasets underpin barely one percent of the papers they survey. Panwar Abdelrahman (2025) frame agentic AI as a paradigm shift from rule-based systems toward self-adaptive autonomous frameworks for threat detection and adaptive defence, while Kshetri (2025) characterises agentic AI as a third wave moving cybersecurity from assistants toward autonomous agent-driven detection and response in security-operations centres, and cautions that practical autonomous attack agents remain immature. In every case malware detection appears only as one use case among many, and none supplies malware datasets, benchmarks, or a consolidated account of agent-based malware detection specifically.

The unaddressed gap

As Table 3 makes visible, no surveyed work is malware-specific and consolidates agent-based approaches thoroughly, describing them only partially at most Champie Elish (2026); Albalooshi et al. (2025); Ahi Valizadeh (2025); Jelodar et al. (2026). The agentic-cybersecurity reviews consolidate agent architectures and their security thoroughly but are not specific to malware detection Lazer et al. (2026); Shahriar et al. (2025); Vinay (2026); H. Xu et al. (2025); Panwar Abdelrahman (2025); Kshetri (2025).

The two closest approaches are the works by Jelodar et al. (2026), which is malware-specific and touches autonomous LLM systems, but only in passing and Tadesse Mbaziira (2025), which is both malware-specific and agent-oriented yet remains explicitly theoretical, confined to cognitive architectures, and without datasets or real-world validation. As a consequence, none assess agent-based malware detection against the functional roles an agent pipeline must fulfil, namely perception, reasoning and decision-making, adaptive monitoring, and collaborative learning as introduced in Section 1. There is therefore no review that is at once specific to malware detection, consolidates the dispersed agent-based work in that area, and reads it through these roles. This review addresses that gap. It consolidates the agent-based malware-detection literature, characterises the datasets it relies on and the performance it reports, and, on that basis, identifies which existing detection systems are structurally suited to agentisation.

4. Datasets, Methods, and Their Alignment with Agent-Based Detection

The preceding sections established that malware detection is converging on adaptive and agent-based architectures, yet repeatedly flagged a shortage of suitable data and evaluation practice as the principal obstacle. This section examines whether the building blocks reported in the implementation literature can support that direction. It surveys the datasets in active use, the feature representations and detection techniques applied to them, the performance these combinations achieve, and the challenges authors report. It then maps datasets and methods onto the four functional roles of: perception, reasoning, monitoring and collaboration to assess how well the available resources match the needs of coordinated and autonomous detection.

The corpus analysed here comprises 64 primary studies retained after screening alongside the relevant reviews presented in Section 3.2. The primary studies all apply LLMs to malware detection or analysis, yet the term agent is used differently across some of them. Therefore, the systems are not distinguished by the label an author applies but by which functional roles the model is actually asked to fill.

Application domains are unevenly distributed. Windows accounts for 27 studies and Android for 18, followed by mixed-platform work with 8 and the software supply chain, meaning malicious npm and PyPI packages, with 6. The supply chain is the third-largest domain in the corpus and a notable addition to the classical Windows and Android split, reflecting that package ecosystems present malicious code as source text, which is the representation language models handle most directly. The remainder covers cloud, IoT, Java, JavaScript, and Linux with one or two studies each. The Java strand is anchored by work on obfuscated JAR binaries that pairs decompilation with a filtered subset of MalDICT Cristea et al. (2026), one of several domains where a single study introduces a dataset seen nowhere else in the corpus.

4.1. Datasets

Malware detection research relies heavily on publicly available benchmark datasets for training, validation, and comparative evaluation. Figure 3 organises the datasets identified across the corpus by data modality. The same colour scheme distinguishing static, hybrid or multimodal, and dynamic or behavioural resources is reused in the usage map (Figure 4) later in this section, so that the two figures may be read as a pair. A full list and links to the available datasets can be found in Table A1, in the appendix.

As Figure 3 shows, there are two main observations regarding the datasets used in primary research.

1.

A small group of benchmarks recurs, led by AndroZoo in 9 studies, VirusTotal in 8, VirusShare in 7, and MalwareBazaar in 6. CIC-AndMal2017, CICMalDroid2020 and Drebin appear in 5 each, EMBER in 4, and CIC-MalMem-2022 in 3. Roughly thirty further datasets appear exactly once.

2.

Of the 64 studies, 48 evaluate on at least one custom or one-off dataset that the authors assembled themselves, and only 16 rely solely on named public benchmarks. Custom corpora take many forms, including sandbox execution logs, package sets crawled from npm and PyPI, expert-labelled report collections, and single-sample case studies. They are not a modality of their own but cut across all three, with 30 of them static, 11 dynamic or behavioural, and 7 multimodal. Note that the figure mixes two quantities, since branch counts give distinct datasets while the values beside each dataset and each custom leaf give studies, and that many studies pair a public benchmark with a corpus of their own, so the values are not mutually exclusive and do not sum to 64.

The corpus shares little evaluation vocabulary with the agentic literature reviewed in Section 3.2. The malware-focused reviews name substantial dataset collections, with 21 datasets in Jelodar et al. (2026) and 17 in Champie Elish (2026), which overlap heavily with the corpus above. The agentic-security reviews name a comparable number, with 14 in Shahriar et al. (2025), but almost all of theirs are agent benchmarks such as AgentDojo, InjecAgent, and CyberSOCEval rather than malware datasets, while Lazer et al. (2026) and Vinay (2026) name no datasets at all. The two literatures do not currently share an evaluation base.

Beyond the benchmarks reused across the surveyed detection studies, a distinct line of work contributes datasets as a primary research output, and several of these are explicitly oriented towards the behaviour-rich and forensic data that adaptive detection requires. MOTIF contributes expert ground-truth family labels linked to human-readable threat-intelligence reports, addressing the unreliable antivirus-derived labelling of prior corpora Joyce et al. (2023). Image-based detection is served by Virus-MNIST, which renders Portable Executable (PE) headers as MNIST-compatible greyscale thumbnails Noever Noever (2021), and TUMALWD and TUANDROMD provide feature-level Windows and Android datasets respectively Borah et al. (2020). A second group targets the dynamic and behavioural data the survey literature identifies as scarce. MLRan offers a near-balanced behavioural ransomware benchmark spanning 2006 to 2024 Onwuegbuche et al. (2026), MTA-KDD’19 supplies a continuously updatable malware-traffic dataset Letteri et al. (2020), and RanSAP/RanSMAP capture low-level storage and memory access patterns at the hypervisor layer, deliberately avoiding Operating System (OS)-level features to resist evasion Hirano Kobayashi (2025); Hirano et al. (2022). Most directly relevant to autonomous detection, MalVol-25 provides paired clean and infected volatile-memory snapshots across four Windows generations and is explicitly constructed to support reinforcement-learning and agentic-AI frameworks for memory-based detection and automated incident response Dunsin et al. (2025). CIC-YNU-IoTMal integrates network captures, system-call traces and system activity logs from 10,000 binaries detonated across ARM, MIPS, MIPSEL and x86. The benign half was synthesised by prompting an LLM to write architecture-appropriate C programs, so that benign and malicious samples could not be separated on traffic volume alone Dadkhah et al. (2026). The same idea is used on the malicious side by fine-tuning a model to emit tabular Android malware records and finding that augmentation preserves detection accuracy while synthetic-only training does not generalise Rollinson Polatidis (2026). CyberLLMInstruct approaches the data problem from the model side instead, supplying instruction-response pairs for fine-tuning and reporting that gains on cyber security tasks come at a measurable cost in safety resilience ElZemity et al. (2026). Collectively, these purpose-built datasets indicate an emerging shift towards temporally aware, behaviour-rich, and evasion-resistant resources, although each remains limited in scale or scope and none yet supplies the continuous, distributed, multi-stage telemetry that coordinated agent-based systems require.

4.2. Feature Representations

Feature representations differ from the dataset mode as the mode depends on whether features are obtained without executing the sample or by observing it at runtime, which follows the static, dynamic and hybrid split of Section 4.1. The extracted feature representations range over API and system-call sequences, PE header and manifest metadata, opcode and assembly sequences, source code and scripts, call and control-flow graphs, network traffic, and rendered images.

Combination is the norm rather than the exception. Of the 64 studies, 37 explicitly describe their input as hybrid or multimodal, fusing several artefact types into a single representation Zeng et al. (2026); Taşkın Doğru (2026); F. Xu et al. (2025). Among the individual artefact types, API and system-call sequences appear in 21 studies, source code or script text in 14, PE header and manifest metadata in 13, graphs in 7, and opcode or assembly sequences in 6. Rendered images appear in only 3 Minh et al. (2026); Mehta et al. (2026) and network traffic in 2, reflecting that LLMs operate more naturally on token sequences than on pixels. One study makes the limits of the image route explicit, comparing prompt-engineered multimodal models against a fine-tuned vision transformer across visual security tasks and finding the transformer consistently ahead on malware classification specifically Trad Chehab (2025). Graph representations are the one structural exception, with control-flow and function-call graphs used as the primary representation in systems that reason over program structure rather than over text Qian et al. (2025).

Static features remain the most common starting point. Android work extracts permissions, intents, API calls, and manifest metadata from application packages Sarraf (2026); Feng et al. (2025); Dong et al. (2025), and one system derives its features from strings held in APK resource files rather than from the manifest alone Feng et al. (2025). Windows work relies on PE header fields, byte sequences, and opcode or instruction sequences Mi (2025); Gravereaux Islam (2025); Adamec Turčaník (2025), while binary-level analysis operates on decompiled pseudocode and intermediate representations Dai et al. (2026); Fujii Yamagishi (2025). In the same vein, obfuscated Java bytecode is decompiled and then summarised into natural language before the model reasons over it, so the textual representation is produced rather than extracted Cristea et al. (2026). Supply-chain work takes package source code and installation scripts as its input, which is a static representation of a different kind Zahan et al. (2025); Toda Mori (2025); Umar Zeshan et al. (2026).

Dynamic features are obtained by executing samples in instrumented environments and recording API call sequences, kernel-level file and registry operations, memory allocations, and network traffic Rat et al. (2025); F. Xu et al. (2025); Yoneda et al. (2025); Cañete Guzmán (2026). Kernel I/O sequences and early API prefixes are used for ransomware detection specifically F. Xu et al. (2025), and volatile memory dumps are used where on-disk artefacts are absent Tiwari et al. (2025). Hybrid representations combining static and dynamic information are adopted in systems that fuse code-level, behavioural, and network features W. S. Perera Jiang (2025); Salem (2025).

Two strategies are distinctive to the LLM setting. The first is textualisation, in which program artefacts are converted into natural language before analysis. Systems translate low-level operating-system events into narrative descriptions Rat et al. (2025), generate structured analysis reports from decompiled code Priambodo et al. (2025); Fujii Yamagishi (2025), or summarise function behaviour for downstream consumption T. Sun et al. (2025); Gravereaux Islam (2025). This step is what allows a general-purpose language model to operate on binaries and packages at all, and it is where the perception role is realised, which explains why perception is the only role present in every study in the corpus. The second is the mapping of observed behaviour onto structured threat intelligence taxonomies such as MITRE ATT&CK, which produces a shared vocabulary that several systems then reason over Salem (2025); Tiwari et al. (2025). Graph-based representations also appear, with attributed function-call and control-flow graphs combined with language-model embeddings Tang et al. (2026); Hossain et al. (2024).

4.3. Detection Techniques

What varies most across the corpus is not which model is used but where in the detection chain it is placed. Grouping the studies by the function the LLM performs yields four roles, summarised with their frequencies in Table 4, and this grouping proves more informative than any distinction based on whether a system calls itself an agent.

The largest group asks the model to decide. Here the characteristic move is to make a binary legible as text and then fine-tune a comparatively small encoder on it, because the verdict must be cheap and repeatable. Systems serialise permissions, manifests and API calls into token sequences and attach a classification head Sarraf (2026); Mi (2025), encode static and dynamic channels separately before fusing them into one embedding for prototype-based zero-shot decisions Al-Owaidi Cansever (2026), or map kernel-level file and API events through lightweight trainable projectors onto a frozen backbone so that only the projectors are learned (F. Xu et al. 2025). Where structure rather than text carries the signal, several representation layers are trained in synchrony and their similarity scores combined Vivekanandan et al. (2025). Where the artefact is genuinely textual, the model can be used almost unchanged, which is why the supply-chain and JavaScript work sits here Wyss et al. (2025); Shin Woo (2025); Huang Qu (2025). Network traffic is brought into the same frame by rendering flow features or raw TCP payloads as token sequences, which lets a fine-tuned encoder classify them directly Rondanini et al. (2026); Naseer et al. (2025). The recurring difficulty is length. Authors respond by selecting a core set of representative samples through clustering Dong et al. (2025), by minifying and de-duplicating code before it is submitted Wyss et al. (2025), or by partitioning call graphs into communities small enough to reason about Dai et al. (2026). A parallel line pushes in the opposite direction, asking how small the model can be. Retrieval is not always the improvement it appears to be, since a study of malicious PyPI packages found that grounding the model against YARA rules and security advisories was less effective than simply fine-tuning a small model with a few examples Ibiyo et al. (2025). Distilled encoders and sub-billion-parameter models are evaluated for deployment on edge and IoT hardware Rondanini et al. (2026), and instruction-tuned local models are fine-tuned through QLoRA to identify original entry points in packed binaries from disassembly alone Arai Kobayashi (2025). At the other extreme sit prototypes that simply prompt a hosted model with heuristic features and read back a verdict Venu et al. (2025), which bounds how little engineering the role requires.

The second group inverts the arrangement: a conventional classifier decides, and the model explains, which requires continued innovation because an explanation must be grounded in something checkable. Several systems therefore derive their ground truth from the classifier itself, generating natural-language rationales against SHAP attributions of an existing detector Gravereaux Islam (2025); Salem (2025), or mapping observed behaviour onto MITRE ATT&CK so that the explanation inherits an external vocabulary (Kumar et al. 2024,Tiwari et al. 2025). Others use the model earlier, as a semantic enricher rather than a narrator, turning sparse API symbols into descriptions that a downstream CNN or Graph Neural Networks (GNN) consumes as node features L. Zhao et al. (2026); Zhang et al. (2025); Tang et al. (2026), generating multi-view functional summaries of permissions and API before embedding them W. Zhao et al. (2025), or embedding raw sandbox reports with a frozen model so that no manual feature engineering is needed at all S. Perera et al. (2025). That this group is nearly as large as the first is the more telling fact, since it means a substantial share of the field applies language models to a purpose that never touches the detection decision. A related concern is how the quality of these explanations is measured at all, and one benchmarking framework specifies structured code-model outputs, namely function summaries, refined names and maliciousness scores, then scores them for consistency, fidelity and semantic relevance Y. He et al. (2025).

The third group asks the model to weigh evidence it did not gather. These systems are defined by what they place between the model and the verdict. A static pre-screener filters candidates before the model reviews them, with a second pass acting as judge over the first Zahan et al. (2025). Rule scanners and semantic reasoning validate each other, and missed samples are fed back to synthesise new rules Cai et al. (2025). Backward program slicing over control-flow graphs extracts only the context that matters before tier-wise summarisation Qian et al. (2025), and SHAP-derived key features from three separate classifiers over bytes, graphs and heuristics are textualised for a two-phase adjudication Zheng et al. (2025). A related multi-agent design splits Android static analysis across specialised permission, link, intent, graph and package agents, then fuses their outputs through a weighted decision agent while a language model writes the forensic explanation Wei et al. (2026). Retrieval is common here, grounding the model against a knowledge base to constrain what it may assert Guo et al. (2025); T. Sun et al. (2025). A related group applies the same adjudication machinery to unstructured intelligence rather than to binaries, extracting and classifying indicators of compromise from threat reports Chawla Prasad (2025); Boudra et al. (2025).

Only four systems let the model decide what to do next. These pair LLM reasoning with deterministic analysers invoked on demand, through supervisor-worker planning with replanning as results arrive Toda Mori (2025), ReAct loops over static analysis engines Zeng et al. (2026); Xenos et al. (2025), or a tiered architecture in which language agents generate database queries while specialised deep models watch individual subsystems Cañete Guzmán (2026). Tool use is near-universal in these four and rare elsewhere, which is the mechanical difference that separates orchestration from the other three roles. Two further systems sit at the boundary of this group without quite belonging to it, since each invokes tools in a fixed order rather than deciding the order itself. One uses a LangGraph pipeline to route static analysis, dynamic sandboxing and threat-intelligence enrichment into a reasoning agent that synthesises the evidence over SHAP-ranked classifier output Katara A (2026), and the other chains decompilation, deobfuscation, retrieval over CVE descriptions and ranking to associate a detected binary with the specific vulnerability it exploits Cristea et al. (2026).

Two cross-cutting observations follow. Adaptation tracks role closely: classifiers are usually fine-tuned, whereas reasoners and orchestrators are almost always prompted zero-shot, because a model that must select tools cannot easily be trained on the distribution of situations it will meet. Model choice, by contrast, tracks nothing at all. GPT, Gemini, LLaMA, Qwen and BERT-family encoders appear across every role, and several studies compare four or more families on identical inputs (Patsakis et al. 2024,Simion et al. 2025,Zheng et al. 2025), generally finding that the pipeline around the model matters more than the choice of model within it.

4.4. Reported Detection Performance

Table 5 aggregates the headline figures each study reports, grouped by the role the LLM plays. Two properties of the corpus limit how far the table can be read. The studies evaluate on heterogeneous data, so the entries are ranges rather than point estimates, and a substantial minority measure something other than detection, using generation-quality scores such as BLEU and BERTScore Gravereaux Islam (2025); Saha et al. (2025) or task-specific measures such as mean reciprocal rank and top-1 recall Valakuzhy et al. (2026); Fujii Yamagishi (2025). Those studies contribute no accuracy or F1-score, which is itself worth noting, since a third of the field does not measure detection at all.

Almost every group reports accuracy above $0.90$, the orchestrators occupy a narrow band near the top, and no method family is visibly worse than any other. The useful information is not in these central values but in the exceptions, because the studies reporting low numbers are mostly the ones asking harder questions.

The clearest example is the spread inside the classifier group, which runs from $0.50$ to $1.00$. The floor is not produced by weak methods. It is produced by prompting open-weight models with no adaptation, which lands at chance and is reported as a negative result Simion et al. (2025), and by recompiling the same samples through an obfuscating toolchain, which drops one model from $0.80$ to $0.53$ and halves its specificity Böke Torka (2026). A memory-forensics study reports accuracy near $0.97$ alongside an F1-score near $0.45$, purely because positives are rare enough that accuracy carries almost no information Lang Schreck (2025). Read together, these say something the aggregate cannot: performance in this corpus is a property of the evaluation conditions at least as much as of the method.

A fine-tuned model reaches 97% accuracy on PyPI packages Ibiyo et al. (2025) and a zero-shot pipeline reports 97% mean accuracy on JAR binaries Cristea et al. (2026), both on custom single-split corpora, while a study that treats malware classification as visual image recognition reports that even a fine-tuned commercial multimodal model reaches only 52% accuracy, well short of a fine-tuned vision transformer on the same task Trad Chehab (2025).

The orchestrator row invites the opposite misreading. Its band is the narrowest and highest in the table, which would seem to suggest that coordination improves detection. It does not follow, because these systems are evaluated on data they assembled themselves and never against one another. One reports $95.8\%$ accuracy on 38 malware samples, one per family, with ten benign samples for contrast Xenos et al. (2025), which is a demonstration rather than an evaluation. The narrowness of that band reflects the absence of anything that could widen it.

Two structural caveats close the section. Headline figures are not comparable across studies, since 56 of 64 evaluate on at least one corpus of their own, so two systems reporting $0.98$ have almost certainly not been asked the same question. And 44 of 64 evaluate on a single closed-world split. Where a temporal or cross-domain split is used, performance falls and becomes more variable (Feng et al. 2025,Li et al. 2025), and systems tested on held-out packers or families degrade sharply Kumar et al. (2024). Reported accuracy here measures component-level skill on curated distributions far more than the robustness coordinated detection would require.

4.5. Key Challenges

Table 6 summarises the data-related challenges the reviewed authors raise about their own work. We restrict the discussion here to obstacles concerning data and datasets, since these are what determine whether the corpus can support the coordinated detection this review is concerned with. Challenges arising from the models themselves and from composing detectors into pipelines are treated in Section 5.

Dataset scale and bespoke corpora (C1, 57 studies).

Almost every author in the corpus raises this. Evaluation sets are repeatedly described as too small to support general claims, in cases as stark as around 180 expert-verified samples Dong et al. (2025), a single malware family Fujii Yamagishi (2025), or a single injected application Li et al. (2025). The structural cause is visible in Section 4.1, where 48 of 64 studies build at least one corpus themselves. Scarcity of large labelled malicious-code collections is named directly as the obstacle (Hossain et al. 2024). The consequence is not only weaker statistics but the absence of any shared basis on which two systems could be compared, which is why C1 and C6 are two views of one problem.

Absence of runtime evidence (C2, 20 studies).

Most studies analyse static artefacts and name dynamic analysis as future work. Authors describe the resulting blind spots concretely, identifying runtime-loaded payloads and reflective class loading as underdetected Li et al. (2025), and noting that encrypted and packed samples resist static treatment because they must execute to reveal behaviour. Where dynamic data is collected, the observation window is itself a limitation, with one study noting that a short sandbox capture excludes dormant and interaction-dependent malware Rat et al. (2025). This challenge matters disproportionately here, because runtime observation is the evidence source an adaptive monitoring role would depend on.

Label quality and class imbalance (C3, 17 studies).

Labels in this corpus are usually inherited rather than established. They are derived from engine votes or clustering rather than expert review Dong et al. (2025), and several studies acknowledge that a benign label means only that no scanner objected. The problem is sometimes structural rather than incidental, as one benchmarking study names the scarcity of reliable ground truth at the function and behaviour level as a fundamental obstacle and is forced to fall back on surrogate scoring from larger models, which it acknowledges introduces noise Y. He et al. (2025). Class imbalance compounds this, and where synthetic oversampling is used to correct it, authors flag that the correction may itself introduce artefactual patterns Salem (2025). One study reports accuracy near $0.97$ alongside precision near $0.20$ purely because positives are rare Oh et al. (2024), which shows how directly label distribution propagates into the headline numbers of Section 4.4.

Generalisation to unseen malware (C4, 12 studies).

Generalisation to unseen or heavily obfuscated real-world malware is repeatedly flagged as unvalidated T. Sun et al. (2025), and strong results are sometimes attributed by their own authors to the discriminative nature of the chosen benchmark rather than to the method Bielen et al. (2025). The evidence base for this concern is thin by construction, since 56 of 64 studies evaluate on a single closed-world split. Where a study does hold out unseen packers or families, performance drops sharply Kumar et al. (2024), which suggests the concern is well founded rather than merely conventional.

Concept drift and dataset currency (C5, 18 studies).

Authors note that malware evolves faster than the corpora used to study it Sarraf (2026), and that results are tied to a particular model version and may not persist Fujii Yamagishi (2025). Only seven studies test whether performance survives a temporal split, and those that do report lower and more variable figures Li et al. (2025); Feng et al. (2025). A corpus that is small, statically sampled, imbalanced and noisily labelled has observed a narrow slice of the threat distribution, and without a temporal split there is no way to tell how narrow.

Shared benchmarks unused (C6, 4 studies).

Explicitly raised by only four studies but implied by the dispersion figures throughout this section. Authors note the lack of large-scale benchmarks and that evaluation remains confined to controlled environments Tiwari et al. (2025). Even retrieval-based work inherits this, since no single curated knowledge base proved sufficient and the authors call for a standardised malicious-code reference that does not yet exist Ibiyo et al. (2025). Taken at face value, this reads as scarcity, and until recently it was. As Section 4.1 sets out, a parallel literature now supplies behavioural, forensic and multi-architecture resources built for precisely the evaluation these authors describe as impossible Dunsin et al. (2025); Dadkhah et al. (2026); Onwuegbuche et al. (2026); Hirano Kobayashi (2025).

4.6. Dataset - Method Relationships

Classifying each study by the modality of the data it uses, as encoded by colour in Figure 4, shows that the corpus leans heavily toward static data, followed by dynamic or behavioural data and hybrid or multimodal data, with the custom datasets being spread across the three modalities. Mapping these modalities onto the datasets used, and the roles the model plays, reveals three consistent patterns.

Finding 1: The dataset landscape is fragmented and the largest single resource is not shared at all 

A small number of benchmarks recur, led by AndroZoo, VirusTotal, VirusShare and MalwareBazaar, followed by the Android families Drebin, CIC-AndMal2017 and CICMalDroid2020. Around thirty further datasets appear exactly once. Dominating all of them is the bespoke corpus, present in 48 of 64 studies and therefore more than five times more common than the most-used public benchmark. The dataset landscape is not merely fragmented, it is anchored by a resource that by definition cannot be reused.

Finding 2: Method choice is conditioned by dataset modality, and both are conditioned by domain 

Static benchmarks pair overwhelmingly with the classifier role, where serialised permissions, manifests and package source feed a fine-tuned or prompted model that emits a verdict. Behavioural and dynamic corpora pair instead with the interpretability role, because sandbox and kernel traces are what a model can usefully narrate. The pattern is strongest in the Android and supply-chain domains, where a static representation is cheaply available, and the classifier role therefore dominates. Modality is thus partly a property of method design rather than of the dataset alone, and domain choice largely settles both.

Finding 3: The systems closest to agentic operation rely most heavily on data they built themselves 

The four orchestrator systems and the six primary-agent systems evaluate almost entirely on bespoke corpora, typically assembled by executing samples in sandboxes or crawling package registries. This was not an oversight at the time these systems were built. The continuous, multi-stage, distributed telemetry a coordinated pipeline consumes did not exist as a public benchmark, so authors constructing such pipelines had no alternative but to assemble one. That is now changing. Datasets pairing clean and infected memory snapshots Dunsin et al. (2025), or combining network, system-call and resource traces across four architectures Dadkhah et al. (2026), have appeared within the window this review covers. The currency problem is therefore most acute exactly where adaptive evaluation matters most, and it remains self-reinforcing for as long as each new system continues to produce evidence that no successor reuses.

Implications for agentisation. 

Read together, these findings yield a portable lesson that motivates Section 5. Because method choice is locked to modality, the datasets that dominate the high-accuracy results, which are the static benchmarks paired with single-decision classifiers, are precisely the ones that expose no intermediate signals for an agent to act on. Agentising such detectors buys little. The behavioural and sandbox corpora are the ones that surface the runtime evidence, feedback paths and multi-stage structure an agent pipeline needs, yet they are the least standardised and least reused resources in the corpus. The available data is therefore well matched to component-level evaluation of individual classifiers, where reported performance is uniformly high, but poorly aligned with the needs of coordinated, adaptive and distributed detection. This misalignment motivates a closer look at the systems that attempt coordination directly.

5. Analysis of Agent-Based Malware Detection Systems

Whereas Section 3 positioned this review against prior surveys and Section 4 analysed the dataset and method landscape of the primary corpus, this section analyses the agent-based systems within that corpus directly. Its subject is the primary systems themselves, and its organising question is the one set out in Section 1: how far does the implemented literature fulfil the four functional roles an agent-based detection pipeline must serve, which are perception, reasoning and decision-making, adaptive monitoring, and collaborative learning.

The agent-based subset is small but has grown. Of the 64 primary studies, six place agents at the centre of the detection architecture and six use an agent abstraction for a single sub-task, giving twelve systems in total. Five further studies treat agents as a conceptual lens without implementing one Simion et al. (2025); Lee Easttom (2025); Tiwari et al. (2025); Zheng et al. (2025); Qian et al. (2025), and the remaining 47 use no agent abstraction at all. Section 5.1 examines how the twelve implemented systems decompose the detection pipeline and which roles they fill, Section 5.2 characterises the coordination they achieve, and Section 5.3 draws these together with the wider corpus into an assessment of what agentisation would require and what currently blocks it.

5.1. Pipeline Decomposition and Role Coverage

Malware detection can be described as a multi-stage pipeline spanning ingestion, static analysis, dynamic analysis, feature extraction, detection and classification, correlation and reasoning, and response or mitigation. Figure 5 records, for each of the twelve agent-based systems, which of these stages it implements and which of the four functional roles from Section 1 it fulfils. A stage or role counts as covered when a system implements a dedicated component for it and the authors evaluate or demonstrate it, partial when it is handled implicitly, delegated to an external tool, or described but not evaluated, and not covered when it is absent or named by the authors as a limitation.

The pipeline block has a characteristic shape: dense on the left, thinning to the right. Every system ingests, nearly every one extracts features and classifies, and most correlate. The thinning begins at dynamic analysis and becomes severe at response. What makes this more than an observation about effort is that the two columns are related. A system that never observes execution has nothing to respond to, so the same architectural decision empties both. Authors describe the boundary in those terms, deferring sandbox logs and memory forensics to future work Zeng et al. (2026) or restricting analysis to static artefacts while acknowledging that packed or encrypted samples would have to run before anything could be seen Saraga et al. (2025). Where response is reached at all, it is reached by systems that already watch the host, and it takes the form of a fixed rule rather than a decision, whether interrupting a process on a team-consensus verdict Cañete Guzmán (2026) or routing an alert through predefined analysis tiers Zeng et al. (2026).

The role block tells a sharper story, and it is why this review classifies by function rather than by architecture, as perception and reasoning are well covered in the literature, whereas adaptive monitoring and collaborative learning are left out almost everywhere. The two roles a standalone classifier can perform on its own are performed almost everywhere, including by systems making no claim to being agents. The two that require a system to persist across time or across machines are performed almost nowhere, including by systems that do call themselves agents.

There is one exception that covers adaptive monitoring by a sandbox rather than a classifier: a defensive reinforcement-learning agent reconfigures the analysis environment in response to evasion while an offensive agent learns to evade it, so adaptation is a property of the observation apparatus, not of the verdict S. Perera et al. (2025). Adaptation, in other words, has so far been achieved where a system controls its environment, and collaboration where it was designed in from the start rather than added to a detector afterwards. Neither capability has yet been demonstrated inside a language-model pipeline, which is what Section 5.3 takes up.

5.2. Coordination in Existing Agent Systems

The 17 systems fall into three recognisable groups, distinguished less by what they detect than by how their components talk to one another.

LLM-orchestrated pipelines

The largest and most recent group uses an LLM to select and sequence deterministic analysis tools. A supervisor agent plans an investigation and dispatches worker agents for deobfuscation and web research, replanning as intermediate results arrive Toda Mori (2025). A ReAct loop drives on-demand calls to static analysis engines across screening, forensics and adjudication tiers Zeng et al. (2026). A further orchestrated pipeline uses LangGraph to sequence static, dynamic and threat-intelligence stages into an adaptive reasoning agent, and is among the few in the corpus to implement learned rather than fixed coordination Katara A (2026). A CrewAI pipeline hands a package between fetcher, extractor, classifier and verdict agents Umar Zeshan et al. (2026). These systems are the closest the corpus comes to genuine agency, and Toda Mori (2025) implement adaptive replanning rather than a fixed hand-off.

Hierarchical and distributed architectures

A second group distributes detection across levels or hosts. A four-level AutoGen architecture routes live system events to per-subsystem deep models for registry, file system and network activity, then reaches team consensus before interrupting a process Cañete Guzmán (2026). A multi-agent Android system splits static analysis across specialised permission, link, intent, graph, and package agents whose verdicts are fused by a decision agent Wei et al. (2026), and a lightweight design pushes detection to the edge and Internet of Things (IOT) nodes rather than to a central server Rondanini et al. (2026). These are the only systems in the corpus that operate across more than one node, and there are three of them.

Fixed multi-stage validators

The remaining systems use several model instances in a fixed pipeline without autonomous control. A scanner, analyser and generator form a detection-verification-evolution loop in which missed samples become new rules Cai et al. (2025). A multi-step workflow adds an LLM-as-a-judge review stage over per-file JSON reports Zahan et al. (2025). A retrieval pipeline converts static features to natural-language descriptions before classification Saraga et al. (2025). Another fuses five specialised static-analysis agents through a weighted decision agent, coordinating them by fixed weights rather than autonomous control Wei et al. (2026).

Coordination across all three groups is shallow. Of the whole corpus, 39 studies use fixed weights or a fixed ordering, 20 use none at all, and only five implement consensus or learned coordination Cañete Guzmán (2026); Toda Mori (2025); Katara A (2026). Only six studies use a recognisable orchestration framework, and only three operate in distributed fashion. Authors say so themselves: inter-agent weights are set by experts rather than learned, with adaptive mechanisms named as future work, and communication of intermediate scores between agents is described as a planned extension rather than an implemented feature (Cañete Guzmán 2026). Several MASs in fact run on a single machine Umar Zeshan et al. (2026). What the corpus calls multi-agent is, in most cases, a modular pipeline with an LLM at one or more of the joints.

5.3. Findings: Agentisation Potential, Missing Roles, and Research Gaps

This subsection consolidates the preceding analysis. It states what the corpus already provides, what it does not, how the missing capabilities might be obtained, and which gaps remain open.

Finding 4: Two roles are effectively solved, one is served by a single system, and one by none 

The distribution of role coverage is not gradual but bimodal. Perception is served in every study in the corpus without exception, because textualisation is what makes a binary legible to a LLM at all, and no system can proceed without it Rat et al. (2025); Priambodo et al. (2025); Fujii Yamagishi (2025). Reasoning is served in most cases, whether by a model that emits the verdict Sarraf (2026); Dai et al. (2026) or one that adjudicates a verdict made elsewhere Zahan et al. (2025); Cai et al. (2025). Adaptive monitoring and collaborative learning are served by almost none. The practical consequence is that the ingredients for the first half of an agent pipeline are abundant and interchangeable, while the second half must largely be built.

Finding 5: Agentisation potential is high where intermediate signals already exist 

Classifying every study by how readily it could be lifted into an agent architecture yields six systems already agentised, five with high potential, 33 with medium, and 17 with low. The discriminating property is consistent across the corpus and is visible in the authors’ own descriptions. Systems rated high expose structured intermediate signals and a feedback path: interpretable system-call data with arguments and return values that could drive a dialogue with the model Yoneda et al. (2025), per-file JSON reports with confidence scores feeding an LLM-as-a-judge stage Zahan et al. (2025), a generator that converts missed samples into new detection rules Cai et al. (2025), SHAP-ranked artefact graphs with an analyst-in-the-loop path back into retraining Tiwari et al. (2025), and re-ranking scores across a decomposed retrieval pipeline T. Sun et al. (2025). Systems rated low share the opposite property, which is a single closed decision over a fixed input with nothing observable in between Simion et al. (2025); Böke Torka (2026); Minh et al. (2026). One study explicitly considered an agentic design and deliberately chose a fixed two-stage workflow instead Valakuzhy et al. (2026).

The practical test for agentisation is therefore not which model family a system uses but whether it exposes anything between input and verdict. This connects directly to Finding 2 in Section 4.6: static benchmarks paired with single-decision classifiers dominate the high-accuracy results and are precisely the systems with nothing to expose.

Finding 6: The missing roles are missing for structural reasons, not for want of technique 

Adaptive monitoring is absent because the evidence it consumes is absent. It requires runtime observation, and 38 of 64 studies perform no dynamic analysis at all. Where authors do collect behavioural data, they note that the observation window itself bounds what can be seen, so dormant and interaction-dependent malware escapes Rat et al. (2025). The 17 studies with partial monitoring are the ones that already touch runtime evidence Yoneda et al. (2025); Cañete Guzmán (2026), which suggests the barrier is access to data rather than any missing algorithm.

Collaborative learning is absent for a different reason. Standalone detectors have no incentive to distribute, and in the few systems where distribution appears it is inherited from an agent architecture rather than driven by the detector Cañete Guzmán (2026); Wei et al. (2026). No system in the corpus fully realises the collaborative-learning role, in which independently deployed detectors share evidence and refine a collective decision over time. The ingredient is not technically out of reach, since coordination can be added as a control layer over existing components rather than requiring them to be retrained, but at present it remains unrealised.

Finding 7: A plausible path to multi-agent operation runs through the existing frameworks 

Taken together, the corpus suggests an ordering of difficulty. Perception and reasoning can be populated by lifting existing components more or less directly, since the same model families already appear on both sides of the agent boundary and several non-agent studies already invoke external tools T. Sun et al. (2025); Oh et al. (2024); Bielen et al. (2025), which is the mechanical prerequisite for tool-using agents. Adaptive monitoring requires runtime hooks and a sustained observation window. This was until recently an engineering and data-collection problem in equal measure. It is now mostly the former, since multi-layer runtime corpora and memory-snapshot datasets built for agentic use are publicly available Dadkhah et al. (2026); Dunsin et al. (2025). Systems that already ingest kernel or sandbox telemetry are natural starting points Yoneda et al. (2025); Cañete Guzmán (2026). Collaborative learning requires a coordination layer that does not currently exist in most designs, but the systems implementing consensus or learned coordination Cañete Guzmán (2026); Toda Mori (2025); Katara A (2026) demonstrate that it can be retrofitted above unmodified detectors. The principal open problem is therefore integration and orchestration rather than the invention of new detection primitives.

Research gaps 

Five gaps follow, the first four raised by the reviewed authors themselves and the last identified by this review.

G1: Runtime evidence. The most frequently deferred item in the agent subset is dynamic analysis, named as future work by systems that are otherwise complete Zeng et al. (2026); Saraga et al. (2025); Umar Zeshan et al. (2026). Without it, the adaptive monitoring role cannot be filled by any means.

G2: Adaptive coordination. Where coordination exists, it is usually fixed. Authors name learned or adaptive inter-agent weighting as the intended next step, and note that exchanging intermediate scores between agents remains unimplemented Cañete Guzmán (2026).

G3: Reliability of agent reasoning. Non-determinism is reported as an architectural problem rather than a nuisance. Models repeat mistakes that temperature adjustment does not fix Zahan et al. (2025), and overly detailed investigations time out Toda Mori (2025). A pipeline that multiplies model calls multiplies this exposure.

G4: Cost and provider dependence. Dependence on a commercial API is identified as an architectural risk with an in-house model named as the intended remedy Cañete Guzmán (2026).

G5: Available evaluation data goes unused. This review adds a gap the individual authors cannot see from inside their own studies, and it is not the one they describe. All twelve agent systems evaluate on data they assembled themselves or on a single benchmark, none is compared against another, and the orchestrator group reports the narrowest and highest performance band in the corpus precisely because nothing constrains it. The authors attribute this to a lack of suitable resources, and Section 4.5 records that attribution. Read against the dataset literature, the attribution no longer holds. Corpora designed for exactly this purpose exist, including paired clean and infected volatile-memory snapshots constructed to support reinforcement-learning and agentic frameworks Dunsin et al. (2025), multi-architecture collections combining network captures, system-call traces and resource logs Dadkhah et al. (2026), hypervisor-layer behavioural data designed to resist evasion Hirano Kobayashi (2025), and a balanced behavioural benchmark spanning nearly two decades Onwuegbuche et al. (2026). The obstacle is therefore adoption rather than existence.

6. Discussion

The preceding two sections analysed the corpus from different angles. Section 4 asked what data and methods the field works with, and Section 5 asked what the agent-based systems within it actually do. This section reads the seven findings together and draws out what they say as a whole.

The field varies in where the model sits, not in which model is used

The most consistent pattern across the corpus is also the least expected. Model family predicts almost nothing. GPT, Gemini, LLaMA, Qwen and BERT-family encoders appear in every role, and the studies that compare four or more families on identical inputs generally conclude that the pipeline around the model matters more than the choice of model within it. What varies is position in the detection chain. A model may emit the verdict, explain a verdict reached elsewhere, weigh evidence it did not gather, or decide which tool to run next, and these four arrangements behave differently in ways that the label attached to the system does not capture. This is why the review classifies by function rather than by architecture, and it is the reason a system calling itself an agent tells a reader very little about what it does.

The corollary is that nearly as many studies use LLMs to explain a decision as to make one. That is a substantial share of the field applying these models to a purpose that never touches detection at all, which is worth stating plainly because headline accuracy figures obscure it.

Role coverage is bimodal, and the two gaps have different causes

Perception and reasoning are served almost everywhere, including by systems making no claim to being agents, with adaptive monitoring being covered once and collaborative learning never occurring. This is not a gradual decline across roles but a sharp division, and the two halves are separated by a simple property. Perception and reasoning are things a standalone classifier can do on its own. Monitoring and collaboration require a system to persist over time or to span more than one machine, which no single classifier does by construction.

The two gaps are not the same, though. Adaptive monitoring is scarce because the evidence it consumes is scarce, since more than half the corpus performs no dynamic analysis at all. It is an evidence problem. Collaboration is scarce because a standalone detector has no reason to distribute, so wherever distribution appears it arrives with an agent architecture rather than from the detector itself. It is a design problem. The distinction matters, because the remedies differ. One is closed by feeding a system better data, the other by adding a coordination layer above components that need not change.

Both exceptions are instructive precisely because neither is a conventional detector. Adaptive monitoring is covered by a sandbox that reconfigures itself in response to evasion, so adaptation belongs to the observation apparatus rather than to the verdict. Collaboration is covered by a pre-LLM peer-to-peer system whose detection performance is the weakest we record. Neither capability has yet been demonstrated inside a language-model pipeline.

High reported accuracy is a weak signal of progress

Almost every group of studies reports accuracy above 0.90, and no method family looks visibly worse than any other. The informative content sits in the exceptions rather than in these central values. Models prompted without adaptation fall to chance. The same samples recompiled through an obfuscating toolchain drop one system from 0.80 to 0.53. A memory-forensics study reports accuracy near 0.97 alongside an F1-score near 0.45 because positives are rare enough that accuracy carries almost no information. In each case the low number comes from asking a harder question, not from using a weaker method.

The orchestrator group invites the opposite misreading. Its band is the narrowest and highest in the corpus, which looks like evidence that coordination improves detection. It is not, because these systems are evaluated on data their authors assembled and never against one another. One reports 95.8% accuracy on 38 malware samples. The narrowness of that band reflects the absence of anything that could widen it.

The practical test for agentisation is whether a system exposes anything between input and verdict

Sorting the corpus by how readily each system could be lifted into an agent architecture produces a clean split, and the property doing the sorting is not model choice, dataset size or reported accuracy. It is whether the system surfaces intermediate signals and a path for feedback to act on them. Systems that expose confidence scores, structured reports, ranked candidates or rules regenerated from missed samples are straightforward to agentise. Systems that make a single closed decision over a fixed input are not, and one study in the corpus considered an agentic design and deliberately chose a fixed workflow instead.

This connects the two halves of the review. Static benchmarks pair with single-decision classifiers, those pairings dominate the high-accuracy results, and they are exactly the systems with nothing to expose. The data that produces the best numbers is therefore the data least suited to the architecture the field says it is moving toward. Agentising such detectors buys very little.

The evaluation gap has changed character

Every agent system in the corpus evaluates on data its authors assembled or on a single benchmark, and none is compared against another. The authors attribute this to a lack of suitable resources, and until recently that attribution was correct. It no longer is. Datasets built for exactly this purpose now exist, including paired clean and infected memory snapshots constructed to support agentic frameworks and multi-architecture collections combining network, system-call and resource traces. Not one detection study in the corpus evaluates on them.

This turns an availability problem into an adoption problem, which is both a different claim and a more tractable one. It calls not for new data collection but for the detection literature to evaluate against resources its own citations already acknowledge. The likely explanation is mundane, in that dataset papers and detection papers are published into largely separate literatures, and a review positioned across both is one of the few vantage points from which the mismatch is visible at all.

What this means taken together

The picture that emerges is of a field with abundant, well-validated components and very little experience composing them. The first half of an agent pipeline can be assembled from parts that already exist and are largely interchangeable. The second half must be built, but the ingredients for that are closer to hand than the literature suggests, since runtime corpora are now available and the handful of systems implementing consensus or learned coordination show that a coordination layer can sit above detectors that are not modified at all. The principal open problem is integration and orchestration rather than the invention of new detection primitives, and the principal obstacle to knowing whether integration helps is that nobody has yet measured it on data anyone else can reuse.

6.1. Threats to Validity

Several limitations bound the conclusions of this review, and we state them plainly so that readers can weigh the findings accordingly.

Reliance on reported results.

The performance figures analysed in Section 4.4 are those the original authors report, and we did not reproduce any experiment. Because the studies evaluate on heterogeneous, often bespoke data under mostly single closed-world splits, these numbers are not directly comparable, a point we treat as a finding rather than a nuisance. Even so, the ranges we present inherit whatever optimism, selective reporting, or evaluation weakness is present in the primary sources, and they should be read as a description of what the literature claims rather than as a verified benchmark.

Classification judgement.

The functional-role and pipeline-coverage classifications that carry Section 5 rest on our reading of each paper. Several systems sit at the boundary between categories, for example a retrieval pipeline that could be read either as a tool-using reasoner or as an orchestrator, and reasonable reviewers could code a handful of these differently. We resolved such cases by a consistent rule, treating a system as an LLM agent only where a language model drives the behaviour rather than sitting beside a classical or reinforcement-learning pipeline, but we acknowledge that a different rule would shift some counts by one or two. We have tried to make the coding transparent enough that these choices are visible rather than hidden.

Strength of the agent-level conclusions.

The role-coverage and agentisation analysis in Section 5 rests on the twelve systems that place agents at the centre of the architecture, since these are the only ones for which the question is meaningful. That this subset is small is itself among our findings, and it reflects the genuine state of an emerging field rather than a gap in the review. A statement such as collaborative learning being realised by no system in the corpus is a claim about the present, and as the agent-based strand grows these specific counts will change even if the structural pattern we identify, that perception and reasoning are populated while monitoring and collaboration are not, is likely to persist.

7. Future Work

This review has argued that agent-based and multi-agent malware detection is a young strand of a mature field. Only 12 of the studies we examined place agents at the centre of the detection architecture, and genuine coordination among them is rare. We do not, therefore, present multi-agent detection as an established practice. We present it as a direction the evidence points toward, and this section sets out what pursuing it will require. The first part follows from the analysis in Section 5 and concerns building coordinated detectors. The second concerns a threat that grows in exact proportion to how far the field moves in that direction, namely that the agents doing the detecting, and the models they defend against, are themselves becoming adversarial tools.

7.1. Building Coordinated Detection Systems

Three priorities follow directly from the findings of Section 5.

The first is integration rather than invention. Perception and reasoning are already served throughout the corpus by interchangeable components, so the immediate problem for most systems is composing well-understood detectors into a coordinated pipeline rather than designing new detection primitives. The open question is which orchestration substrate, whether sequential role specialisation, hierarchical routing or peer consensus, best preserves the validated behaviour of the underlying components while adding adaptive control.

The second is closing the collaboration gap. Collaboration is the one role that agent architectures add rather than inherit, and it is almost entirely absent from the standalone detectors that make up most of the corpus. Bringing distributed and federated operation into otherwise single-node detectors is therefore the most promising way to advance the field, and Section 5 suggests an order of difficulty for doing so, with behavioural and multimodal methods first and static single-decision classifiers last.

The third is evaluation. As Section 4.5 showed, the data needed to test coordinated detection has begun to appear but goes unused, so the near-term task is not to collect new data but to evaluate agent pipelines against the behaviour-rich, temporally structured resources that already exist, under temporal and cross-domain splits rather than the single closed-world splits that dominate the corpus. Standardised benchmarks that measure pipeline-level rather than component-level behaviour remain a prerequisite for comparable progress.

7.2. The Adversarial Use of Agents

The same properties that make agents attractive for defence make them dangerous in the hands of an attacker, and a fast-growing body of work that sits just outside our detection-focused corpus demonstrates this directly. We highlight it here because a review of agent-based detection would be incomplete without acknowledging that the attacker is agentising too.

The clearest evidence is in adversarial malware generation. Language models have been shown to rewrite malware at the source-code level while preserving function, producing variants that evade detectors without fine-tuning the model at all Akil et al. (2025); Madani (2023); Coppolino et al. (2026). Framed as an agent loop, this becomes autonomous, as systems now generate, execute, debug and evolve a payload against a sandbox until it slips past behavioural detection E et al. (2026), and reinforcement learning guided by a language model can search the perturbation space of Windows binaries for functionality-preserving evasions Liu et al. (2026). Dedicated frameworks pair generative models for the same end, whether a GAN with a language model to craft evasive samples for black-box detectors Devadiga et al. (2023), a dual-agent design that attacks Android detectors Lan Nait-Abdesselam (2025), or multi-agent bandits that build universal perturbations against attribution models Y. Sun et al. (2026). The systematic studies confirm the pattern, showing that off-the-shelf models can already produce working malware and attack tools from decomposed prompts Pa Pa et al. (2023). The detectors this review analyses will therefore increasingly be tested against adversaries produced by the very techniques used to build them.

A second concern is that a multi-agent detector is itself an attack surface. Coordination introduces failure modes a single model does not have. Adversarial content can hijack the control flow of a multi-agent system, prompts can self-replicate from agent to agent in a manner conceptually close to a computer virus, and blocking attacks can propagate recursively until the system halts Zhou et al. (2025). Extending the analogy further, work on ransomware against AI assets treats trained models, datasets and agent configurations as the targets of extortion rather than ordinary files Govindarajulu Karimi (2026), and propagation on the physical side has long been modelled at the level of individual nodes in a sensor network, where malware spread and component failure cascade into one another B. Xu et al. (2021). Defending the pipeline therefore becomes a detection problem in its own right, and graph-based runtime oversight of the interactions between agents has been proposed as one response X. He et al. (2025).

Taken together, these two directions describe a single trajectory. As detection becomes coordinated and adaptive, so does attack, and the boundary between the system that defends and the system that attacks grows thinner. We therefore see the security of multi-agent detection pipelines not as a footnote to building them but as an inseparable part of the same research programme.

8. Conclusion

This review set out to examine malware detection not as a catalogue of isolated techniques but as a coordinated, multi-stage system, and to ask how far the current literature is positioned to support agent-based operation. Reading the survey comparison, the dataset and method analysis, and the study of agent-based systems together, a single picture emerges.

At the component level, the field is mature, and its reported performance is high, with headline accuracies clustered in a narrow band across the corpus. Yet that strength rests on a fragile base. What varies across the literature is not which model is used, since model family predicts almost nothing, but where in the detection chain the model sits. Nearly as many systems use a language model to explain a verdict as to reach one. A small number of ageing benchmarks recur, method choice is locked to data modality, and most studies, including most agent-oriented ones, fall back on bespoke corpora evaluated under a single closed-world split. The uniformly high scores therefore measure component-level skill on curated distributions far more than the robustness that adaptive, real-world detection demands.

Against this backdrop, the analysis of agent-based systems revealed a consistent imbalance. Of the four functional roles a coordinated pipeline requires, perception and reasoning are served almost everywhere, including by systems that make no claim to being agents, whereas adaptive monitoring is realised by a single system and collaborative learning by none. The two gaps have different causes. Monitoring is scarce because the runtime evidence it consumes is scarce, and collaboration is scarce because a standalone detector has no reason to distribute. Where coordination does appear, it is usually shallow, and several of the most behaviour-rich systems run on a single host rather than being genuinely distributed.

The central contribution of this review follows from reading these two pictures together. Because abundant standalone detectors and the few existing agent systems draw on the same underlying model families, agent-based malware detection is emerging atop a large body of validated components rather than displacing them. The practical test for whether a detector can be lifted into an agent architecture is not its model or its accuracy, but whether it exposes anything between input and verdict; the systems that produce the best numbers are precisely those that expose nothing. The principal open problem is therefore integration and orchestration rather than the invention of new detection primitives, with behavioural, multimodal and distributed methods the most natural candidates and static single-decision classifiers the least. The principal obstacle to knowing whether integration helps is that the data needed to test it has begun to appear but goes unused, which turns a problem of availability into one of adoption.

Looking ahead, the same properties that make coordination attractive for defence make it available to attack. As detection becomes adaptive, so does the adversary, LLMs are already being turned to the generation of evasive malware, and a multi-agent detector is itself an attack surface. Securing the detection pipeline is thus not a footnote to building one but an inseparable part of the same effort.

The recurring message across all of this is the same. The field has accumulated strong, well-validated components but has rarely examined them as perceiving, reasoning, monitoring, or collaborating parts of a larger whole. Closing that gap, above all on the collaboration dimension, supported by data designed for coordinated rather than standalone evaluation and underpinned by security models appropriate to multi-agent infrastructure, is in our view the most promising path toward malware detection that can keep pace with an adversary that is itself becoming adaptive and automated.

Appendix A.1. Complete Corpus of Reviewed Literature

Table A1. Complete corpus of literature reviewed in this work, grouped by role. Within each group, entries are ordered alphabetically by first author.

Table A1. Complete corpus of literature reviewed in this work, grouped by role. Within each group, entries are ordered alphabetically by first author.

Reference	First author	Year	Title
Reviews of LLM and agentic methods (Section 3.2) (12)
Ahi Valizadeh (2025)	Ahi	2025	Large Language Models (LLMs) and Generative AI in Cybersecurity and Privacy: A Survey of Dua...
Albalooshi et al. (2025)	Albalooshi	2025	Malware Detection and Analysis Using LLMs: A Review of Emerging Trends and Techniques
Champie Elish (2026)	Champie	2026	Large Language Models for Malware Detection: A Systematic Review, Taxonomy, and Open Challenges
Jelodar et al. (2026)	Jelodar	2026	Large language model (LLM) for software security: Code analysis, malware analysis, reverse e...
Kshetri (2025)	Kshetri	2025	Transforming cybersecurity with agentic AI to combat emerging cyber threats
Lazer et al. (2026)	Lazer	2026	A Survey of Agentic AI and Cybersecurity: Challenges, Opportunities and Use-case Prototypes
Panwar Abdelrahman (2025)	Panwar	2025	Agentic AI in Cybersecurity Review of Autonomous Threat Detection and Adaptive Defense Mecha...
Ramírez-Martínez et al. (2026)	Ramírez-Martínez	2026	Generative AI for Ransomware Identification and Mitigation: Taxonomy, Challenges, and Future...
Shahriar et al. (2025)	Shahriar	2025	A Survey on Agentic Security: Applications, Threats and Defenses
Tadesse Mbaziira (2025)	Tadesse	2025	An Extended Review on Analyzing Malware Using Agentic AI and Cognitive Architectural Processes
Vinay (2026)	Vinay	2026	The Evolution of Agentic AI in Cybersecurity: From Single LLM Reasoners to Multi-Agent Syste...
H. Xu et al. (2025)	Xu	2025	Large Language Models for Cyber Security: A Systematic Literature Review
Datasets as primary contribution (Section 4.1) (9)
Borah et al. (2020)	Borah	2020	Malware Dataset Generation and Evaluation
Dadkhah et al. (2026)	Dadkhah	2026	CIC-YNU-IoTMal: A comprehensive multilayer dataset for static and dynamic analysis of IoT ma...
Dunsin et al. (2025)	Dunsin	2025	MalVol-25: A Diverse, Labelled and Detailed Volatile Memory Dataset for Malware Detection an...
Hirano et al. (2022)	Hirano	2022	RanSAP: An open dataset of ransomware storage access patterns for training machine learning ...
Hirano Kobayashi (2025)	Hirano	2025	RanSMAP: Open dataset of Ransomware Storage and Memory Access Patterns for creating deep lea...
Joyce et al. (2023)	Joyce	2023	MOTIF: A Malware Reference Dataset with Ground Truth Family Labels
Letteri et al. (2020)	Letteri	2020	MTA-KDD’19: A Dataset for Malware Traffic Detection
Noever Noever (2021)	Noever	2021	Virus-MNIST: A Benchmark Malware Dataset
Onwuegbuche et al. (2026)	Onwuegbuche	2026	MLRan: A behavioural dataset for ransomware analysis and detection
Primary detection studies (main corpus) (64)
Adamec Turčaník (2025)	Adamec	2025	Malware Detection with LLM
Al-Owaidi Cansever (2026)	Al-Owaidi	2026	Dual-Channel LLM-Guided Semantic Feature Extraction with Zero-Shot Classification for Zero-D...
Arai Kobayashi (2025)	Arai	2025	Staged LLM-Based Original Entry Point Identification Using Disassembled Code
Bielen et al. (2025)	Bielen	2025	Ransomware Detection using LLMs and GraphRAG
Boudra et al. (2025)	Boudra	2025	Toward Lightweight IoC Extraction in IoT: The Role of Small Language Models
Böke Torka (2026)	Böke	2026	“Digital Camouflage”: The LLVM challenge in LLM-based malware detection
Cai et al. (2025)	Cai	2025	MalGuard: Malicious Package Detection Based on Dual Validation of Rule Scanning and Large La...
Cañete Guzmán (2026)	Cañete	2026	A Hybrid Architecture Combining Agentic AI and Deep Learning Techniques for Preventing of Ma...
Chawla Prasad (2025)	Chawla	2025	Proactively Detecting Threats: A Novel Approach Using LLMs
Cristea et al. (2026)	Cristea	2026	MalCVE: Malware Detection and CVE Association Using Large Language Models
Dai et al. (2026)	Dai	2026	AndroSem: Semantics-Guided, LLM-based Interpretable Static Android Malware Detection
Dong et al. (2025)	Dong	2025	LeoDroid: An LLM-Based Few-Shot Multi-Label Detection for Android Malware
Feng et al. (2025)	Feng	2025	LLM-MalDetect: A Large Language Model-Based Method for Android Malware Detection
Fujii Yamagishi (2025)	Fujii	2025	Feasibility Study for Supporting Static Malware Analysis Using LLM
Gravereaux Islam (2025)	Gravereaux	2025	Accuracy and Efficiency Trade-Offs in LLM-Based Malware Detection and Explanation: A Compara...
Guo et al. (2025)	Guo	2025	Malgta: large language model-based guided malware tactical analysis
Y. He et al. (2025)	He	2025	On Benchmarking Code LLMs for Android Malware Analysis
Hossain et al. (2024)	Hossain	2024	Malicious Code Detection Using LLM
Huang Qu (2025)	Huang	2025	SemanticSentinel: LLM-Based Semantic Consistency for Malicious Package Detection
Ibiyo et al. (2025)	Ibiyo	2025	Detecting Malicious Source Code in PyPI Packages with LLMs: Does RAG Come in Handy
Katara A (2026)	Katara	2026	Adaptive Malware Defense: A Multi-Agent System for Malware Detection and Adaptive Response
Kumar et al. (2024)	Kumar	2024	Prompt Chaining-Assisted Malware Detection: A Hybrid Approach Utilizing Fine-Tuned LLMs and ...
Lang Schreck (2025)	Lang	2025	Leveraging LLMs for Memory Forensics: A Comparative Analysis of Malware Detection
Lee Easttom (2025)	Lee	2025	A Novel Framework for Malware Analysis: Integrating Large Language Models with Heuristic Tec...
Li et al. (2025)	Li	2025	ForeDroid: Scenario-Aware Analysis for Android Malware Detection and Explanation
Mehta et al. (2026)	Mehta	2026	Transformer Framework Enhanced by Large Language Models for Image-based Multi-class Malware ...
Mi (2025)	Mi	2025	Malicious Code Detection Models Based on the Large Language Model ModernBERT
Minh et al. (2026)	Minh	2026	Multimodal Learning with LLM-Fusion Head for Android Malware Detection: Enhancing Cross-Moda...
Naseer et al. (2025)	Naseer	2025	Obfuscated Malware Detection and Classification in Network Traffic Leveraging Hybrid Large L...
Oh et al. (2024)	Oh	2024	volGPT: Evaluation on triaging ransomware process in memory forensics with Large Language Model
Patsakis et al. (2024)	Patsakis	2024	Assessing LLMs in malicious code deobfuscation of real-world malware campaigns
S. Perera et al. (2025)	Perera	2025	Project HyperAdapt: An Agent-Based Intelligent Sandbox Design to Deceive and Analyze Sophist...
W. S. Perera Jiang (2025)	Perera	2025	BEACON: Behavioral Malware Classification with Large Language Model Embeddings and Deep Lear...
Priambodo et al. (2025)	Priambodo	2025	MalQwen: Fine Tuned LLM for Static Android Malware Analysis Report
Qian et al. (2025)	Qian	2025	LAMD: Context-Driven Android Malware Detection and Classification with LLMs
Rat et al. (2025)	Rat	2025	ArA - Evaluating LLM Suitability as Out-of-the-Box Malware Analysts
Rondanini et al. (2026)	Rondanini	2026	Malware Detection at the Edge with Lightweight LLMs: A Performance Evaluation
Saraga et al. (2025)	Saraga	2025	Enhancing Android Malware Detection with Retrieval-Augmented Generation
Saha et al. (2025)	Saha	2025	MaLAware: Automating the Comprehension of Malicious Software Behaviours using Large Language...
Salem (2025)	Salem	2025	Redefining Threat Intelligence: How LLMs Revolutionize Malware Detection
Sarraf (2026)	Sarraf	2026	LLM-Guard Semantic Analysis for Android Malware Detection Using Foundation Models
Shin Woo (2025)	Shin	2025	Semantic and structural fusion for malware detection: Leveraging CodeBERT, GraphCodeBERT, an...
Simion et al. (2025)	Simion	2025	Benchmarking Out of the Box Open-Source LLMs for alware Detection Based on API Calls Sequences
T. Sun et al. (2025)	Sun	2025	RAML: Toward Retrieval-Augmented Localization of Malicious Payloads in Android Apps
Tang et al. (2026)	Tang	2026	MCLPF: Malware Collaborative Detection With LLM-Enhanced Pruning for Attributed Interpretabl...
Taşkın Doğru (2026)	Taşkın	2026	From Hand-Crafted Features to Large Language Models: A Comparative Evaluation of Android Mal...
Tiwari et al. (2025)	Tiwari	2025	Operational DFIR: ML-Based Detection and LLM-Assisted Fileless Malware Analysis
Toda Mori (2025)	Toda	2025	CHASE: LLM Agents for Dissecting Malicious PyPI Packages
Trad Chehab (2025)	Trad	2025	Evaluating the Efficacy of Prompt-Engineered Large Multimodal Models versus Fine-Tuned Visio...
Valakuzhy et al. (2026)	Valakuzhy	2026	LUMEN: A Systems Approach to LLM-Guided Activation of Hidden Behaviors in Malware
Venu et al. (2025)	Venu	2025	Prompt-Driven Android Malware Detection Using GPT Models and Simulated Static Analysis
Vivekanandan et al. (2025)	Vivekanandan	2025	Malware and Vulnerability Analysis using Graph-synchronized Language Model
Wei et al. (2026)	Wei	2026	MASDroid: A Multi-Agent System for Enhancing the Analysis of Android Malware
Wyss et al. (2025)	Wyss	2025	Evaluating LLM-Based Detection of Malicious Package Updates in npm
Xenos et al. (2025)	Xenos	2025	MAD-Agent: A Malware Analysis and Detection AI Agent
F. Xu et al. (2025)	Xu	2025	LLM-RD: Multi-Dimensional Lightweight Ransomware Detection Using LLMs Based on Kernel-Level ...
Yoneda et al. (2025)	Yoneda	2025	Kernel-Level Malware Analysis and Behavioral Explanation Using LLMs
Zahan et al. (2025)	Zahan	2025	Leveraging Large Language Models to Detect NPM Malicious Packages
Zeng et al. (2026)	Zeng	2026	MARD: A Multi-Agent Framework for Robust Android Malware Detection
Umar Zeshan et al. (2026)	Zeshan	2026	Many hands make light work: An LLM-based multi-agent system for detecting malicious PyPI pac...
Zhang et al. (2025)	Zhang	2025	OpenEYEs: Leveraging LLM and Graph Neural Networks for Deep Ransomware Detection
W. Zhao et al. (2025)	Zhao	2025	AppPoet: Large language model based android malware detection via multi-view prompt engineering
L. Zhao et al. (2026)	Zhao	2026	LLM-SGCF: A Robust Malware Detection Framework with Spatially Guided Convolution
Zheng et al. (2025)	Zheng	2025	AV-Agent: A Bottom-Up Interpretable Malware Classifier Based on Large Language Models