Frequently asked questions.

eBPF runs in the kernel with negligible overhead, and audit mode is entirely passive - it observes and reports without touching your traffic. Block mode adds a local DNS proxy and firewall rules; the cost is dominated by DNS resolution you were already doing.

A Linux kernel 5.8 or newer (for CO-RE and ring buffers), and either root or the CAP_BPF + CAP_NET_ADMIN capabilities. To build the eBPF objects from source you also need clang/llvm and kernel BTF. This is a non-issue on standard CI runners.

Not today. Egret is built on eBPF, which is Linux-only. macOS and Windows would need entirely different kernel stacks (EndpointSecurity / ETW) and are a separate effort.

Nowhere. No server, no account, no phone-home. Egret writes reports (Markdown, JSON, SARIF) to your runner and appends to the GitHub Actions job summary. The only outbound communication it ever makes is optional - a POST to an ingest URL you configure and control.

Audit mode logs everything and never interrupts a build - use it to learn what your pipeline legitimately talks to. Block mode enforces a default-deny egress policy from a domain allowlist. The intended path is audit → generate a policy from the observed run → block.

Domain-allowlist enforcement has documented residual gaps - encrypted DNS (DoH/DoT), raw-IP connections, IPv6, and fast CDN IP rotation. Egret documents these openly rather than hiding them, blocks raw-IP by default, and has an adversarial reviewer gate on every enforcer change. See How it works for the full list.

No. The dashboard (Egret Nest) is a fully optional, self-hosted Tier-3 add-on for teams running Egret across many repos. No headline feature of the agent ever requires it - the agent is server-agnostic by design.

Yes. The agent, the GitHub Action, and the App integration are open source under Apache-2.0. Optional paid layers (a hosted Nest, support) may exist later but never change the core promise.