Launching today
Heron
Wireshark for AI Agents: passive eBPF observability
63 followers
Wireshark for AI Agents: passive eBPF observability
63 followers
Heron is a passive network analyzer that reconstructs what your AI agents are actually doing. Zero SDKs. Zero proxy. Hook eBPF to see TLS-encrypted LLM calls and identify which agent process made them.
Heron
Hey PH! 👋 I'm sharing Heron today on behalf of the engineering team at Netis.
We built Heron because our team got tired of our AI agent loops looking like 200 OK in the logs while the actual agent was stuck replaying the same tool call for 47 seconds straight.
What Heron does: Heron is a passive analyzer that reconstructs what your AI agents are actually doing — from the network traffic itself. No SDK, no proxy, nothing in the request path. It captures LLM traffic (OpenAI, Anthropic, Gemini, vLLM, SGLang, Ollama…), parses the wire protocol, and stitches multi-call interactions into agent turns you can actually debug.
What's new in v0.7.0 (just shipped): 🌌 OpenTelemetry Native — We completely aligned our architecture with OTel standards. Agent turns are now traces, and LLM calls are now spans.
🔥 eBPF capture discoverability — hook SSL_read/SSL_write to see TLS-encrypted agent traffic as plaintext, with process attribution (which agent process made which call). No proxy, no TLS terminator.
📊 We discovered that ~73% of Claude Code's Opus turns in our production capture were hidden security-monitor sidecars — Heron now filters them automatically so you see real agent work, not housekeeping noise.
🧬 One-click SFT trajectory export — turn your production agent traffic into fine-tuning training data without re-running anything.
Built in Rust, ships as a single binary with the React console embedded. Apache-2.0. Would love your feedback!
🦩 Try it: curl -fsSL https://raw.githubusercontent.com/Netis/heron/main/install.sh | sh ⭐ GitHub: https://github.com/Netis/heron
Seeing TLS encrypted LLM calls without proxies sounds impressive I'd to understand the technical boundaries and what information remains inaccessible due to encryption or process isolation.
Heron
@gordon_bennett Totally fair question. The important boundary is: Heron is not doing generic TLS decryption on the network, and it is not a MITM/proxy.
There are two capture surfaces. With pcap/live network capture, Heron can parse full LLM payloads only where the traffic is already plaintext, for example behind a TLS terminator, on an inference host, in local/dev traffic, or from a trusted packet source after termination. If all Heron has is encrypted TLS packets on the wire, it can still see transport-level signals like endpoints, timing, sizes, retries, and flow shape, but not prompts, responses, or tool payloads.
The eBPF path is different: on Linux, Heron can attach to the host-side TLS library boundary, e.g. `SSL_read` / `SSL_write`, where the process already sees plaintext before encryption or after decryption. That enables payload reconstruction and process attribution (`pid`, command, executable) without a proxy, but only for processes/containers/runtimes on hosts you are authorized to instrument and for TLS stacks Heron supports.
What remains inaccessible: traffic from hosts we are not running on, processes isolated from our permissions, payloads that never cross an observed boundary, unsupported TLS/protocol paths, and data the provider never returns to the client. So the design is passive and no-proxy, but it is not magic remote TLS breaking.
If I've got a swarm of agent processes all calling out to the same LLM endpoint from one box, how do you disambiguate which process initiated which call at the eBPF layer, is it PID tracking through the syscall, or are you also correlating with something at the process tree level?
Heron
@ansari_adin Process ID can be distingushed, it is an advantage of ebpf mode. But even there is no ebpf enabled, Heron has the ability to correlate the Agentic turns through signature of the body automagiclly.
What's the performance impact of running Heron alongside a live agent in production?
Heron
@pradyumna6 Great question. Heron is designed to avoid request-path impact: it does not sit between your agent and the model provider, and it does not proxy or mutate requests. It passively observes traffic, so it should not add latency to the live agent path.
That said, it is still a real observer process, so the impact depends on traffic volume, body sizes, capture mode, retention settings, and storage backend. In production we recommend starting with a passive/shadow deployment, tuning retention and body caps, and watching CPU, memory, and disk I/O before expanding coverage.
The main design goal is: if Heron is slow or fails, your agent traffic should keep flowing. Heron may lose observability data under resource pressure, but it should not block the agent itself.
Heron
@pradyumna6 Minimum, in real production environment, we record almost 0% cpu usage in 8xB300 production nodes while heron is working very well.
The eBPF plaintext reconstruction is impressive. The flip side is you now hold a store of decrypted prompts and responses, which in production often carry PII, secrets, or customer data, plus a one click path to turn that into training data. How do you handle access control and redaction on the captured payloads, so the observability layer doesn't quietly become your most sensitive data store?
Passive observability for agents is a serious missing layer. The useful question is not just what the agent answered, but what it touched, fetched, mutated, or failed to see before it answered.