Building an Autonomous AI SOC: Architecture & Infrastructure (Or: How I Learned to Stop Worrying and Trust the Confidence Score)

Eran Goldman-Malka · June 19, 2026

Security   Homelab   AI

Let’s build something the vendors won’t sell you: an AI-powered Security Operations Center that actually treats model uncertainty as a feature.

The Problem With AI in Security (and Why We’re Doing This)

Every security vendor with a marketing budget is slapping “AI-powered” on their product like it’s a magic immunity totem. The dirty secret? Most of these systems treat LLMs as glorified binary classifiers: malicious or benign, 1 or 0, buy or don’t buy our enterprise license.

This is catastrophic for detection engineering.

AI models don’t deal in certainties—they deal in probabilities. When Commercial AI or Llama tells you something is “malicious,” what it’s really saying is “based on my training data and the embeddings I computed, this looks suspicious with ~73% confidence, I’m a statistical model, not a crystal ball.”

The confidence score isn’t noise to be hidden. It’s signal to be acted upon.

This series is about building a homelab SOC that respects this reality. We’ll route high-confidence detections to automated response, medium-confidence findings to human review, and log everything with full context. No vendor lock-in, no cloud dependencies (unless you want them), and complete visibility into why the AI thinks your PowerShell script is sketchy.

The Architecture: What We’re Building

Here’s the stack:

┌─────────────────────────────────────────────────────┐
│                   Proxmox VE                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────┐  │
│  │   Wazuh      │  │     n8n      │  │  Ollama  │  │
│  │   Manager    │◄─┤   (SOAR)     │◄─┤  (LLM)   │  │
│  │              │  │              │  │          │  │
│  │  + Dashboard │  │  Playbooks   │  │ Llama 3  │  │
│  │  + API       │  │  Webhooks    │  │ Mistral  │  │
│  └──────┬───────┘  └──────────────┘  └──────────┘  │
│         │                                           │
│         ▼                                           │
│  ┌──────────────────────────────────────────────┐  │
│  │     Wazuh Agents (endpoints/VMs)             │  │
│  │     - Process monitoring                     │  │
│  │     - File integrity                         │  │
│  │     - Log collection                         │  │
│  └──────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────┘
              │
              ▼
      ┌───────────────┐
      │   Telegram    │  (Human-in-the-loop)
      │   Webhooks    │
      └───────────────┘

Component Breakdown

Proxmox VE: Our hypervisor. Type-1 virtualization, KVM-based. You can pass through GPUs, carve up resources, and snapshot VMs before you inevitably break something at 2 AM.

Wazuh: Open-source SIEM/XDR. Think “Splunk without the licensing nightmares”. It collects logs, monitors file integrity, detects anomalies, and has an API we can abuse for automated response.

n8n: The SOAR engine. This is where we’ll build the decision logic:

  • Receive alerts from Wazuh
  • Send suspicious artifacts to Ollama for AI analysis
  • Parse the LLM’s JSON response (including confidence scores)
  • Route based on thresholds: block, alert, or log

Why n8n and not Shuffle?

  • Shuffle: Great project, but the community is smaller, and the workflow UI gets clunky fast when you’re debugging complex conditional logic at midnight.
  • n8n: Self-hosted, active community, clean UI, and the workflow-as-code model doesn’t make you want to flip tables. It also has a native HTTP node and doesn’t choke on large JSON payloads.

Ollama: Local LLM inference server. We’ll run models like Llama-3 (8B) or Mistral (7B) for log/payload analysis. No API keys, no rate limits, no “your data is ours” clauses buried in Section 8.4 of the TOS.

Hardware Requirements: The “Can I Run This?” Question

Let’s be realistic about what you need.

Minimum Viable Homelab

Component Spec Why
CPU 6-core / 12-thread (Intel i7-10700 or Ryzen 5 5600X) Proxmox + 3-4 VMs will eat cores. Wazuh indexing is CPU-bound.
RAM 32GB DDR4 Wazuh manager wants 8GB, Ollama needs 16GB+ for 8B models, n8n is lightweight (~2GB), plus overhead.
Storage 500GB NVMe SSD (OS/VMs) + 1TB HDD (logs) Fast boot/IOPS for VMs. Logs can live on spinning rust.
GPU NVIDIA GTX 1070 (8GB VRAM) or better Optional but recommended. CPU inference on Llama-3 is painful.
Component Spec Why
CPU 8-core / 16-thread (Ryzen 7 5800X or i7-12700) Headroom for multiple agents, faster indexing.
RAM 64GB DDR4 Run larger models (13B), keep more VMs active, buffer for log spikes.
Storage 1TB NVMe SSD + 2TB HDD Separate Wazuh indexes, Ollama model cache, VM snapshots.
GPU NVIDIA RTX 3060 (12GB VRAM) or RTX 4060 Ti (16GB) Llama-3 8B fits comfortably. Room for quantized 13B models.

GPU Pass-Through in Proxmox: The Annoying Part

Proxmox uses KVM, which means you can pass a GPU directly to a VM for near-native performance. But NVIDIA drivers are fussy about virtualization.

Quick checklist:

  1. Enable IOMMU in BIOS (Intel VT-d or AMD-Vi)
  2. Verify IOMMU groups: 
    #!/bin/bash
shopt -s nullglob
for g in $(find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V); do
    echo "IOMMU Group ${g##*/}:"
    for d in $g/devices/*; do
        echo -e "\t$(lspci -nns ${d##*/})"
    done;
done;
  3. Add GPU to VM hardware in Proxmox web UI
  4. Install NVIDIA drivers inside the VM
  5. Pray to the PCI gods

We’ll deep-dive this in Part 3, including the workaround for NVIDIA’s “Error 43” when it detects KVM.

Why Local LLMs? (The Sovereignty Argument)

Running Ollama locally means:

  • No rate limits: You’re not fighting OpenAI’s token buckets or Claude’s “please slow down” messages when you’re analyzing a spike of 10,000 process trees.
  • No data exfiltration: Your logs stay in your lab. No third-party ToS, no subpoenas to OpenAI for “what did this customer analyze on June 12th?”
  • Cost control: After the upfront GPU purchase, inference is free. No surprise bills when you accidentally analyze a month of DNS logs.
  • Latency: Sub-second response times. No round-trip to us-east-1.

The trade-off?

  • Smaller models = less reasoning depth. A local Llama-3 8B won’t match GPT-5’s nuance.
  • You’re responsible for model updates, fine-tuning, and the occasional “why is this hallucinating about APT42?”

But for SOC automation, where we’re doing pattern matching and payload analysis (not writing poetry), 8B models are shockingly capable.

Proxmox Setup: The Foundation

Installation

  1. Download Proxmox VE ISO from proxmox.com
  2. Flash to USB (Ventoy is my new goto solution at the moment)
  3. Boot from USB, follow installer
  4. Set static IP for management interface
  5. Access web UI: https://<proxmox-ip>:8006

Initial Configuration

# SSH into Proxmox host
ssh root@<proxmox-ip>

# Disable enterprise repo (unless you bought a subscription, lol)
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list

# Add no-subscription repo
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list

# Update
apt update && apt full-upgrade -y

# Reboot
reboot

VM Resource Planning

For this series, we’ll create three VMs:

  1. Wazuh Manager (Ubuntu 26.04)
    • 4 vCPU, 8GB RAM, 100GB disk
    • Runs the Wazuh manager, indexer, and dashboard
  2. n8n SOAR (Ubuntu 26.04)
    • 2 vCPU, 4GB RAM, 50GB disk
    • Lightweight automation engine
  3. Ollama Inference (Ubuntu 26.04)
    • 4 vCPU, 16GB RAM, 200GB disk
    • GPU pass-through (we’ll configure this in Part 3)
    • Stores model weights (~4-7GB per model)

Create the VMs in Proxmox:

# Example: Create Wazuh VM via CLI (or use the web UI)
qm create 100 --name wazuh-manager --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0
qm importdisk 100 ubuntu-22.04.iso local-lvm
qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0
qm set 100 --boot c --bootdisk scsi0
qm set 100 --ide2 local:iso/ubuntu-22.04.iso,media=cdrom
qm set 100 --serial0 socket --vga serial0
qm start 100

(In practice, I just use the web UI. The CLI is for showing off.)

Network Topology: Keeping It Simple

For a homelab, flat networking is fine. All VMs on the same subnet, firewalled from the internet via your pfSense.

Internet
   │
   ├─ Router (192.168.1.1)
   │     │
   │     └─ Proxmox Host (192.168.1.10)
   │           ├─ Wazuh (192.168.1.11)
   │           ├─ n8n (192.168.1.12)
   │           └─ Ollama (192.168.1.13)
   │
   └─ Monitored Endpoints (Wazuh agents)
         ├─ Windows Desktop (192.168.1.50)
         ├─ Linux Laptop (192.168.1.51)
         └─ Random IoT Device (192.168.1.52)

Security note: Do NOT expose Wazuh, n8n, or Ollama to the public internet. If you need remote access, use WireGuard. If you expose the Ollama API port (11434) to the web, someone will find it and use your GPU to generate furry erotica.

What’s Next?

In Part 2: The Data Pipeline & Telemetry, we’ll:

  • Deploy Wazuh on Proxmox
  • Configure log ingestion with sanity filters (because LLM context windows are expensive, even locally)
  • Set up alerting rules to push high-fidelity events to n8n
  • Discuss why “send everything to the AI” is a terrible idea

Key takeaway: We’re building a system where AI confidence is a first-class citizen. High confidence? Automate. Low confidence? Escalate. Always log the reasoning.

If you’re following along, get Proxmox installed and the VMs created. We’ll start wiring things together next week.

Got questions or spotted a flaw in the architecture? I’m on LinkedIn. If you’re building something similar, I’d love to see your stack.

References

Twitter, Facebook