You can't secure what you can't see — eBPF for AI agent networks.

An AI agent that calls external APIs, sends data to LLM providers, queries vector databases, and coordinates with other agents over a network is, at its core, a networked process. Security depends on understanding exactly what that process communicates, to whom, and when.

Most AI infrastructure monitors this at the application layer: HTTP request logs, OpenTelemetry traces, middleware interceptors. This works until it doesn't.

An attacker who achieves code execution inside an agent — through prompt injection, a compromised dependency, a model that was fine-tuned to exfiltrate data — controls the application layer. They can suppress logs. They can bypass middleware. They can make the observability tooling report normal operation while quietly opening connections to adversary infrastructure.

The only observability surface that cannot be bypassed by compromised application code is the kernel. And the way to monitor the kernel without performance penalty and without modifying the application is eBPF.

eBPF (Extended Berkeley Packet Filter) is a Linux kernel subsystem that lets you run sandboxed programs at various kernel hook points — network stack, syscall layer, scheduler — without modifying kernel source or loading kernel modules.

CO-RE (Compile Once, Run Everywhere) with BTF (BPF Type Format) makes eBPF programs portable across kernel versions without recompilation.

For AI agent network monitoring, the relevant hook points are:

kprobe/tcp_connect — fires on every TCP connection attempt, before the SYN packet kprobe/tcp_sendmsg — fires on every send syscall, captures destination + byte count tracepoint/net/netif_rx — fires on every received packet at the NIC driver level uprobe on TLS library — captures plaintext before encryption (for your own agents)

This gives you kernel-level evidence of every network connection an agent opens — including connections the application layer was told not to make, or was compromised into making silently.

I built p2pflow to monitor Ethereum P2P network traffic at the kernel level. The Ethereum P2P protocol (devp2p, libp2p) involves hundreds of peer connections, gossip propagation, and protocol-level message passing that is opaque to application-layer monitoring.

The same architectural problem exists in AI agent infrastructure. A multi-agent system using libp2p for agent-to-agent communication has the same opacity problem as an Ethereum node: the P2P layer is below the application, and compromising one agent could let an attacker silently observe or manipulate the mesh.

p2pflow architecture: - Rust userspace program + BPF bytecode compiled with libbpf-rs - Attaches kprobes to tcp_connect, tcp_sendmsg, tcp_recvmsg - Maps peer ID → IP → connection state in BPF hash maps - Streams events to userspace via BPF ring buffer (zero-copy) - Works with Geth without any Geth modification or recompilation

For AI agents, the same pattern: attach to the agent process's network syscalls, stream all connection events to an immutable audit log. No agent can make a network call without a kernel-level record.

The complete picture for verifiable AI agent security combines two layers:

Layer 1 — ZK execution receipts (axiom-engine): prove that a specific computation ran correctly on specific inputs, producing specific outputs. Tamper-evident proof of what the agent computed.

Layer 2 — eBPF network audit (p2pflow pattern): prove that the agent only communicated with authorized endpoints. Kernel-level evidence of every network call.

Together: you can prove what the agent computed AND prove it only communicated with authorized parties while computing it. This is the foundation of a sovereign, auditable AI agent infrastructure.

Neither layer alone is sufficient. A ZK receipt proves correctness of computation but says nothing about data exfiltration via network calls made during inference. eBPF monitoring proves network behavior but says nothing about whether the computation itself was correct. Together they close both gaps.

This is the architecture I am building toward in axiom-engine + p2pflow.