SIRT Triage Agent Workshop
← All lessons

Lesson 9

~15 min

A first investigate step with Workers AI

Hook a Workers AI call into the Investigate button so clicking it produces a structured analysis that streams into the UI.

Steps0 / 4
~15 min

  1. Review the investigate handler in server.ts

    Open `src/server.ts` and find the `/api/investigate/:incidentId` route. Read how it constructs the prompt from incident data.

  2. Click Investigate on the Malware + C2 incident

    Open INC-2026-0042 in your app and click Investigate. You should see a structured analysis appear within a few seconds.

  3. Read the system prompt that drives the analysis

    In `src/server.ts`, find the system message. It tells the model to analyze the incident and return a structured assessment.

  4. Investigate a second incident to see different analysis

    Go back to the queue and investigate the Phishing incident (INC-2026-0043). The analysis should be different because the incident data is different.

How the investigate handler works

In lesson 08, you clicked “Investigate” and saw an analysis appear. Now let’s understand exactly how that works by reading the code.

Open sirt-workshop-app/src/server.ts and find the /api/investigate/:incidentId route handler. The flow is:

  1. Load the incident from D1 — The handler takes the incidentId from the URL, queries env.INCIDENTS_DB for that incident’s row, and extracts the telemetry data.
  2. Construct the prompt — The incident’s fields (title, type, severity, telemetry JSON) are formatted into a user message. A system message tells the model what kind of analysis to produce.
  3. Call Workers AI — The handler calls env.AI.run() with the model name and the constructed messages.
  4. Return the result — The model’s response is sent back to the browser, where it renders in the triage panel.

Investigation request flow

sequenceDiagram
  participant Browser
  participant Worker
  participant D1
  participant Workers AI

  Browser->>Worker: POST /investigate/:id
  Worker->>D1: Load incident
  D1-->>Worker: Incident data
  Worker->>Workers AI: System prompt + incident
  Workers AI-->>Worker: Analysis
  Worker-->>Browser: Stream result

The prompt template

The system prompt is what makes this a security analysis tool rather than a generic chatbot. Here’s the structure:

System: You are an expert security analyst performing incident triage.
Analyze the following incident and provide:
- What happened (one concise paragraph)
- Risk assessment (P0–P3 severity with rationale)
- Key indicators to investigate further
- Recommended immediate actions

Be specific. Reference actual values from the incident data.
Do not hedge or give generic advice.

User: [incident data as JSON]

The system message defines the role, the output structure, and the quality expectations. The user message provides the context — the actual incident data that varies per call.

This pattern — fixed system prompt + variable user context — is the foundation of every AI call in this workshop. The prompt is what turns a general-purpose LLM into a specialized security analyst.

Step 1: Review the handler code

Open sirt-workshop-app/src/server.ts in your editor. Find the route that handles POST /api/investigate/:incidentId. Read through the code and identify:

  • Where the incident is loaded from D1
  • How the telemetry data is extracted and formatted
  • The system message content
  • The env.AI.run() call with the model name

Understanding this handler is important because every subsequent lesson builds on this pattern. The prompt will get more specialized, and the single call will be replaced by multiple parallel calls — but the fundamental shape stays the same.

Step 2: Test the investigate flow

Open your deployed app and navigate to the incident queue. Click on INC-2026-0042 (Malware + C2 Beacon) to open the detail view, then click “Investigate.”

Within a few seconds, you should see a structured analysis appear. The model is examining the incident’s telemetry — the encoded PowerShell command, the C2 IP address, the process execution chain — and producing an assessment.

Look at the output and verify it covers:

  • What happened — The model should describe the PowerShell execution and C2 communication.
  • Risk assessment — Should be P1 or P0 given the active C2 beacon.
  • Key indicators — Should list the C2 IP, the encoded command, and any LOLBin usage.
  • Recommended actions — Should include endpoint isolation and network blocking.

Step 3: Read the system prompt carefully

Go back to src/server.ts and re-read the system message in the investigate handler. Notice how specific it is: it doesn’t just say “analyze this incident” — it specifies the exact output dimensions and quality standards.

This matters because the model will do exactly what you tell it. A vague prompt produces vague output. A structured prompt with specific expectations produces structured, actionable output.

Key prompt engineering principles at work here:

  • Role definition — “You are an expert security analyst” sets the expertise level
  • Output specification — The four bullet points define exactly what to return
  • Quality constraints — “Be specific” and “do not hedge” prevent generic filler
  • Context grounding — “Reference actual values from the incident data” forces the model to use the provided data, not make things up

Step 4: Investigate a second incident

Go back to the queue and investigate a different incident — click on INC-2026-0043 (Phishing + BEC).

The analysis should be meaningfully different because the incident data is different. Instead of PowerShell and C2 beacons, the model should discuss:

  • The credential harvesting URL
  • The mailbox forwarding rule
  • Business email compromise indicators
  • Account-focused remediation steps

This demonstrates that the model isn’t returning canned responses — it’s actually reading and analyzing the incident data you provide.

The pattern so far

Here’s what you’ve built through lessons 06–09:

Browser → Worker → D1 (load incident)
                 → DO (session state)
                 → Workers AI (analyze)
                 → Response to browser

Every request flows through your Worker. The Worker orchestrates multiple bindings — D1 for data, a Durable Object for state, Workers AI for inference. The next lesson introduces the Agents SDK, which gives you a structured way to orchestrate these calls as durable, stateful agent workflows.

Knowledge check