CortexPF

• 

  Real-time SOC dashboard — event volume, severity breakdown, and detection metrics fetched live from the backend.

• 

  CortexPF overview — live event counts, alerts, and threats, with links to the architecture and source.

• 

  Live kernel event feed from the eBPF agent — process, network, and file events streaming in real time.

• 

  Threat intelligence view — IOCs from the abuse.ch C2 feed used to flag malicious connections.

• 

  AI decision engine — each alert analyzed for an action, confidence, and reasoning, then verified by the safety gates.

What it does

CortexPF closes the loop between threat detection and response. It watches the Linux kernel with eBPF, streams every event into Splunk, and lets an AI agent decide how to respond — but the core idea is restraint. Every action the AI proposes passes through three independent safety gates before anything touches the system.

A known C2 IP gets blocked automatically. A private IP or a critical process like PID 1 gets refused by the blast-radius gate — even when the AI is 97% confident and policy approves. It responds in seconds, without ever risking your own infrastructure. How we built it

• eBPF agent hooks execve, tcp_v4_connect, and do_sys_openat2 to capture process, network, and file events at the kernel level — tested past 1,000,000 events.
• A Go backend routes events, runs detection rules, checks abuse.ch threat intel, and forwards everything to Splunk Cloud via HEC, tagged by type (cortexpf:exec, cortexpf:net, cortexpf:alert).
• An AI agent (Gemini) analyzes each alert and returns an action with confidence and reasoning.
• Three gates verify it: a risk scorer, a YAML policy engine (auto-execute vs suggest-only), and a blast-radius gate that inspects the real target before acting.
• Actions run through a typed MCP server (kill_process, block_ip) with an append-only audit log.

Splunk integration

Splunk is the SIEM and analytics plane. Every event and alert is searchable with SPL — hunting executions from /tmp, or connections to known C2 IPs. Over 10,000 events flowed through during testing.

Challenges

• Splunk Cloud HEC needs an X-Splunk-Request-Channel header — without it you get a "data channel missing" error.
• Making the blast-radius gate deterministic and independent of the AI, so even a high-confidence wrong decision still gets vetoed.

What I learned

How to wire kernel-level telemetry all the way into a SIEM, and how to make autonomous response safe through layered architectural guardrails — not just prompts.

What's next

Real memory and disk forensics (Volatility3, Plaso), behavioral baselining, and executing the Terraform/Kubernetes remediation that's currently validated but not yet applied.

Built With

• docker
• ebpf
• gemini
• go
• kubernetes
• linux
• mcp
• react
• splunk
• sqlite
• terraform