Kernel Signals That Matter for AI Agent Session Monitoring

The Lede

A platform security engineer at a mid-size fintech recently told us: "We turned on full syscall logging for our agent hosts and got 40,000 events per second. We turned it off after two hours." The signal-to-noise ratio for generic kernel monitoring is terrible when applied to AI agent sessions. Most of those syscalls are read() and write() on pipes, file descriptors the agent uses for IPC, and memory-mapped I/O — none of which indicate a security event.

The question is not "how do I log all kernel events?" It is "which kernel events actually indicate an agent is doing something it should not?"

The Five Signal Categories

After analyzing thousands of agent sessions across Claude Code, Cursor, Copilot, and custom LLM agents, five categories of kernel events consistently produce actionable security signals.

1. Sensitive file access — security_file_open

The single highest-signal kernel event for agent security. When an agent opens a file outside its expected working directory — particularly credential files, SSH keys, or configuration files with secrets — this is almost always either an attack or a misconfiguration.

High-signal paths:

~/.aws/credentials
~/.ssh/id_rsa, ~/.ssh/id_ed25519
~/.config/gcloud/credentials.db
~/.kube/config
~/.env, .env.local, .env.production
/etc/shadow, /etc/passwd
~/.gnupg/

Hook: LSM hook security_file_open via eBPF. This fires before the file is opened, allowing enforcement (block the open) in addition to detection.

Noise filter: Exclude the agent's declared working directory and standard library paths (/usr/lib, /usr/share, node_modules).

2. Subprocess execution — sched_process_exec

AI agents spawn subprocesses constantly — git, npm, cargo, python. Most are benign. The signal is in which binaries are spawned and what arguments they receive.

High-signal binaries:

curl, wget           — outbound data transfer
base64, xxd          — encoding (exfiltration prep)
dig, nslookup        — DNS exfiltration
nc, ncat, socat      — reverse shells
tar, zip, gzip       — compression (staging)
ssh, scp             — lateral movement
chmod +x             — making downloaded files executable

Hook: sched_process_exec tracepoint. Captures the binary path and full argument vector.

Noise filter: Maintain an allowlist of expected build/dev tools per agent type. Alert on anything outside the list.

3. Outbound network connections — security_socket_connect

Every outbound connection from an agent process should be explainable by the agent's task. Connections to known LLM provider APIs (api.anthropic.com, api.openai.com) are expected. Connections to arbitrary IPs or unknown domains are not.

High-signal patterns:

• Connection to IP addresses (no DNS resolution) — likely hardcoded C2
• Connection to non-standard ports (not 80/443)
• Connection to domains registered within the last 30 days
• Connection volume spike (more than 10 unique destinations in one session)

Hook: LSM hook security_socket_connect. Captures destination address and port before the connection completes.

4. DNS resolution — captured via network hooks

DNS queries reveal intent before the connection happens. An agent resolving exfil.attacker.com is a signal even if the connection is subsequently blocked.

High-signal patterns:

• DNS queries to domains not in the agent's expected dependency list
• Unusually long subdomains (potential DNS exfiltration tunnel)
• Queries to non-standard DNS resolvers (bypassing corporate DNS)

5. SSL/TLS plaintext — SSL uprobes

This is the intent layer. Without it, you see what the agent did but not what it was asked to do. SSL uprobes on SSL_write() and SSL_read() capture the plaintext prompt/response content.

Hook: Uprobes on SSL_write and SSL_read in libssl (OpenSSL, BoringSSL, LibreSSL). Requires identifying the library path at startup.

What to extract:

• The prompt text (what was the agent asked to do?)
• The response text (what did the model instruct the agent to do?)
• Tool call definitions (what capabilities did the agent declare?)

What to Ignore

The following kernel events generate high volume but near-zero signal for agent security:

• read() / write() on pipes and standard file descriptors — IPC noise
• mmap() / munmap() — memory management
• futex() — thread synchronization
• epoll_wait() / poll() — event loop mechanics
• File access within node_modules/, site-packages/, target/ — dependency loading

Logging these events at scale will overwhelm your pipeline and obscure the real signals.

Putting It Together: A Minimal Agent Monitoring Policy

[agent_monitoring]
# High-signal file paths to watch
sensitive_paths = [
  "~/.aws/*", "~/.ssh/*", "~/.kube/*",
  "~/.config/gcloud/*", "~/.gnupg/*",
  "**/.env*", "**/credentials*"
]

# Subprocess binaries that warrant alerts
risky_binaries = [
  "curl", "wget", "base64", "xxd",
  "dig", "nslookup", "nc", "ncat",
  "tar", "zip", "chmod", "ssh", "scp"
]

# Expected outbound destinations (allowlist)
allowed_destinations = [
  "api.anthropic.com", "api.openai.com",
  "api.github.com", "registry.npmjs.org",
  "pypi.org", "crates.io"
]

This policy covers the five signal categories with minimal noise. Everything outside these patterns gets logged but not alerted. Everything matching these patterns gets scored, and high-scoring events trigger the Graph RAG pipeline for LLM-based verdict.

Takeaways

• Full syscall logging is not agent monitoring — it is noise generation
• Five signal categories cover the vast majority of agent attack surface: file access, subprocess exec, network connections, DNS, and SSL plaintext
• The security_file_open LSM hook is the single most valuable kernel event for agent security
• Allowlisting expected behavior is more effective than blocklisting known-bad patterns
• SSL uprobes provide the intent layer that makes all other signals interpretable

---

Ring Zero implements all five signal categories out of the box. Download for free and start monitoring in under 5 minutes.