eBPF Kernel Monitoring

Discover and monitor AI agents without modifying any application code. eBPF probes intercept LLM API calls at the kernel level, giving you visibility into agents the team didn't know existed.

Enterprise Plan

eBPF Kernel Monitoring is available on the Enterprise plan. Requires Linux kernel 5.8+ with BTF support.

How It Works

The NodeLoom eBPF agent runs as a daemon on your hosts (standalone binary, Docker sidecar, or Kubernetes DaemonSet). It attaches to the kernel using eBPF uprobes to intercept TLS traffic before encryption, specifically targeting connections to known LLM API endpoints.

Architecture Flow

AI Agent Process (unmodified)
    |
    | SSL_write() to api.openai.com
    v
eBPF uprobes on libssl.so (captures plaintext before encryption)
    |
    v
nodeloom-ebpf-agent (Go daemon, user-space)
    | - Reassembles HTTP request/response
    | - Extracts model, tokens, prompt, completion
    | - Assembles into TelemetryEvent records
    | - Batches and sends to NodeLoom backend
    v
POST /api/sdk/v1/telemetry (same pipeline as SDK)

Because the eBPF agent translates intercepted calls into the same TelemetryEvent schema as the SDK, the entire backend monitoring pipeline works unchanged — anomaly detection, drift alerts, guardrail checks, and LLM evaluation all apply automatically.

Capabilities Comparison

eBPF monitoring complements the SDK — each excels in different areas:

Capability	SDK	eBPF	Notes
Token usage	Full	Full	Parsed from LLM API response JSON
Timing / latency	Good	Better	Kernel-level syscall timing
Agent discovery	Explicit name	Inferred from process	Agent mapping rules bridge the gap
LLM spans	Full	Full	Intercepted HTTP req/resp
Non-LLM spans (tools, retrieval)	Full	None	eBPF only sees outbound HTTP
Pre-send guardrail blocking	Yes	No	eBPF observes after SSL_write
Connection-level blocking	No	Yes	TC/XDP can drop packets by dest IP
Zero instrumentation	No	Yes	Works on unmodified applications
System-wide visibility	No	Yes	Finds ALL agents on a host

Deployment

Requirements

Linux kernel 5.8 or later with BTF (BPF Type Format) support
Capabilities: CAP_BPF, CAP_PERFMON, CAP_SYS_PTRACE
A NodeLoom SDK token for authentication

Kubernetes DaemonSet

The recommended deployment for Kubernetes clusters:

Deploy to Kubernetes

# Create namespace and secret
kubectl create namespace nodeloom
kubectl create secret generic nodeloom-credentials \
  --from-literal=api-key=sdk_your_token_here \
  -n nodeloom

# Apply the DaemonSet
kubectl apply -f https://raw.githubusercontent.com/Nodeloom/nodeloom-ebpf-agent/main/deploy/daemonset.yaml

Docker

Run as Docker container

docker run -d \
  --name nodeloom-ebpf \
  --privileged \
  --pid=host \
  --net=host \
  -v /proc:/proc:ro \
  -v /sys:/sys:ro \
  -e NODELOOM_API_KEY=sdk_your_token_here \
  -e NODELOOM_ENDPOINT=https://app.nodeloom.io \
  ghcr.io/nodeloom/ebpf-agent:latest

Standalone Binary

Download and run

# Download the latest release (Linux x86_64)
curl -L -o nodeloom-ebpf-agent \
  https://github.com/Nodeloom/nodeloom-ebpf-agent/releases/latest/download/nodeloom-ebpf-agent-linux-amd64
chmod +x nodeloom-ebpf-agent

# Run with your SDK token
export NODELOOM_API_KEY=sdk_your_token_here
export NODELOOM_ENDPOINT=https://app.nodeloom.io
sudo ./nodeloom-ebpf-agent

Configuration

Environment Variable	Default	Description
`NODELOOM_API_KEY`	(required)	SDK token for backend authentication
`NODELOOM_ENDPOINT`	`http://localhost:8080`	NodeLoom backend URL
`NODELOOM_CLUSTER_NAME`	(auto-detected)	Cluster or environment name
`NODELOOM_ENABLE_GUARDRAILS`	`true`	Enable local PII and prompt injection detection
`NODELOOM_ENABLE_ENFORCEMENT`	`false`	Enable endpoint blocking and rate limiting
`NODELOOM_ENABLE_PROC_SCAN`	`true`	Enable /proc filesystem scanning for process discovery

Agent Mapping Rules

Since eBPF discovers agents by process name rather than explicit SDK registration, you create mapping rules to associate processes with agent names. Rules are managed in the NodeLoom dashboard under Agent Inventory → eBPF Probes → Mappings.

Match Type	Description	Example Pattern
`PROCESS_NAME`	Match by process executable name	`python.*`
`EXECUTABLE_PATH`	Match by full binary path	`/opt/agents/.*`
`COMMAND_LINE`	Match by full command line	`.openai_agent\\.py.`
`K8S_POD`	Match by Kubernetes pod name	`ai-service-.*`
`K8S_NAMESPACE`	Match by Kubernetes namespace	`ml-production`
`CONTAINER_ID`	Match by container ID prefix	`abc123.*`
`CGROUP`	Match by cgroup path	`.docker.my-agent.*`

Rules are evaluated by priority (highest first). When a process matches a rule, it's automatically registered in the Agent Inventory with the EBPF_PROBE discovery source. Unmapped processes appear in the Discovered Processes tab for manual review.

Local Guardrails

The eBPF agent performs local guardrail checks on intercepted plaintext before it's sent to the backend. This provides early detection without any network round-trip:

PII Detection — SSN, email, credit card regex patterns
Prompt Injection Detection — Common jailbreak and instruction override patterns

Observe-only

eBPF guardrails are observe-only — they detect and report violations but cannot block requests that have already been submitted to SSL_write. For pre-send blocking, use the SDK guardrails.

Enforcement

When enforcement is enabled, the eBPF agent can take action on the network level:

Endpoint Blocking — Block connections to unauthorized LLM endpoints using TC/XDP programs
Rate Limiting — Cap LLM calls per process per time window
Connection Kill — Terminate connections after detecting post-hoc violations

Supported LLM Providers

The eBPF agent monitors connections to these LLM API endpoints by default:

OpenAI (api.openai.com)
Anthropic (api.anthropic.com)
Google Gemini (generativelanguage.googleapis.com)
Cohere (api.cohere.ai)
Mistral (api.mistral.ai)
Together AI (api.together.xyz)
Groq (api.groq.com)
Fireworks AI (api.fireworks.ai)
Perplexity (api.perplexity.ai)

Additional endpoints can be configured via the probe configuration API.

MCP Gateway

Workflows