Your coding agent installs dependencies. Who decides what gets through?

The control moves to installation time

According to GitHub’s 2026 release announcement, the firewall examines both metadata requests and package downloads. Available controls include a cooldown, advisory checks and checks for attestation downgrades. Endpoints must request packages through the firewall. Preview access is free; GitHub says general availability will use metered billing. The announcement provides no future rates, so a production budget cannot yet treat the preview price as permanent.

The GitHub implementation documentation also describes blocking newly introduced installation scripts and requesting exceptions for blocked packages. It explicitly identifies the awkward case: a newly released security fix can be caught by the age policy. Leaders should therefore pair a waiting rule with a patch escalation process. Otherwise, the control can leave the team choosing between delayed remediation and an improvised bypass.

A registry proxy is not the only place to start. pnpm’s current dependency-resolution reference documents minimumReleaseAge for direct and transitive dependencies, with an exception for configuration dependencies pinned using version plus integrity. It also documents strictness and missing-publication-time settings. Those details matter: the built-in age default can fall back to a younger version, whereas explicitly configuring the age enables strict mode by default. Check the installed version and effective configuration before calling an age rule enforced.

Budget for the exception queue

For planning, separate the service charge from the work of operating the policy. Assign time for endpoint configuration, compatibility checks and exception review. Record interrupted agent tasks and human investigation separately from ordinary build failures. A blocked download can be a useful intervention or an avoidable delay; the invoice alone will not tell you which.

Build the pilot report around decisions: which requests were blocked, which were approved, how long approval took, and whether an urgent fix waited. Capture the affected repository, package, version, policy reason and responsible team. Avoid putting tokens or other secrets into the evidence. Use these records to choose staffing and policy changes, rather than presenting every block as an incident prevented.

Keep the coverage map beside that report. Mark agent workspaces, developer machines, CI jobs and internal registry paths as configured, tested or still outside the pilot. GitHub’s documented routing requirement means enabling an enterprise policy does not by itself prove that every endpoint uses it. Treat untested routes as an explicit rollout gap.

Run a pilot that can survive an urgent patch

Start with a representative repository and inventory every place its dependencies are installed. Ask the team to trace a normal download from package manager to registry, including any internal proxy. Record the effective configuration from the environment where the agent actually runs. A policy document and a developer laptop setting are insufficient evidence for a remote workspace.

Choose the waiting period with the service owner and security team. Document why it fits the repository, how a blocked install should stop, and who may approve an exception. Keep an exception specific to the required package version where practical. Require a reason and a review point before granting a broad exclusion. A delivery deadline should have a named decision-maker.

Exercise the workflow using a disposable test environment and benign packages. Confirm that an allowed dependency installs, a disallowed request stops, and the agent reports the block without changing registry settings or weakening policy. Test the urgent-fix route as well. Measure the actual approval delay before expanding coverage; a process that exists only in a runbook has not yet demonstrated that it works.

Finally, agree how to evaluate the pilot. Compare approval effort, blocked-task waiting and coverage against the team’s initial expectations. Investigate recurring exceptions before extending the allowlist. Keep isolation and limited credentials in the design: an age threshold supplies time for discovery, not proof that a package is harmless.

Sources

• GitHub — GitHub package firewall in public preview (October 20, 2026; revised October 21, 2026)
• GitHub Docs — Protecting endpoints with GitHub package firewall (undated documentation; accessed November 3, 2026)
• pnpm — Dependency Resolution Settings (undated documentation; accessed November 3, 2026)