Stop Playing Whack-a-Mole with Hackers: A 23% Faster Path to Recovery

The Problem You Recognize

Your systems get hit. Alerts flood in. Your team scrambles to understand what’s happening while the attacker moves deeper. You’re reacting, not responding. The average company takes over 100 days to fully recover from a cyberattack. Every minute costs money and trust. You need a faster, smarter way to fight back.

What Researchers Discovered

Researchers at KTH Royal Institute of Technology built something different: an AI agent that handles the entire incident response cycle. It reads logs, figures out the attack, plans a fix, and acts—all by itself. You can read their paper here: In-Context Autonomous Network Incident Response: An End-to-End Large Language Model Agent Approach.

Think of it like training a single, versatile paramedic instead of hiring a different specialist for every injury. This paramedic can assess the scene, diagnose the problem, and apply the right treatment—fast.

Here’s what makes it work:

1. It thinks before it acts. The AI doesn’t just guess. It simulates different response actions in its “head” first. It asks: “If I isolate this server, what happens? If I block this port, does it break something else?” Only then does it choose the best move. If reality doesn’t match its prediction, it re-evaluates immediately.

2. It knows exactly where you are in the recovery process. The AI tracks six key stages (like “attack contained” or “evidence preserved”) with over 99% accuracy. It’s like a project manager with a perfect Gantt chart. It knows which milestones are done and what’s blocking progress, so every action is precise.

3. It’s specialized and efficient. This isn’t a giant, expensive model like GPT-5.2. It’s a smaller, cheaper model fine-tuned for one job: security. In tests, it achieved recovery times up to 23% faster than those leading general-purpose models. You get better performance without needing supercomputers.

How to Apply This Today

You don’t need to wait for a commercial product. You can start building this capability into your security operations now. Here are five concrete steps.

Step 1: Map Your Recovery States

Before any AI can help, you need clarity. Define what “recovery” means for your systems. Create a checklist of 5-7 clear, measurable states. For example:

1. Attack Detected – We know something is wrong.
2. Scope Defined – We know which systems are affected.
3. Containment Active – The attack is stopped from spreading.
4. Threat Eradicated – Malware is removed, backdoors closed.
5. Systems Restored – Clean services are back online.
6. Evidence Secured – Logs and artifacts are preserved for analysis.

Action: Run a tabletop exercise this week. Present a simple attack scenario (e.g., ransomware on a file server) and have your team document each step they take. Turn those steps into your official recovery state definitions. This becomes your AI’s “Gantt chart.”

Step 2: Build Your “Flight Simulator” with Historical Data

The AI needs to practice. You don’t need a custom-built, multi-million-dollar simulation. Use what you already have: historical incident logs.

Action: Gather logs from 3-5 past security incidents. Anonymize any sensitive data. For each incident, create a simple “playbook” document that answers:

• What were the initial alerts?
• What actions did analysts take (and in what order)?
• What was the final outcome?

This log-playbook pairing is your training data. It teaches the AI the link between signals in your environment and effective human responses.

Step 3: Fine-Tune a Foundational Model for Your Environment

Don’t build an AI from scratch. Start with an efficient, open-source foundational model. The researchers used models like DeepSeek. Fine-tune it specifically for your security data using a cost-effective method like LoRA (Low-Rank Adaptation).

Action:

1. Choose a target model (e.g., a smaller variant of Llama 3 or DeepSeek).
2. Use your prepared historical data (Step 2).
3. Work with your data science team or a consultant to apply LoRA fine-tuning. This adapts the model to understand your logs and your recovery states without retraining the entire massive model—it’s faster and cheaper.

The goal is a “security co-pilot” model that understands your environment’s language.

Step 4: Implement the “Think-Before-Act” Loop

This is the core logic. Program your agent to follow this sequence for every significant alert:

1. Analyze: Ingest the relevant logs and context.
2. Hypothesize: Determine the current recovery state (e.g., “Attack Detected”).
3. Simulate: Internally propose 2-3 potential response actions. For each, predict the next recovery state (e.g., “If I isolate Server-A, the state should move to ‘Containment Active’”).
4. Act & Verify: Execute the top-ranked action. Monitor the logs to see if the predicted state change occurs.
5. Adapt: If the state doesn’t change as predicted, loop back to Step 1 with the new data.

Action: Script this loop first for a single, common incident type (e.g., a brute-force attack on an SSH server). Use a simple automation tool like Python with an OpenAI API or StackStorm to connect the logic (analysis, simulation) to simple actions (running a script to block an IP).

Step 5: Deploy as a Human-in-the-Loop Co-Pilot

Start with augmentation, not full automation. Position the AI as a tireless junior analyst that proposes plans.

Action: Integrate the agent into your Security Operations Center (SOC) workflow. When a high-severity alert fires, have it:

1. Generate a summary: “This appears to be a ransomware deployment on FILE-SRV-02 based on logs X, Y, Z.”
2. Propose a sequenced response plan: “Recommended Action Sequence: 1. Isolate FILE-SRV-02 from network. 2. Initiate malware scan on associated workstations. 3. Deploy pre-approved patch MS-1234.”
3. Present this to a human analyst for a single-click approval.
4. Upon approval, execute the first step, then report back for verification before proceeding.

This builds trust and gives you a control mechanism.

What to Watch Out For

This approach is powerful, but be realistic about its limits.

• It’s Not a Zero-Day Shield. The system was tested on historical log data. Its performance against a completely novel, never-before-seen attack is unproven. It’s a brilliant responder to known attack patterns, not an omniscient predictor.
• External Model Dependency. The research prototype sometimes asks a larger, external AI (like GPT-5.2) for help when it’s confused. This creates a cost and latency dependency. Plan your architecture so this is a fallback, not the primary path.
• Integration Complexity. The study didn’t solve real-time integration with all threat intelligence feeds or coordinating responses across vastly different systems (cloud, IoT, OT). Start with a contained, critical system (like your Active Directory servers) to prove the concept.

Your Next Move

Start by mapping your recovery states. This single exercise will expose gaps in your own response playbooks and create the foundational framework any AI—or human—needs to act coherently.

This week, gather your incident response lead and a senior engineer. Whiteboard the six states from detection to recovery for your most critical asset. You’ll likely find your team doesn’t agree on what “containment” looks like. Fixing that human process is the first and most valuable step toward intelligent automation.

What’s the one attack scenario that keeps your team up at night? How would you define “success” at each stage of stopping it?