In Part 1, I walked through the journey of capturing every AI agent action at the kernel level — from failed userspace approaches to eBPF, ETW, and ESF across three operating systems. Session tracking, smart sampling, cross-platform normalization. By the end, I had a system that could see everything an AI agent does.

This is Part 2 of a three-part series on building Correlic:

• Part 1: Capturing every AI agent action
• Part 2: Detection, baselines, and incidents (this post)
• Part 3: The AI investigation system (coming next)

The problem at the end of Part 1 was simple to state and hard to solve: the system could see everything. It couldn't think about what it saw.

The First Detection Rule I Wrote — And Why It Was Immediately Useless

My first rule was obvious: if an AI agent reads an SSH private key, alert me.

I wrote it in about twenty minutes. Trigger on file_open events where the path contains /.ssh/ and the filename matches id_rsa, id_ed25519, or id_ecdsa. Set severity to critical. Done.

I ran it. Within an hour, I had 47 findings. Most of them were from ssh itself reading its own config during normal Git operations. A few were from system services checking key permissions. Exactly one was from Claude Code.

The rule was technically correct — those files were being read. But 46 out of 47 findings were noise from processes that had nothing to do with AI agents. If I deployed this, nobody would look at the findings after the first day.

I researched how EDR vendors handle this problem. Read about SentinelOne's behavioral detection model, CrowdStrike's process context approach, and the general concept of attribution-scoped detection. Used Claude to help me think through different filtering strategies.

The breakthrough was deceptively simple: AI-gating.

Every detection rule checks one thing before evaluating anything else: did this event come from an AI agent process tree? If the originating process isn't a descendant of a known AI agent (tracked by the session UUID system from Part 1), the rule doesn't evaluate. Period.

The implementation is straightforward. The detection engine indexes rules by event type for O(1) lookup. When an event arrives, it fetches the applicable rules and invokes each one through a safeEvaluate() wrapper — which includes panic recovery so a malformed event can't crash the entire detection pipeline. But before any of that, the AI-gating check runs. No AI attribution, no evaluation.

The result was dramatic. System daemons, background services, my own manual commands — all invisible to detection. The 47 findings dropped to 1. The one that actually mattered.

13 Rules — Not From a Spreadsheet, From Watching AI Agents Do Weird Things

I didn't plan 13 rules from the start. Each one was born from something I actually observed during testing — a pattern that made me think "the system should have caught this."

They cover the things that matter when an AI agent goes off-script: credential access (with tiered sensitivity — SSH keys are critical, .env files are lower priority), data exfiltration (the read-sensitive-file-then-make-network-connection pattern within a 15-minute window), unauthorized command execution (including pipe-to-shell like curl | bash which always fires regardless of domain), reconnaissance bursts (3+ enumeration commands in 60 seconds), persistence attempts (cron jobs, systemd services), privilege escalation, code tampering (CI/CD configs), container escape, and more.

Every rule is mapped to MITRE ATT&CK techniques, so findings immediately make sense to anyone with a security background.

Two design choices I want to highlight because they shaped everything that came after:

Tiered confidence, not binary alerts. Not every match is equally suspicious. SSH private key access by an AI agent gets 0.90 confidence. A file named config.secret.yaml gets 0.60. This matters because findings with low confidence (below 0.60) get severity-dampened — CRITICAL drops to HIGH, HIGH drops to MEDIUM. Without this, low-confidence detections would drown out the real threats.

Pipe-to-shell never gets suppressed. When an AI agent runs curl something | bash, it fires at high confidence no matter what domain is in the URL. Even github.com. A safe domain today can serve malicious content tomorrow. This is the one rule where I deliberately chose zero exceptions. Supply chain attacks are too dangerous to give the benefit of the doubt.

Severity Dampening — Because Not All Detections Are Equal

Early on, I had a problem with overly aggressive severity ratings. A rule might fire at CRITICAL severity because the pattern matched perfectly — SSH key access from an AI agent — but the confidence was only 0.45 because the context was ambiguous (maybe the agent was checking file permissions, not reading the key contents).

I added severity dampening: findings with confidence below 0.60 get downgraded one level. CRITICAL becomes HIGH. HIGH becomes MEDIUM. This prevents low-confidence detections from drowning out genuinely high-confidence ones in the findings queue.

Simple rule, significant impact on usability.

I Solved the Event Flood. Then I Created a Finding Flood.

The detection engine worked perfectly. Too perfectly.

The first week I ran it with all 13 rules active, I got 200+ findings per day. Claude Code reading .env files — credential_access, Tier 2. Cursor running npm install — authorized, but the node process tree triggered file_activity. SSH config checks — credential_access, repeatedly. Every finding was technically correct. Almost none of them were actionable.

I'd solved the raw event flood with smart sampling. Now I had a finding flood. Different problem, same symptom: too much noise, real threats invisible.

I needed the system to learn what's normal for MY environment and stop alerting on expected behavior.

Auto-Learning — Observe, Remember, Suppress

The baseline system works on a simple principle: events that pass through all 13 detection rules without generating a single finding are probably normal. Observe the pattern. If it keeps appearing without triggering anything, learn it and suppress future matches.

I researched how EDR and UEBA platforms handle behavioral learning. Read about anomaly detection approaches, statistical baselines, and the trade-offs between auto-learning and manual curation. Used Claude to help me design the pattern extraction logic and think through the edge cases.

The extraction depends on event type. File events get baselined at the exact file path — if ~/.config/gcloud/credentials passes cleanly, that specific path is observed. Directory-level baselines (covering entire folder trees) are only created when a user explicitly clicks "Allow Always" on a finding — auto-learning doesn't make broad assumptions. Network events use BGP prefix plus port (104.18.0.0/24:443), so a baseline covers an entire service's IP range. DNS events use the domain name.

Observed baselines have a 30-day TTL from their last-seen timestamp. If a pattern isn't seen again within 30 days, the baseline expires and the pattern starts generating findings again. This prevents stale baselines from hiding threats in workflows that have changed.

There's also a hit count threshold: 5 observations before a baseline becomes active. A one-time event that happened to trigger zero findings doesn't get baselined — it might just be an event the rules don't cover yet.

The cache uses composite keys for O(1) in-memory lookup, refreshed from PostgreSQL every 30 seconds. When a finding is produced, the baseline check adds microseconds to the pipeline — negligible.

The Never-Baseline List — What the System Must Never Learn to Ignore

About a week into testing auto-baselines, I had a realization that stopped me cold.

If the system auto-baselines everything that triggers zero findings, what happens when an attacker accesses SSH keys without triggering any other rules? The credential_access rule fires, but if the user doesn't triage it and the agent keeps accessing the key... eventually the system could learn to suppress it.

Even worse: what if an attacker slowly normalizes access to sensitive resources over time? Day 1: access the key once. Day 2: access it again. Day 30: the system thinks it's normal.

I built the never-baseline list. Certain categories of resources are excluded from auto-learning no matter what: SSH private keys, cloud credentials, system authentication files, dangerous binaries commonly used in attack chains, known C2 and malware network ports, Tor exit nodes, paste services, and file-sharing domains.

The list covers files, binaries, ports, and DNS domains — anything that appears in real attack patterns. I don't care if your AI agent accesses your SSH keys every single session. You should always know about it. The system will never learn to look away.

User Feedback — Every Click Trains the System

The auto-learning handles the obvious stuff. But the real power comes from user decisions.

When you review a finding in the dashboard, you have four options:

Allow creates a permanent, user-confirmed baseline. It never expires. It's never downgraded to an observed baseline. If a human says "this is normal," the system respects that decision permanently. The database enforces this with a SQL CASE expression on upsert — user-confirmed is the highest trust level and can never be overwritten.

Block flags the pattern as malicious and elevates it in future detections. When I build the Response Cycle (coming later), blocked patterns will enable active enforcement — automatically stopping unknown network connections, file access, and ports. For now, Block is the strongest signal the system tracks.

Dismiss marks the finding as a false positive. No baseline created — useful for one-time events that won't recur.

Investigate flags it for deeper review.

There's a security gate on the Allow path: even if a user clicks Allow, the never-baseline list blocks the baseline from being created for sensitive resources. You can't accidentally allow-always your SSH key access. The system protects you from yourself.

The 48-Hour Maturation Curve

The combined effect of auto-learning and user feedback creates a predictable noise reduction curve:

Day 1: 200+ findings. The system is new to your environment. Everything is flagged. Spend 15 minutes clicking Allow on the obvious stuff — your project files, your standard build tools, your known API connections.

Day 2: About 40 findings. Auto-baselines have accumulated. The most common patterns are suppressed. You're seeing things you haven't triaged yet.

Week 1: About 20 findings. The system understands your environment. What remains is genuinely novel: new binaries, new network destinations, new file access patterns.

Ongoing: Single-digit findings on most days. When something does appear, it's worth your attention.

That maturation curve — noisy to smart in roughly 48 hours — became the core user experience of the product.

"SSH Key Read" and "Network Connection" Are Two Alerts. But They're One Attack.

With baselines reducing noise, my findings queue was manageable. But I noticed something that bothered me.

An AI agent reads ~/.ssh/id_rsa — credential_access finding fires. Two minutes later, a child process runs curl to an external IP — data_exfiltration finding fires. Two separate alerts. Two separate items in my queue. I'd triage the credential access, then separately triage the exfiltration, and only in my head would I connect them: "wait, those are the same session. That's not two problems — that's one attack."

The system was catching individual steps. But it wasn't seeing the story.

I researched how security tools handle this — MITRE ATT&CK's kill chain concept, how CrowdStrike constructs attack sequences. Used Claude to help me design the matching logic. The result: 11 predefined attack chain patterns, each describing a specific multi-step sequence that, when observed in order within a time window, gets flagged as a single coherent attack.

Some examples of what the chain correlator catches:

• Your agent reads SSH keys, then makes an outbound connection → credential theft (20-minute window)
• Your agent runs nc or curl, then connects to an unusual port → reverse shell setup (5 minutes)
• Your agent modifies a GitHub Actions workflow, then sends data externally → supply chain attack (20 minutes)
• Your agent runs privilege escalation, then creates a cron job → persistence backdoor (15 minutes)

When a chain fires, the severity gets amplified — because a multi-step attack is categorically more dangerous than any single step. And chains bypass the cooldown system entirely. If an AI agent is executing a credential theft sequence, I don't want rate-limiting to suppress the alert because a similar finding fired recently. Multi-step attacks are too important to rate-limit.

But here's the thing about chains: they only catch predefined patterns. I defined 11 of them, and they're good. But what about the stuff that doesn't fit neatly into a pattern?

Why Chains Aren't Enough — The Incident Layer

Imagine this timeline from a single AI session:

10:00  discovery — whoami, id, uname (recon burst)
10:02  credential_access — reads ~/.ssh/id_rsa
10:04  unauthorized_exec — spawns curl
10:05  data_exfiltration — curl sends data to unknown IP
10:08  persistence — creates a cron job

The chain correlator catches credential theft (step 2 → step 4). That's one chain finding. Good.

But what about the recon at 10:00? And the persistence at 10:08? Those aren't part of the credential theft chain pattern. They're separate findings sitting in my queue — disconnected from the chain, even though they're clearly part of the same attack by the same agent in the same session.

Without something tying all of these together, the analyst sees:

• 1 chain finding (credential theft)
• 1 discovery finding
• 1 persistence finding
• 3 separate items competing for attention

That's when I realized I needed a layer above chains. Not pattern matching — session grouping. Everything an AI agent does within a time window, grouped into one investigation container. Whether it matches a predefined chain or not.

That container is an incident.

The logic is simple: findings from the same host and AI session within a 30-minute window get merged into a single incident. Chain findings create new incidents and pull in all their constituent steps. Standalone findings try to merge into an existing open incident from the same session.

So that timeline above becomes one incident with five findings and one chain — the complete picture of what this AI session did, in one place, with one timeline.

The difference in usability was night and day. Instead of triaging 5 separate items from that session, I open one incident and see everything: the recon, the credential theft, the persistence attempt. One investigation instead of five scattered alerts.

A few design decisions I landed on after iterating:

Auto-resolve for the small stuff. Low-severity standalone findings (like a single discovery command) create auto-resolved incidents. They're in the system for audit, but they don't clutter the active queue. If a high-severity finding later merges into that auto-resolved incident — say, the discovery was followed by privilege escalation 10 minutes later — the incident automatically reopens. What looked harmless might have been the first step of something bigger.

Severity is always the worst case. The incident's severity equals the highest severity among all its findings. If a chain is present, severity gets promoted one more rank. A medium finding that joins an incident with a critical chain doesn't water down the severity — the critical stands.

Chains tell you WHAT happened. Incidents tell you EVERYTHING that happened. Chains are pattern recognition: "these specific steps match a known attack." Incidents are session context: "here's the full story, whether it matches a pattern or not." You need both.

The Moment It All Came Together

I was running a routine Claude Code session. Debugging some API logic, nothing unusual. A notification popped up: credential theft chain detected, critical severity.

I opened the incident. Not the chain. Not a single finding. The incident — which had already assembled the full story for me.

I'd deliberately prompted Claude Code to check my SSH setup and test a remote connection — I wanted to see how the system handled a realistic multi-step flow. The timeline showed exactly what happened: Claude Code read ~/.ssh/config (baselined, expected — no finding). Then it read ~/.ssh/id_rsa (never-baselined — credential_access finding fired). Then a child process spawned curl to an external IP on a non-standard port (data_exfiltration finding). The chain correlator had connected the credential access and the exfiltration into a credential theft chain. The incident correlator had grouped everything into one investigation.

One incident. One timeline. Every finding, every chain, every event — connected by session tracking, correlated by pattern matching, grouped by session context.

I didn't triage 3 findings. I opened 1 incident and saw the complete attack in under a minute.

That's when it stopped being a side project.

What's Still Missing

Detection tells me what happened. Baselines tell me what's normal. Incidents tell me what's important.

But investigating incidents was still manual work. Open the incident, read the timeline, trace the process tree, look up the destination IP, mentally reconstruct the narrative: was this a real threat, or an unusual-but-benign pattern? For a simple incident, that takes a few minutes. For a complex one with 20+ events across multiple process branches, it takes 15-20 minutes.

The obvious next step: use AI to do the analysis. Feed the incident's timeline, process tree, network connections, and behavioral context into an LLM and ask "what happened here?"

But the biggest challenge wasn't plugging in an LLM. It was making sure the AI never assumes, never hallucinates, and only draws conclusions from actual evidence. In security, a confident wrong answer is worse than no answer at all.

That's Part 3.

This is Part 2 of a three-part series on building Correlic.

• Part 1: I Built a Kernel-Level Monitor for AI Agents. Here's Every Wall I Hit.
• Part 2: Your AI Agent Made 70 System Calls Per Second. Here's How I Taught My System Which Ones Matter. (this post)
• Part 3: Building an AI Investigation System That Never Hallucinates (coming next)

I promised I'd show you what I built. But I don't want to just list features. I want to walk you through the journey — every wrong turn, every problem that forced the next decision. Because the architecture didn't come from a whiteboard. It came from hitting walls.

This is Part 1 of a three-part series on building Correlic:

• Part 1: Capturing every AI agent action (this post)
• Part 2: Detection, baselines, and incidents (coming next)
• Part 3: The AI investigation system

Before Any Code — Defining What "Complete Visibility" Actually Means

Before writing any code, I sat down and listed what a complete picture of AI agent activity looks like:

• Process execution — every command the agent runs, what spawned it, what arguments it used
• File access — every file opened, read, written, deleted
• Network connections — every outbound TCP connection, every DNS query
• Process trees — which processes are children of the AI agent, and which are unrelated system activity

Miss any one of these, and you have blind spots. An agent reading your SSH keys is suspicious — but did it also make an outbound connection? Without network visibility, you'd never know. An agent making a connection is concerning — but what files did it access first? Without file visibility, you can't tell if it's a normal API call or data exfiltration.

I needed all four. The question was how.

Phase 1: The Userspace Frankenstein — Four Tools, Zero Coherence

My first approach was to stay in userspace and cobble together existing Linux tools and APIs. Kernel-level monitoring felt like overkill at that point — I figured I could get enough visibility without going that deep.

I researched the available options and tried several:

Watching Files — fanotify, Mount-Level Hooks, and the Illusion of Visibility

Linux has built-in file monitoring through inotify and its newer sibling fanotify. I read through the man pages, went through the kernel documentation, and used Claude to understand the differences between them. I went with fanotify because it can monitor entire mount points rather than individual directories — I wouldn't need to recursively add watchers.

I got it working fairly quickly. File opens, file writes, file deletes — all visible. For a few hours I felt like I was making progress.

The problem: fanotify gives you the file path and the PID, but the process context is shallow. You get which process touched the file, but not why — not the full command-line arguments, not the parent process, not the session context. And critically, no network visibility at all.

Chasing Processes — Polling /proc at 100ms and Still Missing Everything

For process execution, I polled /proc — the pseudo-filesystem where Linux exposes process information. Every 100ms, scan /proc/*/stat and /proc/*/cmdline for new PIDs, build a process list, diff against the previous scan.

This worked but was fundamentally racy. Short-lived processes — and AI agents spawn a lot of them — could start and exit between poll intervals. A curl that runs for 30ms would never appear in my scan. I was missing exactly the processes I cared about most.

I tried reducing the poll interval to 10ms. CPU usage spiked. And I was still missing fast processes occasionally.

Sniffing Packets — libpcap Sees Everything Except Who Sent It

For network connections, I used libpcap through the gopacket Go library. Packet capture at the network interface level — I could see every TCP SYN, every DNS query.

But here's where things started falling apart. libpcap sees packets, not processes. I could see a TCP connection to 185.243.115.42:8443, but I had no idea which process made it. Was that Claude Code? Was that my browser? Was that a background service? Without process-level attribution, network capture was data without meaning.

I tried correlating libpcap data with /proc/net/tcp to match connections to PIDs. It was fragile. The timing rarely lined up — by the time I read /proc/net/tcp, short-lived connections were already gone. I'd have a packet capture showing a suspicious connection and a process list that didn't include the process that made it.

Bridging the Gap — ss, lsof, and the 5ms Processes That Vanish

I also tried using ss (socket statistics) and lsof to get process-attributed network connections. Poll every second, capture which PIDs have which sockets.

Same problem as /proc polling — racy with short-lived processes. And the overhead was significant. Parsing ss or lsof output every second while an AI agent is generating dozens of processes and connections was burning CPU for unreliable results.

The Verdict — Why Userspace Monitoring Can't Work for AI Agents

After two weeks of trying different combinations, I had a Frankenstein stack: fanotify for files, /proc polling for processes, libpcap for packets, ss for connection attribution. Four data sources, none of them reliable for short-lived events, and no coherent way to correlate them.

The core issues:

1. Timing mismatches. Each data source operated on its own schedule. A file read, a process spawn, and a network connection that happened in the same millisecond would arrive at my collector at different times from different sources. Correlating them was guess-work.

2. Short-lived process blindness. AI agents spawn processes that live for milliseconds. Poll-based approaches miss them consistently. The most interesting events — curl to an unknown endpoint, cat on a credential file — happen in processes that are born and die between polls.

3. No unified attribution. Even when I had all four data streams, connecting "this file read" to "this network connection" to "this process" required timestamp-based heuristics that were wrong as often as they were right.

4. CPU overhead. Running four monitoring systems simultaneously, each polling at high frequency, consumed real resources. On my development machine it was manageable. On a busy server, it would be unacceptable.

I stepped back and asked: how do the professionals solve this? Not the "good enough" version — how do CrowdStrike, SentinelOne, and the serious EDR vendors get complete, reliable, attributed visibility into every system call?

The answer, every time, was the same: they go to the kernel.

Phase 2: Down the Kernel Rabbit Hole — eBPF Changes Everything

I spent two weeks researching before writing a single line of eBPF code. This was a domain I'd never worked in.

Brendan Gregg's BPF Performance Tools was my starting point — I read the first six chapters cover to cover. Then the cilium/ebpf Go library documentation. The kernel tracepoint reference. Blog posts from the Cilium and Tetragon teams about using eBPF for security observability. I used Claude extensively during this phase — not to write the code, but to understand concepts. "Explain what a tracepoint is versus a kprobe." "What's the difference between a ring buffer and a perf buffer?" "Why does the verifier reject bounded loops in some cases?" Each answer led to five more questions, and I'd research those through the kernel docs and technical blogs.

The short version for anyone who hasn't encountered eBPF: you write small C programs that the kernel loads and runs at specific hook points — system call entry, process scheduling, network operations. The kernel executes your program synchronously when the hook fires. Every file open, every network connection, every process spawn — you see it as it happens, not after the fact. Near-zero performance overhead because you're running inside the kernel, not polling from outside.

The difference from my userspace approach was night and day. No polling. No timing mismatches. No missed events. Every system call captured synchronously at the exact moment it happens, with full process context.

The First Hook — execsnoop and the Moment It Clicked

My first eBPF program was execsnoop — a tracepoint on sched_process_exec that fires every time a process starts. I followed Brendan Gregg's examples as a template, adapted them for my event schema, used Claude to help me structure the C program and the Go loader, compiled with clang, loaded with cilium/ebpf.

It took me three days to get the compilation pipeline working reliably. Cross-compiling C for the kernel from a Go build system isn't straightforward, and the error messages when something goes wrong are not friendly. But when it finally ran and I saw Claude Code's process tree scroll by in real-time — every bash it spawned, every node process, every curl — I knew this was the right approach.

Expanding the Net — File Access and Network Hooks

Then I added fileopen — a tracepoint on sys_enter_openat that fires on every file open system call. And connect — a kprobe on sys_connect that fires on every outbound TCP connection.

Three eBPF programs, three ring buffers, three event streams. The first time I ran all three alongside a Claude Code session, I saw everything. Every file it read. Every command it spawned. Every connection it made. Complete visibility. No gaps. No polling. No missed events.

It was exhilarating. It was also the beginning of a new set of problems.

Wall #1: When Your Parser Reads Garbage — The Struct Padding Trap

My first event parser was reading garbage. PIDs showed up as astronomical numbers. Timestamps made no sense. I spent an entire day staring at hex dumps of ring buffer output, comparing what the C struct should contain versus what my Go parser was actually reading.

I searched "eBPF struct alignment Go parser" and found blog posts explaining the problem. The C compiler inserts padding bytes between struct fields for memory alignment. A __u32 followed by a __u64 gets 4 bytes of invisible padding so the __u64 starts on an 8-byte boundary. My Go parser was reading at the wrong offsets — everything after the first padding gap was shifted by 4 bytes.

I found a tool called pahole that shows the actual struct layout with all padding included. I used Claude to help me write a Go parser that matched the padded layout exactly. That fixed it immediately. Now I run pahole on every C struct before writing the Go parser. Hard lesson, simple fix — but I lost a full day to it.

Wall #2: The Kernel Says No — Fighting the eBPF Verifier

The kernel verifier rejected my first three attempts at file path extraction.

Every eBPF program goes through a static analysis pass before the kernel will load it. The verifier ensures your program can't crash the kernel, can't access unauthorized memory, and will always terminate. Stack size is limited to 512 bytes. Loops must be provably bounded. Pointer arithmetic must be statically trackable.

My initial file path buffer was too large for the stack. My path traversal loop was rejected because the verifier couldn't prove termination. My pointer arithmetic for parsing variable-length strings was too complex for static analysis.

I spent days reading verifier error messages, searching each one, going through kernel documentation and mailing list threads from developers hitting the same walls. I used Claude to help me understand what the verifier was actually complaining about and to explore alternative approaches. Eventually I learned to think like the verifier: bounded loops with explicit counters, fixed-size buffers within stack limits, no arithmetic the verifier can't track. It's a different way of programming — you're not just writing correct code, you're writing provably correct code.

Wall #3: Silent Event Drops — Ring Buffer Sizing With No Reference Point

Too small and events get silently dropped — you don't even know you missed them. Too large and you're wasting kernel memory. I had no reference for "how many events per second does an AI coding session generate." Nobody had measured this before.

Trial and error. Small buffer, watch the drop counter climb, increase, repeat. I discovered that a typical Claude Code session generates about 70 events per second across all hook points. It took weeks of adjusting and testing under different workloads before I found buffer sizes where the drop counter stayed reliably at zero.

Finally — Complete Kernel-Level Visibility

But it worked. For the first time, I had complete, reliable, attributed visibility into what an AI agent was doing on my machine. Every process spawn with full command-line arguments. Every file open with the complete path. Every network connection with the destination IP and port. All with the PID and process context that told me exactly who made each call.

The difference from the userspace Frankenstein was stark. One unified data source instead of four. Synchronous capture instead of polling. Zero missed events instead of probabilistic coverage. And dramatically lower overhead — the eBPF programs run inside the kernel's existing code paths, adding microseconds per event rather than the milliseconds of constant polling.

Phase 3: Drowning in Data — When Seeing Everything Becomes the Problem

And then I had a different problem: too much data.

A single Claude Code session generates hundreds of events per minute. File reads on project files. Process spawns for node, npm, tsc. Network connections to the Anthropic API, to npm registries, to GitHub. The vast majority of it completely normal development activity.

My first attempt at a dashboard was a scrolling list of events. Unusable. A wall of text streaming faster than I could read. Trying to spot something suspicious in there was like trying to find a specific raindrop in a storm.

I tried filtering by event type — only show network connections. But then I'd miss the file read that happened 30 seconds before the suspicious connection. Context was everything, and filtering destroyed context.

I researched how observability platforms handle high-volume event streams. Read about how Datadog and Prometheus approach sampling. Read about security-specific event filtering in EDR architectures. I used Claude to help me think through different sampling strategies and their trade-offs.

The insight: not all events are equal. Some should always be kept — anything touching SSH keys, cloud credentials, /etc/shadow, crypto material. Some should always be dropped — ls, grep, common build tools reading known-safe paths. Everything else gets probabilistically sampled.

The ordering is critical, and I almost got it wrong. The suspicious pattern check has to come before the benign process filter. If you check benign first, cat /etc/shadow gets dropped because cat is a benign binary. That's a security hole. I caught it during testing when credential access events disappeared from my logs. Reordered the pipeline and left a big comment in the code so I'd never accidentally flip it back.

One more critical rule: AI agent events bypass sampling entirely. The whole point of the tool is monitoring AI agents — I'm not going to let the sampling engine filter them out. Every event from an AI session is kept, no matter what.

Result: about 90% volume reduction, but every security-relevant event survives. The dashboard went from a firehose to something I could actually read.

Phase 4: The Attribution Problem — 4 PIDs, 1 Agent, Zero Connection

Now I could see everything, but I still had an attribution problem.

When Claude Code spawns bash, which spawns curl, which makes a TCP connection — those are four separate processes with four separate PIDs. My eBPF programs captured each event perfectly, but they showed up as unrelated. A file read by PID 12847. A network connection by PID 12849. No indication they were part of the same AI coding session.

I researched how EDR tools handle process trees. Read CrowdStrike's technical documentation on process lineage, the Linux audit subsystem's approach to parent-child tracking, kernel process management internals. I used Claude to help me think through different attribution models and their edge cases.

The solution: when I detect an AI agent root process — by pattern matching on executable names and command-line arguments — I assign it a unique session UUID. Every child process inherits that UUID through a lineage tracker. Every grandchild inherits it. One session, one ID, entire process tree tracked.

The 50ms Race Condition That Nearly Broke Everything

This worked beautifully — until it didn't.

Short-lived processes like curl would spawn, make a network connection, and exit in under 50 milliseconds. The network event from eBPF would arrive at my Go program before the fork event that told me the process even existed. I was losing attribution on exactly the processes I cared about most — the ones making network connections to external servers.

I tried buffering events and reordering them by timestamp. Too slow, too complex, and it introduced its own race conditions. I tried prioritizing the fork ring buffer. Didn't help — the events come from different kernel subsystems with independent delivery paths.

I went back to the kernel docs and spent time reading about BPF maps — hash maps that live in kernel space and are accessible from both BPF programs and userspace code. I used Claude to help me design a two-layered solution:

Layer 1 — Kernel-side. I maintain a BPF hash map inside the kernel that tracks known AI process PIDs. When a uprobe fires for a process I don't recognize in userspace, the BPF program checks the parent PID against the kernel-side map. If the parent is a known AI process, the child gets registered atomically — right there in kernel space. Zero latency. No race condition possible.

Layer 2 — Userspace grace period. When a PID exits, its session mapping sticks around for 10 more seconds. Any late-arriving events from that PID still get attributed to the correct AI session. Short-lived processes that exit before their events are fully processed don't lose their identity.

Paranoid? Definitely. But I stopped losing events. And that race condition fix became one of the most important pieces of the entire architecture.

Phase 5: Three Operating Systems, Three Completely Different Kernel APIs

With Linux working reliably, I turned to the other platforms. Developers use AI agents on Windows and macOS too — I couldn't be Linux-only.

Windows — ETW, Undocumented Structs, and the 5ms Command-Line Problem

Windows has its own kernel instrumentation: Event Tracing for Windows (ETW). I researched the available kernel providers, read Microsoft's documentation, and used Claude to help me understand the ETW session model and the UserData struct formats.

I set up a single ETW real-time session with four kernel providers: Kernel-Process (process start/stop), Kernel-File (file operations), Kernel-Network (TCP connect/accept), and DNS-Client (DNS queries). I supplemented this with Windows Security Audit events for process command lines and the NTFS USN Journal for reliable file change tracking.

Windows threw its own unique challenges. The ETW UserData structs are underdocumented — field offsets change between Windows versions, and I had to reverse-engineer the layouts by hex-dumping real events on my Windows 11 test machine. Path normalization was a nightmare: paths arrive in NT device format (\Device\HarddiskVolume3\Users\...), UNC format, with mixed slashes, and with various prefix notations. I built a normalization layer that converts everything to consistent forward-slash format with drive letters.

The hardest Windows-specific problem: command-line capture for short-lived processes. On Linux, eBPF gives me command-line arguments synchronously. On Windows, reading the Process Environment Block (PEB) requires a userspace call to NtQueryInformationProcess and ReadProcessMemory — but short-lived processes like curl or cat exit in under 5 milliseconds, before the read completes. I built a three-tier fallback: Security Audit event 4688 cache (kernel-written, 100% reliable but not always enabled), PEB read inside the ETW callback itself, and a runner-side fallback as a last resort.

macOS — Clean APIs, Missing Network Events, and the lsof Compromise

macOS uses Apple's Endpoint Security Framework (ESF). I researched the available event types, read Apple's developer documentation, and used Claude to help me write the native C wrapper that Go calls through cgo.

ESF provides process execution, process exit, file open, and fork notifications with full process metadata. The implementation was cleaner than Windows in many ways — Apple's API is well-designed. But macOS has its own pain point: Full Disk Access permissions and entitlement requirements that vary by macOS version.

Network monitoring on macOS was the gap. ESF doesn't expose network events — Apple requires a Network Extension entitlement for that, which has its own signing and provisioning complexity. For now, I use lsof polling at 2-second intervals for network connection visibility. It's the one place where I'm still polling rather than getting synchronous kernel events. The ESF network gap is on the roadmap.

One Schema to Rule Them All — Cross-Platform Event Normalization

Three platforms, three completely different kernel APIs, three different event formats. I needed detection rules that work identically regardless of which OS the event came from.

I built a canonical event schema with three components: Actor (PID, PPID, executable path, command line, username, AI session ID), Target (file path or IP:port or domain), and Context (timestamps, platform, container info). Every platform collector normalizes its native events into this schema before dispatch. A detection rule checking for SSH key access works the same whether the event came from an eBPF tracepoint on Linux, a USN Journal entry on Windows, or an ESF notification on macOS.

Where This Leaves Us — And What's Still Missing

At this point, I had a working cross-platform kernel-level monitoring system. Every process spawn, every file access, every network connection from an AI agent process tree — captured, attributed, sampled, and normalized.

The agent runs silently. Sub-millisecond overhead per event. Zero silent drops on Linux and Windows. Full AI session attribution with the race condition solved. Smart sampling reducing noise by 90% without losing security-relevant events.

But capturing events is just the foundation. Seeing everything is useful, but what I really needed was the system to tell me when something was wrong. To distinguish "Claude Code reading project files" from "Claude Code reading my SSH private key and then making an outbound connection to an unknown IP."

That required detection rules, behavioral baselines, and incident correlation — which is a whole different set of problems and a whole different set of walls.

That's Part 3.

This is Part 1 of a three-part series on building Correlic.

• Part 1: I Built a Kernel-Level Monitor for AI Agents. Here's Every Wall I Hit. (this post)
• Part 2: From Raw Events to Real Threats — Detection, Baselines, and Incidents (coming next)
• Part 3: Building an AI Investigation System That Never Hallucinates

I know this because I built the monitoring to see it. And what I found scared me enough to write this.

Quick Background: Why I Can't Turn Off the Security Part of My Brain

I spent 7 years as a software engineer before moving into DevSecOps. Two years fullstack, three years senior backend at a fintech — building APIs, wiring up Kafka queues, provisioning AWS infra, implementing Redis caching. I also set up our entire observability stack: Grafana, Loki, Prometheus, eventually ELK.

But the whole time, I was also solving CTFs, reading vulnerability disclosures, and once asked our DevOps lead for permission to pentest our own servers. (I found things.)

That dual lens — writing production code by day, thinking like an attacker by night — is exactly why AI coding tools worry me in a way they don't worry most of my colleagues.

I'm not anti-AI. I use Claude Code and Cursor daily. The productivity is real and I'm not going back. But I can't unsee what's happening underneath.

The Trust Escalation Nobody Talks About

Cast your mind back. In the Stack Overflow era, developers copied code snippets without auditing them. Nobody checked the top-voted answer for injection vulnerabilities. Nobody verified the dependency tree of that library they just imported. And that was just text on a screen — you still had to paste it, read it, run it yourself.

Now compare that to what AI agents actually do:

• They don't suggest code. They execute it. Claude Code spawns shell processes and runs bash commands. Cursor executes arbitrary commands in your terminal. They operate with your full user permissions.
• They spawn deep process trees. A shell spawns a child, which spawns more children. Each one inherits everything: your SSH keys, cloud credentials, environment variables, CI/CD configs.
• They make network connections you didn't request. Package installs, API calls, telemetry. Without monitoring, you can't tell a legitimate registry call from a connection to an IP you've never seen.
• They modify files beyond your project. CI/CD configs, Dockerfiles, dependency manifests. A modified .github/workflows/build.yml means code execution on every push for your entire team. That's not a local change — that's supply chain territory.

The jump from "suggest code I review" to "run commands on my machine with my credentials" happened gradually. Most developers didn't notice the line being crossed. The speed felt too good to question and the productivity makes us look past the risks.

Vibe Coders: This Section Is for You

If you're building with AI and you're not deeply reading every line it generates — you're not alone. That's increasingly how software gets made, and there's nothing wrong with the approach itself.

But here's what you need to know: when you prompt an agent and it "just works," a lot happened between your prompt and that working output. Files were read. Commands were executed. Dependencies were pulled. Connections were made. You saw the result — you didn't see the process.

That's not a moral failing. It's an observability problem. And right now, nothing in your stack is solving it.

Your Security Stack Wasn't Built for This

I've talked to security teams who assume their existing tools cover AI agent activity. Some are starting to — but the coverage is retrofitted, not native, and most teams don't have it yet.

EDR has come the furthest. Modern EDR does behavioral analysis, not just signature matching — and it can work. SentinelOne recently caught a supply chain attack executing through Claude Code by detecting behavioral patterns in a spawned Python subprocess. They've also shipped dedicated tooling (OneClaw) for AI agent discovery and observability. But here's the catch: EDR sees the endpoint. It can tell you "a Python process did something suspicious." What it can't tell you is "this was part of an AI coding session that started 40 minutes ago, touched these 12 files, made these 3 network connections, and this is the one that crossed a line." It detects point events. It doesn't reconstruct sessions.

SIEM still has a real data gap. AI coding tools don't emit security-formatted logs — no syslog, no audit events, no native integration with your log pipeline. Tools like OneClaw are starting to bridge this by producing structured telemetry that can be fed into SIEM platforms, but most teams haven't deployed them yet. If you're relying on your SIEM to surface AI agent activity today, you're probably seeing nothing.

Network monitoring has the hardest problem. It sees every connection but can't answer the question that actually matters: did a human or an AI initiate this? A curl to an external API looks identical whether you typed it or an agent spawned it. Without process-level attribution, network monitoring is half-blind to AI activity — and nobody has solved this at the network layer alone.

UEBA is adapting faster than I expected. Exabeam shipped AI agent behavior analytics in late 2025, explicitly modeling agents as separate entities with their own behavioral baselines. That's real progress. But it's currently tied to specific platforms (Google's agent ecosystem), and it doesn't cover the developer-laptop-level activity that AI coding tools generate. Your UEBA might now catch an enterprise AI agent deviating from its baseline in a cloud workflow — but it's not watching what Claude Code does on your MacBook.

The industry is waking up to this problem. That's validating. But the gap that remains is continuous session-level attribution at the kernel level — not "this process looks suspicious" but "this entire chain of actions was initiated by an AI agent, here's the full timeline, and here's where it crossed from normal into anomalous." That's a different architecture than what's being bolted onto existing tools.

So I Started Building

I couldn't unsee this gap. Years of writing production code, years of thinking like an attacker, and now AI agents with full system access and zero monitoring — every part of that experience was telling me the same thing.

So I started building a tool to address exactly this: real-time AI agent observability, from the kernel up. Not bolted onto an existing security product. Purpose-built for the problem.

I'll go deep on the architecture and the product in my next post. For now, I'll just say this: once you can actually see what an AI agent does during a session — every file it touches, every connection it makes, every process it spawns — the gap between what you assumed was happening and what's actually happening is uncomfortable.

The Contractor Test

Here's the thought experiment I keep coming back to.

If a contractor had shell access to every engineer's laptop — could read their SSH keys, access their cloud credentials, modify their CI/CD pipelines, and make outbound connections — with zero visibility into what they were doing? Your CISO would lose sleep. Your compliance team would escalate immediately. There'd be an emergency meeting.

That's exactly what we have today with AI agents. Except nobody's escalating because the access is invisible.

What's Next

In my next post, I'll introduce the tool — what it does, how it works, and what it actually looks like when you have full visibility into AI agent activity on a developer machine.

If this resonated, follow along. This problem is only getting bigger.