GitHub package firewall entered public preview on 20 October 2026 for GitHub Enterprise Cloud customers, including enterprises with data residency. It gives administrators a policy check between npm downloads and the machines requesting them, including coding agents and CI runners. The official announcement says both metadata requests and package downloads pass through the service once an endpoint is configured to use it.
The preview supports npm only and is free during the preview period. GitHub plans metered charging at general availability; the announcement gives neither a tariff nor a general-availability date. Those limits matter when deciding whether to add it to an agent development environment today.
Documentation checked: 21 October 2026.
On this page
Agent environments need an explicit registry route
Enabling enterprise policy alone does not route an agent’s package requests through the firewall. GitHub says the endpoint must use the firewall instead of contacting the upstream registry directly. For a team running several agent environments, the practical question is therefore where each installation happens.
A developer’s local terminal, a disposable agent session and a CI runner should be considered separately when planning that configuration. A useful rollout record would identify the environment, its package registry configuration and the person responsible for it. Otherwise, a team could approve the enterprise policy while leaving the environment that actually installs dependencies outside its intended coverage.
For the broader session lifecycle, see our GitHub Copilot cloud agent guide. The firewall preview addresses a specific dependency-installation step within that workflow.
The documented policy defaults
GitHub’s endpoint documentation lists known-malware blocking, attestation-downgrade blocking and newly introduced install-script checks as enabled by default. Vulnerability blocking starts at critical severity. The default minimum package age is one day.
Administrators can select an age from one to 365 days; zero disables that control. Enterprise administrators and security managers manage the policy. The documentation also describes a custom-role permission for delegated management.
For npm, the documented configuration uses a user-level .npmrc and an enterprise-specific registry URL. Requests require a token belonging to an enterprise member, including a bot account. GitHub says read-only public-repository access is sufficient and recommends keeping the token in a secure location such as a CI secret, never in a committed file.
Plan the exception review before a blocked build
A newly released security fix may itself encounter the age policy. GitHub provides an exception-request link in the npm output or CI log, with package and version details for an administrator to review. Its documentation warns that allowing every version broadens the exception beyond the requested release.
For an agent workflow, that creates a handoff worth deciding in advance: who reviews the request, which package version they are evaluating and how the agent session resumes after the decision. Record the blocked version and the reason for requesting it so a reviewer can assess a specific dependency change.
Treat an installation failure as information to investigate. Repeatedly asking an agent to “fix the build” without preserving the policy error makes it harder for the reviewer to understand what stopped the installation.
