IRSDA: An Agent-Orchestrated Framework for Enterprise Intrusion Response

TL;DR

IRSDA addresses the need for fast, policy-compliant automated intrusion response in dynamic enterprise environments. It combines the MAPE-K autonomic loop with SA-ACS, a partitioned knowledge graph, and a cybersecurity-tuned LLM to coordinate autonomous response across system boundaries. The approach grounds LLM outputs with graph-based retrieval (GRAG) to provide explainable, ROE-compliant containment demonstrated in an Online Boutique microservices case study. The work advances practical, scalable, and auditable enterprise cyber defense by integrating agentic orchestration, graph reasoning, and retrieval-grounded AI.

Abstract

Modern enterprise systems face escalating cyber threats that are increasingly dynamic, distributed, and multi-stage in nature. Traditional intrusion detection and response systems often rely on static rules and manual workflows, which limit their ability to respond with the speed and precision required in high-stakes environments. To address these challenges, we present the Intrusion Response System Digital Assistant (IRSDA), an agent-based framework designed to deliver autonomous and policy-compliant cyber defense. IRSDA combines 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. IRSDA incorporates a knowledge-driven architecture that integrates contextual information with AI-based reasoning to support system-guided intrusion response. The framework leverages retrieval mechanisms and structured representations to inform decision-making while maintaining alignment with operational policies. We assess the system using a representative real-world microservices application, demonstrating its ability to automate containment, enforce compliance, and provide traceable outputs for security analyst interpretation. This work outlines a modular and agent-driven approach to cyber defense that emphasizes explainability, system-state awareness, and operational control in intrusion response.

Figures (4)

• Figure 1: IRSDA System Architecture - an n-tier architecture following a client-server and multi-agent system design. Tier I includes the IRSDA Chatbot (IRSDAC), the user-facing interface that enables natural language interactions. Tier II is the IRSDA Server (IRSDAS), which handles client requests, manages state, and coordinates incident response. Tier III is the IRS Digital Assistant Agentic Orchestration layer (IRSDAAO), where an agentic brain orchestrates task delegation to agents. Tier IV contains IRSAgents (IRSDAA), with each agent handling a single system partition. Tier IV also includes the IRS Knowledge Graph (IRSKG) and the enterprise-tuned LLM (IRSLLM). IRSKG is a vector-indexed knowledge base of system logs, configuration data, and rules of engagement. IRSLLM is fine-tuned on both enterprise data and publicly available cybersecurity datasets. The architecture supports both knowledge extraction into IRSKG and consumption by IRSLLM and other system components.
• Figure 2: IRSDA Question-Answer Control Flow. The user initiates a query via the IRSDA Client (IRSDAC), which is routed to the IRSDA Server (IRSDAS). The query $Q_i$ is dispatched to the Incident Response System Digital Assistant Agentic Orchestration layer (IRSDAAO), where the Agentic Brain (AB) coordinates delegation to partition-specific agents ${\mathcal{C}\xspace_i}$. Each agent generates prompts ${\mathcal{T}\xspace_i}$ using predefined templates, retrieves contextual data from the IRS Knowledge Graph (IRSKG), and queries the IRSLLM for responses ${\mathcal{A}\xspace_i}$. Agents also engage IRS computational models (e.g., GAN, RL) to evaluate potential incident response actions. The aggregated outputs are returned to IRSDAAO, which forwards the structured responses to IRSDAS. IRSDAS collaborates with IRSLLM to synthesize and format a multi-tab answer set, ultimately returned to the client interface.
• Figure 3: IRSKG representation of OB system: frontend-partition$\mathcal{C}\xspace_1$ (containers) of component type $i=1$ (container images) with configuration $f_1$ having components $\mathcal{C}\xspace_{1_{1}}$ and $\mathcal{C}\xspace_{1_{2}}$
• Figure 4: IRSKG representation of an OB ROE ($\mathcal{R}\xspace_1$) prohibiting frontend-service to backend-service