Skip to content

eBPF Firewall

The Carapace eBPF firewall provides kernel-level network observability for AI agents. It intercepts SSL/TLS traffic at the kernel level, scans it through the Carapace prompt injection scanner, and can block malicious content before it reaches its destination — all without modifying any running process.

Application (agent)
→ SSL_write() / SSL_read()
→ eBPF uprobe captures plaintext
→ Ring buffer → Node.js consumer
→ Carapace scanner
→ PASS or BLOCK

The firewall attaches uprobes to SSL_write and SSL_read functions in the system’s SSL library. These probes fire whenever any process makes an SSL call, capturing the plaintext content before encryption (on write) and after decryption (on read).

This means the firewall sees exactly what the LLM sees — no MITM proxy, no certificate manipulation, no process injection.

PropertyDetail
Zero process modificationNo LD_PRELOAD, no proxy config, no code changes
Plaintext captureSees content before SSL encryption / after decryption
Ring buffer streamingEvents flow from kernel to userspace via BPF ring buffer
PASS/BLOCK actionsScanner verdict determines if traffic proceeds
All processesCaptures SSL from any process on the system

The eBPF program attaches to two probe points:

  • SSL_write uprobe: Captures outbound plaintext (what the agent sends to the LLM)
  • SSL_read uretprobe: Captures inbound plaintext (what the LLM returns to the agent)

Each captured buffer is pushed to a BPF ring buffer with metadata (PID, timestamp, direction, length).

A Node.js consumer reads from the ring buffer and processes events:

  1. Parse: Extract PID, direction, and plaintext content
  2. Scan: Run Carapace scanner on the content
  3. Decide: PASS (allow) or BLOCK (reject)
  4. Log: Record event for Nectar audit trail
BackendImplementationDependencies
ssl-monitor.jsNode.js with vendored node-ebpf native addonLinux 5.8+, libbpf-dev, clang
ssl-intercept.pyPython with BCC (BPF Compiler Collection)Python 3, bcc-tools

Both produce identical event streams. The Node.js backend integrates directly with the Carapace scanner. The Python backend is useful for standalone monitoring.

  • Linux 5.8+ (BPF ring buffer support)
  • libbpf-dev and clang (BPF program compilation)
  • root or CAP_BPF capability
  • OpenSSL or BoringSSL (probe targets)

The firewall does not work on macOS or Windows (no BPF support). For development on those platforms, use the Carapace proxy or MCP proxy instead.

Terminal window
# Start the firewall
carapace-firewall start
# Stop the firewall
carapace-firewall stop
# Start with proxy mode (intercept + forward)
carapace-firewall proxy
# Run test suite
carapace-firewall test
DirectionContentExample
OutboundAgent → LLM requestsSystem prompts, user messages, tool calls
InboundLLM → Agent responsesCompletions, tool results

Combined with Nectar’s audit trail, this provides complete visibility into what every agent said and what every LLM returned — at the kernel level.

The eBPF firewall feeds events into the Nectar audit layer:

eBPF event → Carapace scan → Nectar record
├── trace_id (correlates with agent session)
├── direction (outbound / inbound)
├── pid (which process)
├── content (plaintext, if audit mode)
├── scan_result (PASS / BLOCK, score, findings)
└── timestamp

This creates an unbreakable chain of evidence: you can prove exactly what every agent sent to every LLM, what came back, and whether any prompt injection was detected.

ApproachProsCons
HTTP proxyEasy setup, portableRequires config per process, adds latency, MITM cert issues
LD_PRELOADNo process config neededFragile, doesn’t work with static linking
eBPFZero config, zero latency, zero modificationLinux only, requires root/CAP_BPF

For production Linux deployments (VPS, containers, bare metal), eBPF is strictly superior. For development and non-Linux platforms, the Carapace proxy is the recommended alternative.