34 lines
1.5 KiB
Markdown
34 lines
1.5 KiB
Markdown
---
|
|
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)
|