Build Your Own AI SOC Agent with Claude Tool Calling

The full technical writeup with complete Python code, tool definitions, system prompt, and a step-by-step investigation walkthrough is on the blog below:👇

https://motasem-notes.net/build-an-ai-soc-analyst-with-claude-api-python-and-your-siem/

You could also watch the video instead:

Prerequisites and Environment Setup

Install the Anthropic SDK:

pip install anthropic

Export your API key as an environment variable:

export ANTHROPIC_API_KEY="your_api_key_here"Code language: JavaScript (javascript)

You can name the environment variable whatever you want in your code as long as you reference it consistently. To get an API key, log into platform.anthropic.com, navigate to the console, go to API Keys, and create a new key. You’ll need a small credit balance ; a few dollars is sufficient to get started and will cover significant development and testing work.

SIEM access: The code I’m walking through assumes your SIEM exposes a REST API. The TryHackMe room provides a virtual SIEM environment on a local network address. If you have a production SIEM deployed, you’ll replace the VM address with your actual SIEM’s API endpoint and substitute your real API key. The code structure doesn’t change only the endpoint URLs and authentication headers.

Adapting to Your Environment

If you have a production SIEM, three changes get you to a working deployment:

Replace the SIEM endpoint:

SIEM_BASE_URL = "https://your-actual-siem.com"  # Your SIEM's API base URLCode language: PHP (php)

Replace the SIEM authentication:

headers = {
    "Authorization": f"Bearer {os.environ.get('SIEM_API_KEY')}",
    # Add any additional headers your SIEM requires
}Code language: PHP (php)

Verify your SIEM’s API endpoint paths for listing alerts, retrieving individual alerts by ID, and searching logs. The three-function structure remains the same; only the URL paths change.

The full adapted code for the Claude version of this agent is available in the video description. The TryHackMe Agent Building room remains a useful practice environment for the agent architecture concepts just note that it uses TryHackMe’s own AI model rather than Claude, so the API integration section differs from what I’ve described here.

The Agent Limits

The agent has exactly 3 approved capabilities:

→ List alerts from the SIEM

→ Retrieve alert details by ID

→ Search SIEM logs for corroborating evidence

It cannot close alerts, modify SIEM state, or trigger containment. That boundary the right design for where autonomous AI belongs in a SOC workflow right now.

What a live investigation looks like:

A "Repeated Sign-In Failures" alert fires for user David James. 12 failed attempts in 9 minutes. The agent:

1. Retrieves the alert details from the SIEM

2. Searches logs for the user account and source IP

3. Finds zero corroborating events

4. Returns verdict: INSUFFICIENT_EVIDENCE with specific recommendations on what log data would resolve it

What would have taken a Tier 1 analyst 15-20 minutes of manual SIEM browsing took under 60 seconds. The analyst's time goes to the judgment call at the end, not the data retrieval.

The Aget Architecture:

The agent is built around three Python functions that directly represent its approved capabilities, a tool definition schema that tells Claude how to call those functions, and an investigation loop that manages the conversation state and tool execution.

List Security Alerts

import requests
import json

SIEM_BASE_URL = "http://your-siem-ip:port"  # Replace with your SIEM address
SIEM_API_KEY = "your-siem-api-key"          # Replace with your SIEM API key

def list_alerts(count: int = 10, offset: int = 0) -> dict:
    """
    List security alerts from the SIEM in paginated form.
    
    Args:
        count: Maximum number of alerts to return (default 10)
        offset: Pagination offset for retrieving subsequent pages
    
    Returns:
        JSON response containing alert IDs, names, severities, and statuses
    """
    endpoint = f"{SIEM_BASE_URL}/api/alerts"
    headers = {
        "Authorization": f"Bearer {SIEM_API_KEY}",
        "Content-Type": "application/json"
    }
    params = {
        "count": count,
        "offset": offset
    }
    
    response = requests.get(endpoint, headers=headers, params=params)
    response.raise_for_status()
    return response.json()Code language: PHP (php)

The pagination design ; count and offset is deliberate. Returning all alerts in a single response wastes tokens on data the agent doesn’t need for any single investigation step. Keeping the count at 10 means the agent gets a manageable view of the alert queue, and the offset allows it to page through if it needs to see more.

Token conservation matters in an agentic loop because every turn in the conversation carries the full prior context ; cost accumulates quickly if you’re not thoughtful about response sizes.

A Live Investigation Walk-Through

Let me walk through the sequence of interactions I ran during testing, because the investigation flow itself is what demonstrates why this architecture works.

Listing the alert queue:

Analyst: list the current alerts

Agent: [calls list_alerts()]

Here are the 10 current alerts in the queue:

| ID        | Name                          | Severity | Status |
|-----------|-------------------------------|----------|--------|
| alert_004 | Repeated Sign-In Failures     | MEDIUM   | NEW    |
| alert_005 | MFA Method Added              | LOW      | NEW    |
| alert_006 | Session Revoked               | LOW      | NEW    |
| alert_007 | Suspicious Sign-In            | MEDIUM   | NEW    |
| alert_008 | Successful Home Sign-In       | LOW      | NEW    |
| alert_009 | Password Change               | MEDIUM   | NEW    |
...Code language: PHP (php)

Investigating the session revocation alert:

Analyst: investigate alert_006

Agent: [calls get_alert(alert_id="alert_006")]

VERDICT: P9_POSITIVE (Benign)

KEY_EVIDENCE:
- Event type: Session revoked (logout)
- User: Maria [account]@northstar-fashion.com  
- Action: Revoke session
- Outcome: Success
- Source device: Non-company-managed device
- No MITRE ATT&CK techniques flagged
- Provider: Google Cloud Identity
- Severity: LOW

REASONING: This is a routine successful session revocation on a non-company-managed 
device with no indicators of malicious activity, unusual location, or credential compromise.

RECOMMENDATION: No containment action required. Session expiry or user-initiated 
logout — no follow-up needed.