GitHub Package Firewall Screens npm Installs
GitHub's new package firewall inspects npm downloads before they reach a runner or a coding agent. Here is what it covers, and the four things you can do without it.
GitHub put a package firewall into public preview on 20 October 2026. It sits between the machines that install your dependencies and the upstream registry, inspects metadata requests and downloads for signs of malicious activity, and blocks what fails policy. Two limits matter before you get excited: it covers npm packages only, and it is available to GitHub Enterprise Cloud customers, including data-resident Enterprise Cloud. If you build on a free or Team plan, this is not yet yours to turn on.
The announcement lands in the GitHub changelog for 20 October, filed as a release rather than a quiet improvement. It is free during the preview, and GitHub says that after general availability it will be billed on metered usage, similar to Actions billing. No pricing figures were published.
What sits where
The firewall is a proxy with an opinion. GitHub describes it as sitting between endpoints, naming Actions runners and coding agents specifically, and the upstream package repositories those endpoints would otherwise talk to directly. Nothing routes through it by default. An administrator sets enterprise policy, and then each endpoint has to be configured to send its requests to the firewall instead of straight to the registry.
That second step is the one people will forget. A policy with no traffic through it blocks nothing, and a build that still resolves registry.npmjs.org on its own is exactly as exposed as it was last week.
The three checks worth knowing
GitHub names three kinds of policy control, and they catch different things.
Control | What it actually looks at |
|---|---|
Cooldown period | How long a version has existed. A package published minutes ago is held back until it has aged past your configured window. |
Advisory Database checks | Whether GitHub has a malware or vulnerability alert on file for that package and version. |
Supply-chain checks | Signals such as attestation downgrades, where a package that previously shipped with provenance suddenly does not. |
The cooldown is the most interesting of the three, because it is the only one that works without knowing anything about the package. Most npm malware is caught within hours of publication, which means the attack window is short and a delay of a day or two covers it. The Advisory Database check, by contrast, can only block what somebody has already reported.
The attestation downgrade signal is the subtle one. A package that used to publish build provenance and then stops has either changed its release process or had its publishing credentials taken. Both are worth a human look before the bytes reach a runner.
False positives have a path
Blocking installs breaks builds, so GitHub included an exception workflow: if a package is blocked in error, users can request an exception through a flow similar to other GitHub Advanced Security features. That matters more than it sounds. A security control with no release valve gets switched off the first Friday it stops a deploy.
Why this shows up now
The timing is not a coincidence. Coding agents install dependencies as a side effect of doing what you asked. You say "add image uploads" and something runs npm install with a package list you did not choose and will probably never read. We wrote about what npm install actually does to your project for exactly that reason, and about the related failure where an AI model invents a package name that does not exist, which an attacker can then register.
GitHub naming coding agents as a protected endpoint class is the notable part of this release. The threat model has shifted from a developer typing an install command to an autonomous process doing it unattended, at a volume no reviewer reads.
If you are not on Enterprise Cloud
Most people reading this are not, so here is what is available without it.
Set a cooldown of your own. npm supports installing with a time constraint through
--before, and some registries and proxies expose a minimum-age policy. A 48-hour floor on new versions removes the window most npm malware lives in.Pin exactly and commit the lock file. A lock file is the record of which versions you actually resolved, and reading its diff is how you notice a change nobody asked for. That is covered in why AI agents keep changing your lockfile.
Turn on Dependabot alerts, which are free on public and private repositories and read the same Advisory Database the firewall checks.
Give the agent a smaller blast radius. A container that cannot reach your production credentials turns a malicious postinstall script into a wasted afternoon rather than an incident. The same reasoning applies to AI coding tool plugins that update behind you.
None of those is as good as a proxy that inspects every download. All four are available today, cost nothing, and work on whatever plan you are on. The architectural point in GitHub's release is portable even where the product is not: put something between your build and the registry, and make new versions wait.
Keeping track of changes like this is its own small discipline, and we wrote up a method in how to keep up with AI news without losing days.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
