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.
Launch Team
Context.devAPI to scrape anything for AI, 20,000+ developers trust us.
Promoted
Langfuse
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
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?
Heron
@angelika_dev You’re absolutely right — this is the core security trade-off of passive evidence.
Heron can reconstruct prompts and responses, which is what makes it useful for debugging, audit, agent-turn reconstruction, and trajectory export. But that also means the Heron store must be treated as highly sensitive infrastructure, not as ordinary logs.
Our intended production model is private/self-hosted deployment inside the same security boundary as the LLM gateway or inference stack. Today that means keeping the API/console private, using retention policies and body caps, and being deliberate about who can access raw payloads or exports.
But that is not the full end-state. For serious production use, this needs redaction before storage, metadata-only capture modes, RBAC for raw payload access, explicit permissions for SFT/trajectory export, and audit logs for viewing/exporting sensitive traces.
The one-click export path is powerful, but it should be governed like access to raw production data. Our goal is for Heron to be a controlled evidence layer — not an ungoverned warehouse of decrypted prompts and customer data.
The eBPF SSL_read/SSL_write uprobe approach to read TLS-encrypted agent traffic as plaintext is the clever part here, since it sidesteps the SDK and proxy tax entirely. Before pointing it at production I'd want to know where the reconstructed plaintext (prompts/completions that can carry secrets or PII) actually lives, does it stay on the local host as part of the single binary, or get shipped off-box anywhere? And since uprobes hook a known libssl, how does it handle agents on statically-linked Go (crypto/tls) or Rust/rustls that never call SSL_read/SSL_write, silent miss or is there a fallback capture path?
Heron
@hi_i_am_mimo Two separate boundaries here.
On data residency: by default, reconstructed calls live in Heron’s configured storage, usually the local embedded DuckDB file next to the Heron deployment. The console is embedded in the single binary, but the captured data is stored in the local/self-managed storage backend, not sent to a Heron cloud service. There is no hosted telemetry path by default.
Data only leaves that box if you configure it to: for example using ClickHouse as the storage backend, forwarding packets from cloud-probe to a central Heron instance, or explicitly exporting SFT/pcap artifacts. We treat those prompts/responses as sensitive production telemetry.
On TLS coverage: the `SSL_read` / `SSL_write` uprobe path is intentionally scoped. It covers OpenSSL/BoringSSL-style clients, including dynamically linked libssl and the statically linked BoringSSL case we built for Bun/Claude Code. It does not automatically cover runtimes that never call those functions, such as Go `crypto/tls` or Rust `rustls`.
For those, Heron will not magically reconstruct plaintext through the SSL uprobe path. The fallback is to capture at a point where traffic is already observable: after TLS termination, at a gateway, from a pcap/live interface with plaintext HTTP, or through cloud-probe. Native Go/Rust TLS support would require separate probes for those TLS stacks, and we should treat that as explicit compatibility work rather than claim universal coverage today.
Really clear, thanks, and the local-DuckDB-by-default residency is exactly the boundary I wanted. On the fallback path: when I capture post-termination at a gateway or from pcap for a Go/rustls agent, do I still get the same per-call request/response correlation and SFT-ready labeling the uprobe path gives, or does losing the syscall boundary mean I cannot reliably tie a reconstructed payload back to a specific process or agent?
Heron
@hi_i_am_mimo Exactly — this is the tradeoff.
The post-termination / pcap / cloud-probe path can still do request/response correlation and SFT-ready reconstruction, as long as Heron can see plaintext HTTP traffic and the provider payload shape is one it understands. That part does not depend on the syscall boundary; it comes from reconstructing the HTTP stream, LLM call, streaming response, tool-call structure, and agent turn.
What you lose without the eBPF path is the native OS process attribution: `pid`, `comm`, and executable path. Packet capture can tell us “this HTTP flow / gateway route / source probe / tenant / service sent this call,” but it cannot magically recover “this exact local process made it” unless that identity exists somewhere in the observable metadata.
So for Go/rustls agents behind a gateway, the best setup is to preserve an agent identity at the capture point: source/probe identity, gateway route, workspace/tenant, Kubernetes pod/service, mTLS identity, or a stable header if your gateway already has one. If multiple agents send indistinguishable HTTP traffic through the same gateway to the same endpoint with no distinguishing metadata, Heron can still reconstruct the calls, but it should not claim reliable per-process attribution.
Short version: same call/turn/SFT reconstruction when plaintext is visible; eBPF adds process attribution. Without eBPF, attribution depends on what identity your capture point exposes.
That header-based identity path is the part I'd lean on, since most of my agents already go through one gateway. Can Heron be configured to key attribution off a custom header the gateway injects (say an x-agent-id) and map it to a named agent in the console, so I get reliable per-agent grouping at the capture point without eBPF? Or is gateway-route/tenant the finest grain it correlates on there?
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.
The one-click SFT trajectory export is the part I didn't see coming. Turning production agent traffic into fine-tuning data without re-running anything is a genuinely useful shortcut, especially if you're running high-volume agent loops and want to improve model behavior from real usage. Does it have any mechanism to strip sensitive content from prompts before export, or is that left to the user?
Heron
@xavier_macia Yes — that is the right caveat.
Today, Heron does not automatically strip PII or secrets before SFT export. The export is explicit, and the resulting JSONL should be treated as a sensitive artifact. If the captured traffic may contain customer data, credentials, or proprietary context, it should go through a redaction/de-identification/review step before being used for training.
The controls we have today are more about exposure reduction: local/self-managed storage, retention policies, stored-body caps, and explicit operator-driven export. First-class redaction policies before export are the right next step, and we are adding that to the roadmap.
If you have a strong view on what the redaction policy should look like — rule-based filters, schema-aware tool-result filtering, allowlists, or review gates — I’d love to capture that in an issue or PR.
Debugging AI agent behavior has been painful for our team because we're always working backward from logs after something breaks. The passive observability angle here is interesting — if it captures what's happening without requiring changes to the agent code, that removes a real barrier to adoption. Does Heron work with cloud-hosted agents or only local/on-prem setups?
Heron
@kudiff Yes, with one important distinction: Heron does not need changes inside the agent code, but it still needs a capture point you control.
If your agents run on your own cloud infrastructure — VMs, Kubernetes nodes, inference hosts, gateways, or behind a TLS terminator — Heron can work there. You can run it on the relevant host, feed it traffic through cloud-probe/pcap, or use the opt-in eBPF mode on the Linux host where the agent process makes the LLM calls.
If by “cloud-hosted” you mean a fully managed third-party agent where you cannot access the host, network path, TLS boundary, or any log/export stream, Heron cannot observe it from the outside.
So the short version is: cloud infra you control, yes; opaque managed SaaS agents, only if they expose a capture or export point.
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.
Heron
@krekeltronics Yes — that is the missing layer we care about.
For agents, the final answer is only one artifact. The more useful debugging trail is what happened before it: model calls, tool calls/results, service paths, timing, loops, failures, and process ownership.
Heron reconstructs that passively from observable LLM/agent traffic. Important boundary: if a local mutation never crosses an observed LLM/tool/API boundary, Heron cannot infer it from the wire alone. But the passive trail still gives teams an independent record of what the agent actually did before it answered.