GitHub Actions Egress Firewall: The Control That Runs Outside Your Runner

GitHub Actions runners have had a well-understood blind spot since day one: once code is executing inside a runner, it can reach any host on the internet. OIDC tokens, scoped GITHUB_TOKEN permissions, SHA-pinned actions — none of those controls say anything about what the runner is allowed to call out to. That gap is now closing. GitHub’s native egress firewall is in technical preview for all users, and its architecture makes it categorically different from anything the community has built before.

Why Outbound Network Control Has Always Been the Missing Piece

The tj-actions/changed-files compromise in early 2025 is the clearest illustration of the problem. Attackers tampered with version tags on an action used by more than 23,000 repositories. The malicious code dumped runner memory — including workflow secrets — directly into the Actions log. The secrets never left GitHub’s infrastructure in that incident, but the attack vector was there: a runner with unrestricted outbound access and secrets in memory is a single curl command away from exfiltration.

Existing defenses each address a piece of the problem. SHA pinning prevents version-tag swaps from pulling new malicious code. OIDC removes long-lived cloud credentials from workflow context. The workflow lockfile cryptographically pins every action and transitive dependency. What none of these controls touch is the network layer — they cannot stop running code from calling a host it was never supposed to reach.

What the Egress Firewall Actually Does

This is where GitHub’s implementation differs from prior art like StepSecurity’s Harden-Runner or Bullfrog. Both work as workflow actions — they run inside the runner VM and intercept network calls at the process level. An attacker with root access inside the runner can potentially work around an in-process agent.

GitHub’s firewall operates at Layer 7, outside the runner virtual machine entirely, at the network infrastructure level between the runner and the internet. Root access inside the VM does not help an attacker bypass it. The firewall is not a step you add to your workflow. It is infrastructure that runs underneath it.

To support domain-level filtering — not just IP addresses — the firewall terminates TLS at the egress boundary and re-establishes it to the destination. Each workflow run gets a unique ephemeral certificate that is destroyed when the run ends. Traffic is decrypted, inspected against policy, and re-encrypted on the way out, without creating a persistent decryption capability.

Enabling It Is One Line of YAML

The runner label ubuntu-24.04-firewall is all that is needed to opt in to audit mode:

jobs:
  build:
    runs-on: ubuntu-24.04-firewall
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

No action to install. No secrets to configure. No structural changes to your workflow. The runner image is the same Ubuntu 24.04 base your jobs already use, with egress monitoring layered on at the infrastructure level. Enroll via the early access repository.

The trade-off is roughly a 15–20% increase in job runtime for typical workloads — the cost of having the firewall inspect and log every outbound DNS lookup and HTTP/HTTPS request. For most teams running security-critical workflows, that is a reasonable exchange.

Audit Mode Now, Enforcement Later — Start Now Anyway

The current technical preview runs in audit mode only. Every outbound request is logged and surfaced in the workflow summary, but nothing is blocked. Enforcement mode — where you define an allowlist and traffic outside it gets blocked — is listed as future work, with public preview expected within a few months.

This timeline creates a clear strategic case for enrolling today: the traffic logs you collect in audit mode become the allowlist for enforcement mode. Teams that start monitoring now will have real data on every domain, IP range, and HTTP method their workflows touch. When enforcement ships, they flip a switch. Teams that wait will face a cold audit of every dependency and deployment target their CI pipeline reaches — under time pressure.

GitHub’s rollout is deliberate: observe first, so enforcement does not break you. That is the right order of operations, and they are offering you the time to do it properly.

Where the Egress Firewall Fits in the Full Defense Stack

GitHub’s 2026 security roadmap is building a defense-in-depth stack targeting the full supply chain attack chain. The egress firewall is the third leg:

• Workflow lockfile — Pins every action dependency to a cryptographic hash, preventing a compromised version tag from running altered code.
• Scoped secrets — Binds credentials to explicit execution contexts: specific repositories, branches, workflow identities, or trusted reusable workflows.
• Egress firewall — Even if malicious code runs and locates a secret in memory, it cannot transmit it to an external host.

Each control breaks a different link in the attack chain the tj-actions incident demonstrated. The lockfile prevents the malicious code from running. Scoped secrets limit what code can find. The egress firewall contains what it can send. For teams already running the workflow lockfile, adding the firewall runner label closes the exfiltration gap the lockfile alone leaves open.

The Bottom Line

The GitHub Actions native egress firewall is not a complete solution yet — enforcement mode is still incoming. But audit mode is available right now, enrollment is one YAML label change, and the logs you collect become the foundation for full enforcement when it arrives. The architecture is the right approach: running outside the VM, immutable to root-level compromise, TLS inspection without persistent decryption. Enroll your critical workflows today and start building the allowlist you will need when enforcement lands.