GitHub has put a package firewall into public preview — a checkpoint that inspects every npm package before a coding agent, a CI runner, or a developer workstation is allowed to install it. Why it matters: attackers increasingly steal credentials at install time, before a package’s code ever runs, and autonomous coding agents that install dependencies on their own make that hole bigger.
October 20, 2026
What happened
GitHub announced the package firewall in its Changelog on October 20, 2026. The service sits between endpoints — GitHub Actions runners, coding agents, and CI/CD hosts — and the upstream package repositories they normally pull from directly. Both metadata requests and the actual package downloads flow through the firewall first, where they are evaluated against policy set by enterprise administrators.
How the firewall decides what gets through
Administrators set the controls up front. The options available today, according to GitHub, are a configurable cooldown period for newly published packages, checks against the GitHub Advisory Database for malware or vulnerability alerts, and supply-chain checks such as attestation downgrades. Endpoints then have to be configured to request packages through the firewall instead of pointing straight at the upstream registry.
If a legitimate package is blocked by mistake, the user can request an exception through a workflow GitHub says is similar to its other Advanced Security features.
The limits, stated plainly
This is a preview with real constraints. It currently supports npm packages only — no PyPI, Maven, or other ecosystems yet. It is available only to GitHub Enterprise Cloud customers, including data-resident Enterprise Cloud. The service is free while in public preview; once it reaches general availability, GitHub says it will be charged on metered usage, similar to Actions billing.
Why it matters
The install step has become the attack. GitHub’s own framing is that a growing number of attacks harvest credentials on CI/CD hosts and developer workstations at installation time, without the package’s code ever needing to run. That risk compounds when the thing doing the installing is an AI coding agent working autonomously: an agent will happily fetch whatever a task seems to require, at machine speed, unless something checks the package first. A policy checkpoint that an enterprise controls — cooldowns, advisory checks, attestation checks — is a practical answer to that specific problem, and it is notable that GitHub is building it as a metered platform service rather than a warning in a dashboard. For teams letting agents install dependencies today, the honest takeaway is narrower: if you are on Enterprise Cloud and live in npm, you now have a real control to test; everyone else is still relying on lockfiles, review, and hope.
Frequently asked questions
What is GitHub’s package firewall?
It is a service that sits between your runners, coding agents, and CI hosts and the package registries, inspecting package metadata and downloads against administrator-set policy before installation.
Who can use the package firewall?
GitHub Enterprise Cloud customers, including data-resident Enterprise Cloud, during the public preview. It is free in preview and will be metered, like Actions, at general availability.
Which packages does it cover?
Only npm packages for now, according to GitHub’s announcement.
What happens if a good package is blocked?
The user can request an exception through a workflow similar to other GitHub Advanced Security features.
Sources: GitHub Changelog (GitHub package firewall in public preview, October 20, 2026)
Related reading
- Claude Mythos 5 Tried to Sneak Malware Into a Real GitHub Project — Anthropic Calls It a ‘Serious Failure of Alignment’
- Meet PoeLLM: The Malware Hiding Its Orders in a GitHub Poem — and Mining Crypto on Exposed AI Servers
- OpenAI Published 722 AI-Written Math Papers on GitHub — and Admits Some May Have Errors