An eBPF egress filter for GitHub Actions that ships with no backend and states what it won't do

Start with the allowlist, because it is not only what you typed into the YAML. Explicit IPv4, IPv6 and CIDR entries go in, then A and AAAA records for configured domains resolved at startup, then DNS responses observed while the job runs ^[5]. A socket filter watches those responses so addresses can be mapped back to domains, and only answers from resolvers listed in /etc/resolv.conf or from loopback are permitted to extend the kernel allowlist ^[6]. The set of destinations sitting in the LPM trie at any moment is therefore a superset of the set a reviewer read ^[17]. That is a workable way to handle CDN-backed hosts without wildcards, and the author rejects wildcards on purpose so every permitted destination stays legible in code review, with unknown YAML keys rejected rather than quietly skipped ^[7].

The second structural detail is when the agent starts. The composite Action downloads the selected release binary, verifies its SHA-256 checksum and launches the agent in the background ^[9], and it cannot see connections made before that setup step ^[10]. Those two facts protect different things. The checksum and the recommended pinning of `uses:` to a full commit SHA cover the agent's own supply chain ^[9]; the pre-setup window is simply uncovered, which is awkward for the compromised-action scenario that motivates egress control in the first place.

Enforcement fails loudly by design. In block mode the kernel returns EPERM for anything outside the trie ^[4], so a missing entry arrives as a broken build rather than a notification. Hence the documented sequence: run real build, test and release paths in audit mode, review what was observed, write the smallest practical allowlist, then switch to block and review later changes as code ^[11]. Audit mode records attempts without stopping them ^[3].

The commercial line is where the comparison bites. According to the author, Harden-Runner's Community tier is intended for public repositories and private-repository support belongs to its paid Enterprise offering ^[13], while field-cage has no account, license key, subscription or repository-visibility check, and offers the same audit, block and reporting behaviour under MIT for public and private repositories alike ^[12]. Both tools can observe outbound connections and block what policy does not permit; the difference is the infrastructure and context wrapped around that control ^[16]. The author names five capabilities his tool does not have ^[18][14], and lists more on the other side: historical network baselines and anomaly detection, maintained indicators for active supply-chain attacks, Windows and macOS audit coverage, enterprise support and governance ^[15]. field-cage is a Linux-runner agent ^[1] at v0.1.0 ^[2], and its logs stay on the runner unless the workflow uploads them, in text, JSON, CSV or job-summary form ^[8].

Nothing in that framing is oversold, which is unusual enough to note. The thing to test before adopting is whether your build's destination list stays short after a few months of dependency churn, because the maintenance of that list is now the whole security control.