Building a Security Investigation Agent: Tools, SIEM Correlation and Memory

A security investigation agent is only as good as the evidence it can reach. The TryHackMe room on agent building, rated medium difficulty, shows this by assembling a SOC assistant for a fictional retailer called NorthStar Fashion, one capability at a time. The room is at tryhackme.com/room/agentbuilding, and everything below is meant for learning and defensive practice.

The problem the agent solves

An analyst facing an alert has to gather facts from many places. The alert says one thing, the SIEM holds related logs, an IP address may have a bad reputation elsewhere, and company documents explain what normal looks like. Stitching that together by hand is slow, and it gets repeated for every alert.

The agent in this room does the legwork. It starts from a security alert, pulls the relevant evidence, searches related SIEM logs and checks outside context such as IP reputation. It then reads internal organizational information and merges everything into a supported verdict that an engineer reviews. The decision itself stays with the human.

What you learn

By the end of the room you can:

• build an investigation agent from a written design
• connect tools that fetch alerts and query SIEM logs
• tie evidence together by account, IP address, device, event type and time
• bring outside and internal context into a case
• use conversation memory so follow-up questions don't restart the investigation
• produce verdicts backed by evidence while the analyst keeps the final call

The lab setup

The environment gives you access to an AI model through TryHackMe's own AI service. A helper module, thm_ai.py, already sits in the project. It handles communication with the service and uses the temporary token issued to the lab. You never manage the model provider, credentials or tokens yourself. The module is the single interface between your investigation code and the model, so the agent's logic stays separate from the infrastructure behind it.

How the agent grows

Each task adds one capability, and by the end the agent can combine model reasoning with approved actions, SIEM alerts, log correlation, IP reputation, organizational context and conversation history. The progression across the room looks like this:

Task 3 → Define the agent behaviour and connect to the AI
Task 4 → Execute approved alert capabilities
Task 5 → Correlate alerts with SIEM logs
Task 6 → Add external and organisation context
Task 7 → Continue investigations across follow-up questions

A few details from the build are worth remembering.

Connecting to the model. The agent's instructions and behavior come first, followed by a method that sends a message to the AI service. The reply includes a field holding the generated assistant text, which your code reads and passes along.

Approved alert capabilities. Tools let the agent list alerts and fetch one complete alert by its ID. Listing supports paging, so a query parameter controls how many alerts are skipped. At this early stage the agent can't retrieve an alert such as ALT-051 from the SIEM, because log search hasn't been added yet.

Correlating logs. The SIEM search endpoint takes a POST request. Conditions can be combined with logical operators, and AND requires both conditions to match the same log entry. The exercise shows how narrowing works. Searching on a single user's account returns many logs. Adding the source IP cuts the set down, and adding the device cuts it down again. Each extra condition turns a noisy list into a tight, defensible story.

External and organizational context. Two further capabilities give the agent a wider view. check_ip_abuse looks up an address for previously reported abusive activity. search_org_details searches NorthStar Fashion's internal documents, so the agent knows what's expected for that company.

Memory. The last addition is conversation history, which the TryHackMe AI service stores and which the code can retrieve with a dedicated method. Because the service keeps that history, the agent doesn't need a separate LangGraph checkpointer to remember a conversation. An analyst can ask a follow-up question without repeating the entire investigation.

The finished agent lives in one file, built up step by step throughout the room.

Why this design works

Several choices make the agent trustworthy and not merely impressive:

• It uses only approved capabilities. The model can't act outside the tools you wired in.
• Verdicts rest on evidence that can be traced back to specific logs, accounts, IP addresses, devices and timestamps.
• Outside reputation data and internal documents add context that logs alone lack.
• Memory keeps an investigation continuous, which matters when analysis takes more than one question.
• A person stays responsible for the final security decision.

That mix of tools, context, memory and human review is a sensible blueprint for any SOC automation project, whether it's practiced in a lab or built for production.