Intrusion Response System Digital Assistant

• IRSDA is a unified intrusion response framework that merges detection, reasoning, and policy-based orchestration using a structured knowledge graph and agent-based architecture.
• It leverages the MAPE-K loop and self-adaptive autonomic computing to enable real-time decision-making and coordinated countermeasure deployment across distributed systems.
• The system transforms traditional IDS alerting into an active closed-loop defense mechanism, enhancing response automation, auditability, and governability.

Intrusion Response System Digital Assistant (IRSDA) denotes an intrusion-response architecture that unifies detection, reasoning, policy constraints, and response orchestration into a single operational loop. In its explicit enterprise formulation, IRSDA is an agent-based framework designed to deliver autonomous and policy-compliant cyber defense, combining Self-Adaptive Autonomic Computing Systems (SA-ACS) with the knowledge guided Monitor, Analyze, Plan, and Execute (MAPE-K) loop to support real-time, partition-aware decision-making across enterprise infrastructure (Panigrahi et al., 24 Nov 2025). The concept also sits within a broader line of IRS research in which systems move beyond alerting toward selection and initiation of response actions, closed-loop cyber defense and recovery capability, centrally coordinated host response, reinforcement-learning-based countermeasure selection, and policy-based hierarchical isolation of compromised components (Chouhan et al., 2023, Timmons et al., 8 Apr 2025, Cardellini et al., 2022, Mamun et al., 2012).

1. Conceptual scope and research lineage

An IRS differs from an IDS in that it mitigates intrusions detected by an Intrusion Detection System by selecting and initiating appropriate response actions at the right time. The literature frames this as a transition from passive notification to a decision-making system for containment, blocking, isolation, quarantine, throttling, recovery, or policy changes, motivated by IoT, edge, and high-speed attack environments in which manual response is no longer sufficient (Chouhan et al., 2023).

Within that trajectory, IRSDA addresses a specific gap in modern enterprise operations: intrusion detection is often automated, but intrusion response remains slow, manual, static, and difficult to coordinate across distributed enterprise systems. The framework was proposed for environments that are highly distributed, microservices-based, dynamic, and attacked in multi-stage ways, where classic IDS tools can detect anomalies but response is usually left to human analysts and static playbooks (Panigrahi et al., 24 Nov 2025).

Earlier work supplies important antecedents. A policy based intrusion detection and response system for hierarchical WSN architecture organized response around a four-level hierarchy and a node-class state machine spanning Fresh, Member, Unstable, Suspect, and Malicious, with automatic isolation, banning, and signature-record updates (Mamun et al., 2012). A later IRS prototype, irs-partition, treated intrusion response as adaptive countermeasure selection under non-stationarity and the curse of dimensionality, using partitioning of the protected system and Deep Q-Networks in a multi-agent formulation (Cardellini et al., 2022). Host-centric orchestration research then argued that isolated host IDS/IPS components should be turned into a centrally coordinated, adaptive intrusion response system in which a network-wide orchestrator remotely programs host logic and correlates alerts across hosts and time (Timmons et al., 8 Apr 2025).

A recurring theme across these strands is that response is not reducible to a fixed mapping from alert to action. The survey literature classifies IRSs by response purpose, response mechanism, risk assessment, response revision, response selection, response evaluation, response execution, response time, response location, and response lifetime, thereby treating intrusion response as a full lifecycle rather than a single containment step (Chouhan et al., 2023).

2. Architectural patterns and control structure

The enterprise IRSDA architecture is presented as an n-tier architecture that combines a client-server (CS) model with a multi-agent system (MAS) model. Its tiers are: Tier I: IRSDAC, the analyst-facing IRSDA Chatbot; Tier II: IRSDAS, the server for sessions, state, and request routing; Tier III: IRSDAAO, the IRS Digital Assistant Agentic Orchestration layer; Tier IV: IRSAgents, which are partition-specific agents; and Tier V: IRSKG + IRSLLM, consisting of the enterprise knowledge graph and vector-indexed knowledge base together with the cybersecurity-tuned LLM (Panigrahi et al., 24 Nov 2025).

This structure is explicitly grounded in SA-ACS and the MAPE-K loop. In operational terms, IRSDA monitors enterprise state through logs, telemetry, and partition-level data; analyzes the threat and contextual relationships; plans a compliant response based on Rules of Engagement (ROE) and system constraints; executes actions through agents; and uses the knowledge layer to supply the data and rules needed for every phase. The paper emphasizes that the framework is not just an LLM chatbot, but a control system whose reasoning is grounded in a structured enterprise knowledge base (Panigrahi et al., 24 Nov 2025).

A closely related host-based architecture adopts a different but convergent decomposition. It consists of an IDS Orchestrator, a Host IDS Agent, and an IDS Module Deployment / Module Library. The orchestrator maintains a secure communications channel to hosts, collects alerts in real time, decides whether a next-tier IDS module is required, and remotely sends either pre-built modules or Just-in-Time (JIT) dynamically generated modules to selected hosts. The host agent is composed of remotely installed IDS modules that inspect application processes and layers of the protocol stack, and some modules can also act autonomously on the host before reporting back (Timmons et al., 8 Apr 2025).

The modified Layer 4.5 orchestration substrate provides a useful structural analogy for IRSDA-like systems. It preserves the original Monitor, Construct, and Deploy functions, but adds an Alert Processor and an Alert DB, making the control plane explicitly responsible for alert handling, correlation, and adaptive deployment logic (Timmons et al., 8 Apr 2025).

3. Knowledge representation and decision mechanisms

The enterprise system in IRSDA is formalized as a graph

$G = (V, E) \mid E_{i,j} \in E,\; V_i \in V$

with vertices and edges represented as

$V_i = \{L(V_i), P(V_i)\}$

and

$E_{i,j} = \{L(E_{i,j}), P(E_{i,j})\}.$

IRSKG stores components, hosts, services, rules, logs, and their relationships, including communication, dependency, and policy constraints. Enterprise partitioning is represented as

$M = \{C_1, C_2, \dots, C_n\},$

and ROE are themselves encoded as graph objects: $$R = \{R_i \ \forall \ 0 < i < n\}, \qquad R_i = \{V_a(R_i), E(R_i), V_b(R_i)\}.$$ The paper also gives a GNN-ready transformation via

$P_{count}(V_i) = deg(V_i)$

and

$$P_{count}(E_{i,j}) = P_{count}(V_i) + P_{count}(V_j),$$

indicating that the graph is intended not only for retrieval but also for computational models such as GNNs (Panigrahi et al., 24 Nov 2025).

Knowledge-guided reasoning in IRSDA is mediated through Graph Retrieval Augmented Generation (GRAG). For a query $Q_i$, the system retrieves relevant chunks from IRSKG using vector search, inserts the evidence into a prompt template $T_i$, sends the prompt to IRSLLM, and receives a grounded response $A_i$. Summarization applies the same process to the preliminary answer and additional retrieved context, producing $V_i = \{L(V_i), P(V_i)\}$0. IRSLLM is based on a cybersecurity-oriented model adaptation approach and is further fine-tuned on curated IRSKG corpora using LoRA, while prompt whitelisting, retrieval augmentation, and explicit task restriction are used to reduce hallucination and injection risk (Panigrahi et al., 24 Nov 2025).

A different decision paradigm appears in irs-partition, where the protected system is partitioned by component type: $V_i = \{L(V_i), P(V_i)\}$1 State is built from boolean state variables $V_i = \{L(V_i), P(V_i)\}$2, actions are defined per component type as $V_i = \{L(V_i), P(V_i)\}$3, and the reward function is based on action execution time and cost, including a $V_i = \{L(V_i), P(V_i)\}$4 penalty when an action cannot be executed because the precondition is not met. Termination is partition-specific, with the system secure only when all partitions are secure: $V_i = \{L(V_i), P(V_i)\}$5 Each partition has its own DNN/DQN and agent, making countermeasure selection tractable under a multi-agent formulation (Cardellini et al., 2022).

At the survey level, these mechanisms map onto two major IRS families: knowledge-driven approaches and data-driven approaches. The literature explicitly includes rule-based, association-based, attack-graph, service-dependency, Bayesian, fuzzy, game-theoretic, and reinforcement-learning-based response selection, together with static, dynamic, cost-sensitive, and hybrid selection strategies (Chouhan et al., 2023). This suggests that IRSDA is best understood as an architectural category rather than a single algorithm.

4. Operational workflow and response semantics

IRSDA’s query-driven operational path begins when a user submits a query $V_i = \{L(V_i), P(V_i)\}$6 through IRSDAC. IRSDAS forwards it to IRSDAAO; the agentic brain delegates work to partition-specific agents; the agents retrieve data from IRSKG; they instantiate prompts $V_i = \{L(V_i), P(V_i)\}$7 and query IRSLLM; responses are returned and summarized; and structured outputs are presented back to the analyst. The framework restricts IRSLLM to two primary tasks—question answering and summarization—and relies on structured prompting and summarization passes rather than a single unstructured generation pass (Panigrahi et al., 24 Nov 2025).

In the host-orchestration lineage, workflow is framed as multi-fidelity flow interrogation and network-wide event correlation. A host-level IDS module observes local activity and generates an alert; the alert is transmitted to the IDS orchestrator; the orchestrator stores the alert condition in its alert database; it determines whether the alert should trigger a next-tier IDS module; it chooses the relevant hosts; it decides whether the module is pre-built or requires JIT construction; if needed it collects relevant information from the alert database; it builds the new module; and it deploys the module network-wide or to a relevant subset of hosts. The paper’s Algorithm 1 makes explicit that response logic is remotely programmed by the orchestrator based on alert context rather than hard-coded only at the host (Timmons et al., 8 Apr 2025).

Policy-based response in hierarchical WSNs introduces a distinct stateful response semantics. A newly arrived node is Fresh; absence of misbehavior during a preselected interval yields Member status; detected misbehavior yields Unstable; repeated oscillation or long-term misbehavior yields Suspect; and continued misbehavior yields Malicious. A Suspect node is completely isolated, cannot send, receive, or forward packets, and triggers a red alert from LPA to RPA. A Malicious node is permanently banned, and its MAC address or unique ID is added to the Signature Record Database of the LPA and all higher layers. Response therefore includes monitoring, temporary isolation, packet discard, probationary reconnection, permanent ban, signature/database update, and policy dissemination (Mamun et al., 2012).

A further operational refinement appears in Agentra, which converts alert evidence from IDS, EDR, and XDR into a structured incident response plan grounded in MITRE ATT&CK, MITRE D3FEND, and NIST CSF 2.0. Its pipeline builds an enriched incident context $V_i = \{L(V_i), P(V_i)\}$8, retrieves internal and external evidence under Moderator control, drafts a plan $V_i = \{L(V_i), P(V_i)\}$9, validates it through a bounded Planner--Validator loop, gates execution through an Action Catalog and a risk score

$E_{i,j} = \{L(E_{i,j}), P(E_{i,j})\}.$0

maps actions to authorization tiers

$E_{i,j} = \{L(E_{i,j}), P(E_{i,j})\}.$1

and records all decisions in an append-only audit log backed by Merkle chaining (Patel et al., 16 Jun 2026). A plausible implication is that IRSDA research is increasingly treating response orchestration as a supervisable pipeline rather than an unbounded autonomous action generator.

5. Empirical demonstrations and case studies

The enterprise IRSDA framework is evaluated on Google Online Boutique 2.0, an 11-service e-commerce application, using Neo4j as IRSKG, Graylog for collecting logs, and the AICA prototype as part of the agent framework context. The case study introduces a hypothetical breach in which the frontend service is compromised and attempts to send unsolicited email through the email service. The reported demonstration is qualitative rather than benchmark-heavy: IRSDA can identify the compromised frontend service, enforce the ROE that blocks communication from frontend to email service, return traceable outputs that reference the underlying rule and evidence, and provide analyst-facing explanations (Panigrahi et al., 24 Nov 2025).

The host-based orchestration prototype uses a small enterprise testbed consisting of Two Windows 11 laptops, each running Ubuntu 20.04 Layer 4.5-enabled VMs, kernel version 5.13, Intel Core i7, 16 GB RAM, SSD storage, and a TL-SG108E switch with 1 Gbps Ethernet. In the DNS flood scenario, each host begins with a module that monitors DNS query frequency using a threshold of 10 requests per second, and the orchestrator responds by deploying a throttling module that limits DNS queries to 5 requests per second on all hosts in the network. With JIT modules, the full detect-notify-construct-deploy-throttle process takes more than 30 seconds overall; with pre-built modules, mitigation completes in less than 10 seconds. In the malicious root process / malicious URL connection scenario, the system blocks the initial connection and then deploys increasingly refined response modules through an orchestrator feedback loop (Timmons et al., 8 Apr 2025).

The irs-partition evaluation also uses Google Online Boutique (OB) 2.0, but reports results for a 2-partition subsystem on a CloudLab c220g2 machine. The model uses 16 state variables, an initially heavily compromised state, and cumulative reward over training time as the primary metric, benchmarked against Value Iteration via VIMain and PartitionVIMain. Reported convergence times are about 173 seconds for the frontend-service partition and about 220 seconds for the whole system, supporting the claim that partitioning reduces training time and makes convergence easier (Cardellini et al., 2022).

Agentra provides the most quantitative evaluation among the IRSDA-adjacent frameworks. On a 120-event corpus drawn from ThreatHunter-Playbook, Splunk BOTS v3, and DARPA OpTC, with 58 malicious events and 62 benign or false-positive stress events, the static OASIS CACAO v2.0 baseline achieves recall 0.55, FP-aware IRS $E_{i,j} = \{L(E_{i,j}), P(E_{i,j})\}.$2 0.61, false-positive rate on stress cases 0.50, and harmful-action rate 0.0\%. The strongest configuration improves FP-aware IRS $E_{i,j} = \{L(E_{i,j}), P(E_{i,j})\}.$3 from 0.61 to 0.84, with precision 0.79, recall 0.90, D3FEND coverage/precision 0.84/0.84, false-positive stress rate 0.47, and harmful-action rate 0.0\%. The paper identifies A3, where Moderator plus CTI grounding is added, as the consistent safety/quality inflection point (Patel et al., 16 Jun 2026).

6. Limitations, misconceptions, and open directions

A central misconception is to treat IRSDA as merely a conversational interface layered over security data. The enterprise paper explicitly rejects that reading: IRSDA is not just an LLM chatbot, but a control system grounded in a structured enterprise knowledge base, with ROE encoded as graph objects and partition-aware agents supporting controlled local action (Panigrahi et al., 24 Nov 2025).

A second misconception is to equate IRSDA with unrestricted autonomous execution. Agentra is explicit that the Planner does not execute, Validators do not execute, the Moderator does not execute, and the analyst is the final approver before execution. Additional supervisory controls include bounded revision count, approval threshold, state-change revalidation, action catalog membership checks, sanity checks, risk-tier authorization, and escalation when approval fails (Patel et al., 16 Jun 2026).

Technical limitations remain substantial. In the host-orchestration prototype, Layer 4.5 inspects data only in TCP/UDP socket buffers, does not monitor the entire network stack, does not detect attacks using RAW sockets, depends on a secure control channel to every host agent, and assumes hosts can be dynamically reprogrammed without rebooting. JIT module construction also introduces substantial delay, and the implementation was intentionally not optimized for speed (Timmons et al., 8 Apr 2025).

The reinforcement-learning line carries strong modeling assumptions. In irs-partition, partitions are assumed to be disjoint and non-interacting, and the claim that local optimality yields a global optimum depends on that independence condition. The prototype currently implements only DQN, evaluates only a 2-partition subsystem rather than the full 11-service deployment, and treats non-stationarity primarily through transfer learning rather than a detailed continual-adaptation algorithm (Cardellini et al., 2022).

The hierarchical WSN proposal illustrates an older but still relevant limitation profile: no simulator or real-world evaluation results, no quantitative performance metrics, no explicit secure communication design between hierarchy layers, and further work needed to define detection and response policies comprehensively (Mamun et al., 2012).

At the field level, the survey literature identifies unresolved requirements that map directly onto IRSDA design: incident authentication, incident de-duplication, incident prioritization, response prioritization, response impact analysis, recovery, incident-response storage, remote management, human-in-the-loop governance, and standardization aligned with NIST, ENISA, CIS, and ISO/IEC 27035 (Chouhan et al., 2023). This suggests that the mature form of IRSDA is not a single autonomous agent, but a standardized, auditable, adaptive, and governable intrusion-response capability spanning preparation, detection and analysis, containment, eradication, recovery, and post-incident learning.