diff --git a/.planning/seeds/SEED-002-ebpf-network-audit.md b/.planning/seeds/SEED-002-ebpf-network-audit.md
new file mode 100644
index 0000000..2509279
--- /dev/null
+++ b/.planning/seeds/SEED-002-ebpf-network-audit.md
@@ -0,0 +1,34 @@
+---
+id: SEED-002
+title: eBPF network session logging
+status: planted
+planted: 2026-04-09
+trigger: observability or auditing milestone
+---
+
+## Idea
+
+Use eBPF to trace network connections made inside the bwrap sandbox during a Claude Code session. Produces a retrospective log of all outbound connections (DNS lookups, HTTP endpoints, WebSocket connections) so the user can audit what the AI agent actually talked to.
+
+## Why
+
+The current sandbox hides secrets and restricts filesystem access, but network activity inside the sandbox is opaque. You can't tell post-hoc whether Claude Code connected to unexpected endpoints, leaked data to third-party MCP servers, or made API calls you didn't expect.
+
+## When This Becomes Relevant
+
+- When claudebox is stable enough that the next concern shifts from "does it work" to "what is it doing"
+- When an observability/auditing phase is planned
+- When MCP server connections inside the sandbox become common (more network surface area)
+
+## Rough Shape
+
+- Attach eBPF probes to the bwrap namespace (connect(), sendto(), dns resolution)
+- Log to a structured file in ~/.claudebox/sessions/{timestamp}.log
+- `claudebox --audit-log` to view the last session's network activity
+- Optionally: real-time display with `claudebox --watch-network`
+
+## Open Questions
+
+- Does bwrap's PID namespace make eBPF attachment straightforward or painful?
+- Should this be a separate tool (`claudebox-audit`) or integrated into the main script?
+- How to handle Nix store paths in the eBPF program (needs nix tooling or prebuilt binary)