SIRT Triage Agent Workshop
← All lessons

Lesson 12

~15 min

Response Agent and playbook-driven action plans

Add the Response Agent that reads playbook files and produces a structured action plan with per-action risk, reversibility, and approve/reject controls.

Steps0 / 4
~15 min

  1. Review the playbook files

    Open `src/playbooks/` and read one playbook (e.g. `malware-containment.md`). Note the structured steps with risk levels and reversibility flags.

  2. Review the Response Agent code

    Open `src/agents/response-agent.ts`. Read how it matches the triage card to relevant playbooks and generates structured actions.

  3. Complete a full triage-to-action-plan flow

    Investigate the Malware incident. After the triage card appears, you should see an action plan with 4-6 structured actions including risk levels and reversibility.

  4. Investigate the Data Exfiltration incident

    The P0 incident should produce a different action plan — actions for legal hold, access revocation, and investigation preservation rather than malware containment.

Playbooks as procedural knowledge

Security teams already have runbooks — step-by-step procedures for handling specific incident types. The Response Agent encodes these procedures into a format the AI can read and follow.

Open the sirt-workshop-app/src/playbooks/ directory. You’ll find markdown files like:

  • malware-containment.md — Procedures for isolating infected endpoints and blocking C2 channels
  • phishing-response.md — Procedures for credential resets, mail rule removal, and user notification
  • unauthorized-access.md — Procedures for session revocation and access review
  • data-exfiltration-suspected.md — Procedures for legal hold, evidence preservation, and access restriction

Each playbook is structured markdown with steps that include risk levels and reversibility:

# Malware Containment

## Immediate Actions (within 15 minutes)

1. **Isolate the affected endpoint** from the network
   - Risk: low
   - Reversible: yes
   - Integration: CrowdStrike / endpoint management
   - Rationale: Prevent lateral movement while preserving forensic state

2. **Revoke active sessions** for the affected user account
   - Risk: medium (disrupts user's work)
   - Reversible: yes
   - Integration: Identity provider (Okta, Azure AD)
   - Rationale: Prevent attacker from using stolen session tokens

3. **Block C2 IP/domain** at the network perimeter
   - Risk: low
   - Reversible: yes
   - Integration: Firewall / DNS filtering
   - Rationale: Sever command-and-control communication

These aren’t just documentation — they’re structured inputs the Response Agent uses to generate incident-specific action plans. The markdown format makes them easy for security teams to write and maintain using their existing workflows.

How the Response Agent works

The Response Agent sits downstream of the triage flow. Once the Synthesizer produces a triage card with an incident_type and severity, the Response Agent:

  1. Matches the incident type to relevant playbooks — A malware_c2 incident loads malware-containment.md. A data_exfiltration incident loads data-exfiltration-suspected.md. Some incidents match multiple playbooks.
  2. Loads playbook content as context — The relevant playbook markdown is included in the system prompt alongside the triage card.
  3. Generates structured actions via Workers AI — The model reads the playbook procedures, applies them to the specific incident (using real targets, real indicators from the triage card), and outputs structured action recommendations.

The key: the model doesn’t invent procedures from scratch. It follows the playbook but adapts it to the specific incident — using real hostnames, real user accounts, and real indicators from the triage card.

Response Agent flow

flowchart LR
  A[Triage Card] --> B[Playbook Matcher]
  B -->|matches incident type
to playbook| C[Playbook + Triage Card]
  C --> D[Response Agent
— Workers AI —]
  D --> E[Structured Actions]
  E -->|risk, reversibility,
integration target| F[HITL Controls
approve / reject / escalate]

Structured action output

Each recommended action has a consistent structure that enables per-action UI controls:

{
  "actions": [
    {
      "action_id": "act-001",
      "action_type": "isolate_endpoint",
      "target": "WKSTN-JDOE-PC",
      "domain": "endpoint",
      "reversible": true,
      "risk_level": "low",
      "playbook_source": "malware-containment.md",
      "rationale": "Prevent lateral movement while investigation continues",
      "prerequisites": [],
      "integration": "CrowdStrike"
    },
    {
      "action_id": "act-002",
      "action_type": "revoke_sessions",
      "target": "jdoe@company.com",
      "domain": "identity",
      "reversible": true,
      "risk_level": "medium",
      "playbook_source": "malware-containment.md",
      "rationale": "Prevent use of potentially compromised session tokens",
      "prerequisites": ["act-001"],
      "integration": "Okta"
    },
    {
      "action_id": "act-003",
      "action_type": "block_destination",
      "target": "203.0.113.42",
      "domain": "network",
      "reversible": true,
      "risk_level": "low",
      "playbook_source": "malware-containment.md",
      "rationale": "Sever C2 communication channel",
      "prerequisites": [],
      "integration": "Cloudflare Gateway"
    }
  ]
}

Notice the structure enables the UI to render per-action controls:

  • reversible — Shows whether the action can be undone. Irreversible actions get additional confirmation.
  • risk_level — Colors the action (green/yellow/red) and determines the approval threshold.
  • prerequisites — Some actions depend on others (revoke sessions after endpoint isolation).
  • integration — Shows which tool would execute the action.
  • rationale — Explains why this action is recommended, so the analyst can make an informed decision.

Step 1: Review the playbook files

Open sirt-workshop-app/src/playbooks/ and read through at least one playbook file. Note:

  • The structured format: each step has risk, reversibility, integration target, and rationale
  • The specificity: steps reference tool categories (endpoint management, identity provider, firewall) not abstract concepts
  • The ordering: immediate actions first, then investigation steps, then longer-term remediation

These playbooks are the procedural knowledge the Response Agent draws on. Different incident types route to different playbooks, producing different action plans.

Step 2: Review the Response Agent code

Open sirt-workshop-app/src/agents/response-agent.ts and read how it:

  • Receives the triage card from the Coordinator/Synthesizer
  • Maps the incident_type field to one or more playbook files
  • Loads the playbook content and includes it in the system prompt
  • Instructs Workers AI to generate structured actions that follow the playbook but are adapted to the specific incident (using real targets from the triage card)
  • Parses the model output into the structured action format

Step 3: Test the full triage-to-action-plan flow

Open your deployed app and investigate the Malware + C2 Beacon incident:

  1. Click Investigate — the four sub-agents analyze the incident
  2. The Synthesizer produces a triage card
  3. The Response Agent activates and generates an action plan

You should see 4–6 structured actions appear below the triage card. For the malware incident, expect actions like:

  • Isolate the affected endpoint (low risk, reversible)
  • Revoke the user’s active sessions (medium risk, reversible)
  • Block the C2 IP at the network perimeter (low risk, reversible)
  • Collect forensic artifacts from the endpoint (low risk, irreversible in terms of state change)
  • Reset the user’s credentials (medium risk, reversible)

Each action should show risk level, reversibility, the playbook it came from, and the rationale.

Step 4: Try a different incident type

Go back to the queue and investigate the Data Exfiltration incident. The action plan should be substantially different because the playbook is different:

  • Initiate legal hold on the employee’s accounts and devices (medium risk, specific to exfiltration)
  • Revoke access to sensitive repositories (medium risk, reversible)
  • Preserve forensic evidence before any access changes (low risk, irreversible)
  • Block the personal cloud storage destination (low risk, reversible)
  • Notify legal/HR as required by policy (low risk, procedural)

The actions reflect the data-exfiltration-suspected.md playbook rather than the malware-containment.md playbook. Different incidents, different playbooks, different action plans — but the same structured format and the same human-in-the-loop approval requirement.

The complete pipeline

At this point, your deployed app has the full core triage-to-recommendation pipeline:

Incident Queue (D1)
    │
    ▼
Investigate (TriageAgent)
    │
    ├── Command-Line Analyzer ──┐
    ├── Identity Analyzer ──────┤
    ├── Network Analyzer ───────┤── Synthesizer ── Triage Card
    └── Activity Analyzer ──────┘
                                        │
                                        ▼
                                Response Agent
                                        │
                                        ▼
                               Action Plan (approve/reject)

The analyst clicks one button and gets: four dimensions of specialized analysis, a synthesized triage card with severity and confidence, and a concrete action plan with per-action risk assessment. Every step runs on Workers AI through the Agents SDK, with data staying on Cloudflare’s network.

What comes next

In lesson 13, you’ll add the Sandbox SDK to give the Network Analyzer the ability to run CLI enrichment commands (like dig, whois, and nslookup) in a secure sandbox — turning it from a model-only analysis into an analysis augmented with real infrastructure lookups. In lesson 14, the Response Agent gains the ability to generate and execute custom Workers using Dynamic Workers.

Knowledge check