GitHub announced on October 20, 2026 the public preview of its package firewall, a feature that sits between execution environments, whether GitHub Actions runners or coding agents, and upstream package registries. The stated goal is to block attacks that trigger at the moment a dependency is installed, a frequent blind spot for security tools that focus on code already published.
What the firewall actually inspects
The principle is simple: every metadata request or package download now passes through a checkpoint before reaching the build environment. GitHub cross-references each request against the Advisory Database to catch packages known to be malicious or vulnerable, and applies supply-chain checks, including detection of attestation downgrades, a classic signal that a legitimate package has been compromised.
A configurable cooldown period can also be imposed before a newly published version from a maintainer becomes installable, giving time for any reports to surface.
“Currently the package firewall only supports npm packages.”
A deliberately limited scope for now
GitHub does not hide the partial nature of this launch. The npm ecosystem is the only one covered at this stage: neither PyPI, Maven, nor any other registry is included in this preview. The feature is also restricted to GitHub Enterprise Cloud customers, including data residency, which effectively excludes personal accounts and organizations on lower-tier plans.
The explicit mention of “coding agents” among the protected entry points is not incidental: an autonomous agent installing dependencies to test or run code is an attack vector in its own right, since it often operates with less direct human oversight than a developer typing npm install by hand.
The point echoes a broader shift already discussed in Mail Studio’s guide to AI for web developers: more autonomy for coding agents means a larger attack surface to account for.
How the feature gets turned on
Setup follows three steps. Administrators first define an enterprise-level policy, including the cooldown duration and which checks are enabled. Execution endpoints, Actions runners or agents, must then route their package requests through the firewall instead of going straight to the npm registry. A package blocked by mistake can finally be the subject of an exception request, in a flow similar to other GitHub Advanced Security features.
As an illustration, the general principle resembles a client-side registry redirect:
# .npmrc - illustrative example of the routing principle
# (check GitHub's documentation for the exact configuration)
registry=https://npm.pkg-firewall.example/registry/
always-auth=true
GitHub points readers to its dedicated documentation, “Protecting endpoints with package firewall,” for the precise configuration, which goes beyond this simple illustration. Teams that already handle their security watch with a curated set of command-line tools for web development will find a natural addition to track alongside Dependabot.
How it compares to existing protections
| Feature | What it covers | When it steps in |
|---|---|---|
| Dependabot alerts | Known vulnerabilities in dependencies already installed | After installation, ongoing |
| Secret scanning | Credentials and keys exposed in code or packages | At publish time or upon detection |
| Package firewall | Malicious or downgraded packages before install (npm only) | At download time |
A billing model modeled on Actions
The preview is free, but GitHub warns that usage-based billing will apply once the feature reaches general availability, on a model similar to Actions. The company also says it is still scaling the infrastructure behind the feature, with additions planned based on customer demand, which suggests an extension to other registries is not off the table in the medium term.
What to remember
GitHub’s package firewall shifts supply-chain attack detection to the moment of installation itself, rather than relying solely on after-the-fact auditing. The preview remains limited to npm and GitHub Enterprise Cloud, though, which for now makes it more a signal of direction than a broad-based protection.
The most interesting angle in this announcement isn’t malicious-package detection, a space already occupied by several third-party tools, but the explicit mention of coding agents as a surface to protect. As these agents gain more autonomy over installation and build tasks, treating them as identities to secure the same way as a human account is a habit worth adopting, well beyond GitHub’s own ecosystem. — Simon Janvier
To go further: the full announcement is available on GitHub’s changelog.
