On 20 October 2026 GitHub announced a package firewall in public preview. Its stated reason: “An increasing number of malware attacks exploit systems at package installation time.” In other words, the danger is not only in the code your developers write, but in the third-party packages their tools pull in while building your product.
How it works
The firewall sits between a company’s machines and the public package registry. Administrators set a policy, and every request is checked against it. GitHub lists three controls today: a cooldown period for newly published packages, checks against GitHub’s malware and vulnerability database, and checks for suspicious supply-chain changes. Coding agents and build servers have to be pointed at the firewall rather than straight at the registry. Mistaken blocks can be challenged through an exception request.
The limits
It is for GitHub Enterprise Cloud customers, it supports npm packages only for now, and it is free during the preview. After general availability GitHub says it will be billed on metered usage. It is a preview, not a finished product.
Why this matters outside engineering
AI coding agents install packages quickly and without much hesitation. That is a large part of why they are fast, and also why a poisoned package can reach a developer machine or a build server before anyone has looked at it. The malware GitHub describes steals credentials, which means access to your cloud accounts, app store accounts and customer data.
So what
If you are commissioning software from a team that uses AI coding tools, ask a plain question: how do you control which packages your tools and agents can install, and who is accountable when one goes wrong? A good supplier will have an answer, whether that is a firewall, a private registry, pinned versions or a review step. A vague answer is a warning sign.
That discipline is part of how we run AI-assisted development at BuildApps. If you want a supplier conversation that starts with this kind of control, start a project.