STAIR: Effective Incident Response Using an End-to-End Agentic Planning Framework

STAIR: Effective Incident Response Using an End-to-End Agentic Planning Framework

Abstract Summary:

Incident response planning is critical for restoring compromised software systems after cyberattacks. Common practice relies on expert-driven playbooks that encode fixed response procedures, but these static workflows struggle to adapt to evolving incident states, changing recovery objectives, and execution feedback. Recent LLM-based planners and tool-using agents improve automation, yet they remain unstable in long-horizon response because they lack a unified basis for maintaining incident state, aligning actions with the current recovery stage, and reusing historical experience. The paper presents STAIR, an end-to-end agentic planning framework for incident response. The framework maintains the current incident as Graph-as-State, uses a Stage Router to dispatch planning to stage-specialized agents, and retrieves historical experiences to guide action selection. An Execution Harness executes actions, returns feedback to update the incident state, and validates action effects for future experience reuse. Across 100 Docker-based cyber ranges, the framework achieves a normalized defense score of 0.94 and improves over the strongest baseline by 9.5%.

Introduction Summary:

Incident response is a software-intensive operational workflow for handling confirmed or suspected intrusions in modern production environments. It aims to investigate the incident, contain the threat, preserve evidence, remove attacker footholds, harden vulnerable entry points, and restore affected services. Incident response planning is the decision layer that determines which response action should be executed next according to current incident progress. Effective planning requires both the current incident state and historical response experience. Existing methods struggle to maintain stable decisions over long-horizon response chains, with only an average defense score of 0.59 on complex incidents in evaluation. The root cause is the lack of a workflow-level decision substrate that connects the evolving incident state, the current response stage, execution feedback, and validated historical action effects throughout the response loop. The key insight is that response planning should be grounded in a shared evolving incident state, organized by the current recovery stage, and guided by validated historical response experience. The framework addresses three challenges: maintaining a unified incident state (Graph-as-State), validating historical actions for experience reuse (Execution Harness with incident-specific profiles), and aligning planning with the current recovery stage (Stage-Specialized Agent Planner with Stage Router). The prototype supports graph-based state management, experience retrieval, stage-specialized LLM planning, and bounded tool execution over 33 response capabilities. The framework achieves a normalized overall defense score of 0.94 and improves over the strongest baseline by 9.5%.

Background Summary:

Incident response is a multi-stage operational process for mitigating cyberattacks and restoring affected software systems. Standard guidance organizes incident handling into stages such as containment, assessment, preservation, eviction, hardening, and restoration. Incident response planning is a multi-stage decision process that must continuously adapt to evolving state. LLM agents extend language models from one-shot generation to interactive task execution, selecting actions according to task goal, context, and available tools, then adjusting later decisions based on execution feedback. Incident response shares this agentic workflow structure but operates over live software systems rather than static software artifacts. Existing methods have limitations: static playbooks encode expert experience but cannot dynamically infer the current recovery stage from incident evolution; LLM planners carry incident state as textual context without stable multi-stage recovery progress; LLM agents rely mainly on online interaction traces, making long-horizon response prone to repeated exploration and unstable objectives; RL-based planners depend heavily on reward design, potentially optimizing action executability rather than advancing multi-stage recovery. Overall, existing methods lack a unified planning basis that connects evolving incident state, current response stage, and validated historical action effects.

Overview Summary:

The common limitation of existing methods is the lack of a workflow-level decision foundation connecting evolving incident state, current response stage, and validated historical action effects. The key insight is that effective incident response planning should maintain a shared evolving incident state, use the current recovery stage to organize agent specialization, and reuse historical experience only after action effects are validated. Three key challenges are identified: (1) Incident State Construction - constructing a continuously updated incident state representation that provides a reliable foundation for stage identification and response planning; (2) Response Effect Validation - understanding action effects from real execution outcomes and constructing historical experiences associated with incident states; (3) Stage-Aware Response Planning - organizing stage-aware planning based on incident states, enabling agents to leverage stage information and historical experiences. The architecture consists of four components: Incident State Manager maintains evolving incident state as Graph-as-State; Experience Database organizes response experiences by associating executed actions with incident states, response stages, execution feedback, and evaluated recovery effects; Stage-Specialized Agent Planner performs stage-aware multi-agent response planning; Execution Harness executes generated actions and collects feedback to update incident state and experience database.

Design Summary:

Incident State Manager: Represents incident state Gt at response step t as an attributed graph Gt = (Vt, Et, At), where Vt denotes response-relevant entities, Et denotes behavioral relations, and At stores node- and edge-level attributes. GAS models three categories of entities: machine nodes, artifact nodes, and defender nodes. Edges describe behavioral relations including attack behaviors (Et,atk) and response actions (Et,rsp). The State Manager initializes GAS from initial SOC alerts by extracting entities, behavioral relations, and metadata, then updates GAS through incremental state merging after each response action, performing entity and behavior alignment to maintain state consistency.

Experience Database: Transforms historical response processes into structured experience records defined as xi = (Gi, ai, yi, fi), where Gi is the incident state before the action, ai is the executed response action, yi is the action-effect label, and fi is the execution feedback. Effect labeling uses incident-specific evaluation profiles that specify recovery objectives, validation conditions, and side-effect constraints. The database retains effective and high-risk actions while excluding ineffective ones, aggregating records with similar incident states, target objects, and action types. During planning, it retrieves stage-compatible records ranked by similarity with current GAS, partitioned into positive experience set Et+ and negative experience set Et−.

Stage-Specialized Agent Planner: Uses recovery stage as both dispatch signal and planning scope. The Stage Router defines recovery stage space S = CONTAINMENT, ASSESSMENT, PRESERVATION, EVICTION, HARDENING, RESTORATION and infers zt = (st, ρt) where st is the recovery stage and ρt is the concrete recovery focus. Stage-specialized agents A = Aσ σ ∈ S each plan under their stage with stage-scoped context including shared GAS, recovery focus, stage working memory Mtσ, retrieved experiences (Et+, Et−), stage experience skill Kσ, and tool subset Cσ. Each agent outputs structured response action at = (Tt, Pt, Rt) where Tt is the selected tool, Pt is the argument set, and Rt records rationale.

Execution Harness: Receives generated action at, validates it against tool schema, grounds it into concrete security tool or response script, executes it, and returns execution feedback including execution status, outputs, and environment observations. It produces two downstream updates: for GAS, the executed action is written as a new response-action edge with feedback recorded in attributes; for Experience Database, it evaluates post-action environment according to incident-specific profile, obtains recovery effect label, and combines pre-action state, action, effect label, and feedback into candidate experience record.

Implementation Summary:

The main pipeline is implemented in Python 3.12.12 with about 21.03 KLOC of code. GAS is implemented as a graph-state runtime maintaining node, edge, and attribute records, serialized into compact stage-scoped context for planning. The Experience Database stores persistent records with pre-action incident state, response stage, executed action, effect label, and feedback summary, built offline from labeled historical response trajectories. Retrieval filters by stage and ranks by state similarity using vector index built from NumPy.npy vectors generated by stella en 1.5B v5 with cosine similarity. The Stage-Specialized Agent Planner uses deepseek-v4-pro as default LLM backend, implementing Stage Router, six stage agents, stage working memories, experience skills, and stage tool subsets. The Execution Harness exposes 33 bounded response capabilities covering log/artifact collection, host/service inspection, network/firewall control, cleanup, and service restart, executing in Docker 24.0.7 and containerlab 0.74.3 cyber ranges.

Evaluation Summary:

RQ1 (End-to-End Effectiveness): The framework achieves best overall response quality with ODS of 0.9409, improving over strongest baseline CC-DeepSeek V4 Pro (0.8589) by 9.5% relative. Recovery improves from 0.7835 to 0.8834 (12.8% relative gain). It achieves perfect AttackSup, ReattackBlk, and SCS, and reduces ReplayObjSucc to 0. LLM Planner performs worse because textual plans are not grounded in runtime feedback or state updates, while SecLoop favors executable and low-risk assessment-like actions that do not advance later recovery stages.

RQ2 (Robustness under Incident Complexity): The framework degrades least as complexity increases. From Low to High complexity tiers, ODS drops by only 6.1%, compared with 8.8% for CC-DeepSeek V4 Pro, 20.2% for CC-Opus 4.7, and 33.4% for LLM Planner. It maintains AttackSup of 1.0000 across all tiers, while baselines drop to 0.833 and 0.667 in High-complexity cases. Complex incidents require more than longer tool interaction; GAS preserves affected entities, attack behaviors, response actions, and unresolved conditions, while Stage-Specialized Agent Planner keeps action generation aligned with current recovery stage.

RQ3 (Component Attribution): Cumulative ablations show clear degradation as components are removed. Full achieves 0.9409 ODS and 0.8834 Recovery; w/o E drops to 0.8250 ODS and 0.7926 Recovery; w/o E+G further drops to 0.6889 ODS and 0.6326 Recovery; w/o E+G+P reaches only 0.6031 ODS and 0.5348 Recovery. Removing Experience Database reduces SCS from 1.0000 to 0.7000 and raises CDR from 0 to 0.3000. Removing GAS reduces AttackSup from 1.0000 to 0.5333 and ReattackBlk to 0.7333. Removing Stage-Specialized Agent Planner further degrades response quality. The results show GAS, Experience Database, and Stage-Specialized Agent Planner are complementary components for safe and durable response.

RQ4 (Experience Reuse): Removing Experience Database reduces ODS from 0.9409 to 0.8250 and Recovery from 0.8834 to 0.7926. ReattackBlk and AttackSup both drop from 1.0000 to 0.9333, ReplayObjSucc increases from 0 to 0.0667, SCS drops from 1.0000 to 0.7000, and CDR rises from 0 to 0.3000. Experience reuse brings a 14.7% ODS gain on seen-family variants and an 8.2% gain on previously unseen families, indicating the database transfers response patterns through similar incident states, recovery stages, and validated action effects rather than replaying training trajectories.

Discussion Summary:

The main implication is that agentic incident response requires more than giving LLMs access to tools; without explicit incident state and recovery-stage control, long-horizon response can degenerate into local exploration. The framework shifts agentic response from open-ended tool interaction to a stateful workflow organized around recovery progress. For controllability in real deployment, the framework constrains agents to structured actions, stage-scoped tool subsets, and bounded execution, storing high-risk historical actions as retrievable risk constraints. The framework is most useful for long-horizon, multi-stage incidents where incident state evolves and historical experience is transferable; for low-risk stable one-step tasks, static playbooks may remain simpler. Future work should improve cross-environment state alignment, experience-retrieval generalization, recovery-stage robustness, and approval mechanisms for SOC workflows.

Conclusion Summary:

The paper presents an end-to-end agentic planning framework for incident response, modeling incident response planning as a stateful, stage-specialized, and experience-supported workflow automation problem. It maintains the current incident as GAS, retrieves effect-validated response experience, dispatches planning to stage-specialized agents, and uses the Execution Harness to feed execution results back into the response loop. Evaluation on 100 closed-loop cyber ranges shows that the proposed workflow improves end-to-end response quality over representative planning, reward-driven, and agentic baselines.

Improvements to AI Systems Based on STAIR:

1. Graph-Based State Memory for Long-Horizon Tasks

• Implement a persistent, attributed graph (Graph-as-State) that tracks entities, relations, and attributes across multi-step tasks.

• The improved AI system can maintain coherent task state over long sequences, avoiding context loss or drift that plagues text-only memory, and can update state incrementally after each action.

2. Stage-Aware Planning with Specialized Sub-Agents

• Add a Stage Router that infers the current phase of a multi-stage task and dispatches planning to specialized agents, each with stage-specific tools, memory, and retrieval scope.

• The improved AI system can align its actions with the correct recovery/execution stage, reducing irrelevant actions and improving goal progression in workflows like incident response, software repair, or multi-phase operations.

3. Effect-Validated Experience Reuse

• Build an Experience Database that stores (pre-state, action, effect-label, feedback) records, validated by post-action evaluation, and retrieve them by stage and state similarity.

• The improved AI system can reuse proven action patterns from similar past states, avoiding repeated exploration, and can learn from both positive and negative examples to improve decision quality and avoid high-risk actions.

4. Execution Harness with Feedback-Driven State Update

• Integrate an execution layer that validates actions against schemas, executes them in a bounded environment, and feeds back execution status and environment observations into the state graph and experience database.

• The improved AI system can ground its decisions in real execution results, correct its state representation after each action, and continuously refine its experience base—enabling closed-loop adaptation rather than static planning.

5. Stage-Scoped Tool Subsetting and Action Structuring

• Constrain each stage agent to a relevant subset of tools and require structured action outputs (tool, arguments, rationale).

• The improved AI system can operate safely in production-like environments by limiting action scope per stage, reducing unintended side effects, and improving action executability and traceability.

6. Robustness to Task Complexity

• Use state graph preservation and stage-specialized planning to maintain performance as task complexity increases (e.g., more entities, longer chains).

• The improved AI system can handle high-complexity, multi-stage tasks with minimal performance degradation, maintaining high success rates where baseline LLM agents fail.

7. Controllable and Safe Exploration

• Store high-risk actions as retrievable constraints and enforce bounded execution with schema validation.

• The improved AI system can avoid dangerous or irreversible actions, reduce collateral damage, and support human-in-the-loop approval mechanisms for critical steps.

8. Transferable Experience Across Task Variants

• Retrieve experiences based on state similarity and stage compatibility, not just exact matches.

• The improved AI system can transfer learned response patterns to unseen but similar task families, improving generalization without overfitting to training trajectories.

9. Unified Workflow-Level Decision Substrate

• Combine state graph, stage router, experience database, and execution harness into a single decision loop.

• The improved AI system can make decisions that are simultaneously grounded in current state, aligned with the current phase, informed by validated history, and corrected by execution feedback—overcoming the fragmentation of existing LLM agents, static playbooks, and RL planners.

10. Quantifiable Performance Gains in Operational Tasks

• Achieve higher end-to-end success (e.g., normalized defense score 0.94 vs. 0.86 baseline), better recovery rates, zero re-attack success, and zero collateral damage in cyber incident response.

• The improved AI system can deliver measurable improvements in real-world operational workflows, not just benchmark tasks, making it suitable for deployment in security operations centers and similar high-stakes environments.