How GitHub Package Firewall Is Changing DevOps Security: Securing npm Installs for AI Agents and CI

\n

The Moment AI Installs a Package, a DevOps Attack Begins

An AI coding agent writes code, and a CI runner starts a build. On the surface, it’s an ordinary automation workflow. But a single command executed along the way can become the starting point of an attack.

npm install

The problem is that this command doesn’t simply download library files. npm packages can run scripts such as preinstall, install, and postinstall during installation. If a malicious package—or a legitimate package that has been compromised—hides malicious commands in one of these scripts, attack code can run on a CI environment or developer machine before the code review is even complete.

For example, a malicious postinstall script may attempt to:

• Steal API keys, tokens, and cloud credentials from the CI runner’s environment variables
• Collect GitHub Actions’ GITHUB_TOKEN or deployment secrets
• Search for SSH keys, npm authentication tokens, and registry configuration files
• Send sensitive information to an external server
• Download and run additional malicious tools
• Tamper with build artifacts or deployment packages

This can happen even faster than the problem of “vulnerable code entering the repository.” If a script runs as soon as a package is installed, the CI environment may already be compromised before anyone reviews the Pull Request or a security tool raises an alert.

How DevOps Automation Has Expanded the Package Supply Chain Attack Surface

In the past, developers often selected and installed packages themselves. Now, in DevOps environments, dependencies are installed by automated actors rather than people.

• CI/CD runners execute npm ci with every build.
• AI coding agents search for and add the libraries they need.
• Docker build steps install packages inside containers.
• Test environments and deployment pipelines repeatedly download dependencies.
• Internal automation tools sync the latest package versions.

Automation speeds up development, but it also accelerates the spread of package supply chain attacks. Imagine an attacker registering a package with a name similar to a popular package, or taking over an account for a poorly maintained package and publishing a malicious version. An automated environment may quickly install that package and run its installation scripts.

AI Agent or CI Runner
        ↓
   npm install / npm ci
        ↓
Package download and installation script execution
        ↓
Access to environment variables, tokens, and files
        ↓
Data exfiltration or build environment takeover

CI runners are especially valuable targets for attackers. To build and deploy software, they often hold access to source code, package registry tokens, cloud credentials, deployment keys, and other privileges. A single small package can become the starting point for an attack on the entire deployment chain.

Why Code Review Alone Is Not Enough

Typical security processes focus on source code changes. When a Pull Request is created, developers review the changes, static analysis tools such as CodeQL look for vulnerabilities, and Dependabot alerts teams to known vulnerable dependencies.

But package installation attacks happen at a different point in time.

| Security control | Primary focus | Limitation | |---|---|---| | Code review | Application code changes | Difficult to inspect every installation script inside every package | | Static analysis | Code in the repository | Package behavior during download from a registry requires separate controls | | Dependabot | Known vulnerable dependencies | Does not block installation requests in real time | | Runtime security | Services while running | May detect a compromise in the CI environment only after it has happened |

A malicious package may not appear directly in the application code. The dependency added to package.json may look legitimate, while the actual risk is hidden in the installation script it runs after being downloaded.

Modern DevOps security, therefore, cannot stop at asking, “Is the code safe?” It must also ask:

Which packages are our AI agents and CI runners installing, and under what policies?

Why You Need to Control the Moment of Installation

The key to package supply chain security is detecting risks earlier. Finding a vulnerability after installation may be too late. In automated build environments, installation, execution, testing, and deployment can happen one after another in a very short time.

That’s why policy controls at the package installation request stage are essential. At a minimum, organizations should be able to evaluate the following before installation:

• Does the package or version have any known malware or vulnerability advisories?
• Is a newly published version being used unusually soon after release?
• Has its provenance or attestation level decreased compared with the previous version?
• Are AI agents or CI runners accessing unapproved registries directly?
• If an emergency exception is needed, who approves it, and what records are kept?

An installation-time security gate such as GitHub Package Firewall targets exactly this point. Before a package reaches a CI runner or AI agent, it evaluates metadata, download requests, and supply chain trust signals against policy—and blocks risky installations.

Ultimately, the shift is simple: in a DevOps environment, npm install is no longer a harmless setup step. It is a crossing of a security boundary—a process that lets external software enter an organization’s build environment and, in some cases, execute code.

How Do DevOps Package Requests Pass Through the Security Gate?

Enabling Package Firewall does not automatically protect every CI/CD environment. If a runner or AI coding agent connects directly to the npm registry, Firewall policies do not apply at all.

The key is not simply turning on a security feature—it’s forcing package installation requests through Package Firewall. In a DevOps environment, every request, from package metadata lookups to actual file downloads, must pass through the security gate.

Package Installation Takes More Than One Request

When you run npm install or npm ci, npm generally makes two kinds of requests:

1. Metadata lookups

   • Check package names and available versions
   • Inspect the dependency tree
   • Retrieve release and integrity information

2. Package file downloads

   • Download the tarball for the selected version
   • Prepare to run installation scripts
   • Install dependencies based on the lockfile

Package Firewall needs to sit between these two steps.

CI Runner / Developer Environment / AI Agent
                │
                ▼
     npm metadata and download requests
                │
                ▼
        GitHub Package Firewall
        ├─ Evaluate package policies
        ├─ Check against the Advisory Database
        ├─ Check cooldown periods
        ├─ Inspect for attestation downgrades
        └─ Allow or block
                │
                ▼
      npm Registry or Internal Registry

In other words, Firewall is not a scanner that reports results after installation is complete. It’s a dependency admission control layer that evaluates requests before packages are fetched—and blocks the download itself if a package is deemed risky.

Allow Direct Access, and the Security Gate Can Be Bypassed

One of the most common operational mistakes is configuring Firewall on CI runners while still allowing them to communicate directly with external registries such as registry.npmjs.org at the network level.

For example, even if a runner’s .npmrc points to the Firewall route, a build script or container configuration could specify a different registry and bypass the policy.

# Even if the policy-routed setting is in place
npm config set registry "Firewall-routed Registry URL"

# A build script or separate configuration can still bypass it
npm install some-package --registry="https://registry.npmjs.org/"

That’s why DevOps teams shouldn’t assume that changing configuration alone is enough. They need to apply both of the following:

• Standardize npm registry settings on the Firewall route
• Block direct registry access through outbound network policies for runners and agents

These two controls work together to reduce bypasses caused by configuration errors, ad hoc commands, or malicious scripts.

Components That Can Change the Actual Request Route

When adopting Package Firewall, don’t check just one configuration file. Review every execution point that could generate package requests.

| Area to check | What to verify | |---|---| | GitHub-hosted or self-hosted runners | Confirm that the npm registry is configured to use the Firewall route | | AI coding agent environments | Confirm that agents cannot connect directly to external registries | | Docker builds | Check for npm install and .npmrc copies inside the Dockerfile | | Monorepos | Make sure individual projects’ .npmrc files don’t specify a different registry | | Private packages | Confirm that scope-specific registry settings don’t bypass Firewall | | Internal proxies and caches | Validate the routing path between existing caches or artifact proxies and Firewall | | Local developer environments | Distinguish where warning-focused policies apply from where blocking policies are enforced |

Container builds are especially easy to overlook. The host runner may have the correct npm settings, but if a Docker build uses a separate .npmrc, npm ci inside the container could take a different route.

FROM node:22

WORKDIR /app
COPY package*.json ./

# npm requests in this step must also use the Firewall route.
RUN npm ci

COPY . .
RUN npm run build

That’s why Dockerfiles, build secrets, .npmrc files, and registry settings in environment variables should all be reviewed together.

What Does Firewall Use to Allow or Block Requests?

Once a request passes through Firewall, the package and version are evaluated according to the organization’s policies. The central question is: “Is this package safe to install?”—answered right before installation.

Key evaluation criteria include:

• Cooldown period
  Prevents newly published package versions from being installed for a set period. This can slow the initial spread of an attack if an attacker takes over a legitimate package account and publishes a malicious version.

• GitHub Advisory Database checks
  Compares packages against known malware or vulnerability advisories to block risky packages or versions.

• Attestation downgrade checks
  Detects releases with weaker provenance or attestation than previous versions. This policy helps flag versions that look like routine updates but have weaker supply chain trust signals.

• Checks on both metadata and download requests
  Policy coverage extends beyond controlling package names to include the actual version being installed and the download flow.

This approach is particularly valuable for mitigating risks from scripts that can run during installation, such as preinstall, install, and postinstall. Malicious packages don’t have to wait until the application runs: the moment dependencies are installed, they can target the CI runner’s environment variables, tokens, SSH keys, and cloud credentials.

Once Policies Are in Place, Operations Matter More Than Blocking

Strict policies can also slow down development. Applying a long cooldown across the board can delay legitimate builds, especially for teams that frequently adopt new versions. On the other hand, if exceptions are too easy to grant, Firewall becomes little more than a proxy.

For effective DevOps operations, it’s best to vary policy strictness by environment.

| Environment | Recommended approach | |---|---| | Production CI | Enforce advisory, cooldown, and attestation policies | | Staging | Maintain production-level policies, with approval-based exceptions | | Local developer environments | Prioritize warnings and visibility over blocking | | AI agent environments | Require the Firewall route and block direct registry access | | Emergency patches | Apply break-glass exceptions limited by time, repository, and package |

Blocked events shouldn’t end up as simple failure logs. Keep audit logs showing which runner requested which package and version, and which policy triggered the block, then review them regularly. Packages or teams that repeatedly need exceptions may point to issues in policy design, internal mirrors, or dependency management practices.

Ultimately, Package Firewall’s first line of defense isn’t its detection rules. It’s designing request routes so every package request must pass through Firewall. Only when that route is enforced can CI runners and AI agents become environments that install only trusted dependencies.

DevOps Security That Stops Threats at a Different Point Than Dependabot and CodeQL

Tools that identify vulnerable packages and tools that prevent those packages from being installed serve different purposes. The key distinction of GitHub Package Firewall is that it moves security checks one step earlier.

Dependabot and CodeQL already play important roles in DevOps security. However, rather than directly controlling package installation requests, both tools primarily help development teams respond by identifying risks in code and dependencies.

| Tool | Primary role | When security checks occur | Default outcome | |---|---|---|---| | Dependabot | Detects vulnerable or outdated dependencies | After dependency analysis | Alert, update PR | | CodeQL · AI Scan | Analyzes source code and PR changes | During development and at the PR stage | Vulnerability findings, fix suggestions | | Package Firewall | Controls package installation requests | Just before a registry request or download | Allow or block |

Dependabot Alerts You; Package Firewall Stops the Install

Dependabot analyzes dependency information in files such as package-lock.json and package.json to identify versions that contain known vulnerabilities. It then generates alerts or proposes a Pull Request to update to a safe version.

This approach is extremely useful, but responding can take time. Even after an alert is generated, someone still needs to review it, check the PR, run tests, and merge the changes before the risk is actually reduced.

Package Firewall, by contrast, operates in the following flow:

npm install request from a CI runner or AI agent
                ↓
      Package Firewall policy evaluation
                ↓
No risk: allow download / Risk detected: block installation

In other words, if a package has a known malware advisory or poses a risk under policy, it can be blocked before a CI runner or AI coding agent downloads it. Rather than a post-incident measure for addressing vulnerabilities, this is closer to admission control that prevents risky dependencies from entering the environment in the first place.

CodeQL Finds Problems in Code; Firewall Controls the Packages Coming In

CodeQL and AI Scan excel at finding vulnerabilities in application code. For example, they can detect risks stemming from how code is written—such as SQL injection, path traversal, authentication bypasses, and secret exposure—at the Pull Request stage.

But safe code doesn’t necessarily mean a safe build environment. Consider the following:

npm install some-package

When this command runs, the npm package’s preinstall, install, and postinstall scripts may run as well. At that point, a malicious package may try to steal environment variables, authentication tokens, SSH keys, cloud credentials, and more. The impact can be greater in environments with broadly privileged self-hosted runners or automated AI agents.

CodeQL analyzes code changes in the application repository, while Package Firewall evaluates external artifacts coming from a package registry against policy. They are not competing tools; they complement each other by protecting different points of attack.

Write code
  ↓
Analyze code changes with CodeQL · AI Scan
  ↓
Validate package installation requests with Package Firewall
  ↓
CI build and tests
  ↓
Deployment and runtime monitoring

DevOps Security Expands from “Detection” to “Blocking What Gets In”

Traditional DevOps security has focused on finding and fixing vulnerabilities quickly. Package Firewall adds another layer of control: preventing risky external software from entering automated environments in the first place.

It is particularly effective in environments such as:

• CI/CD runners that install dependencies without human review
• AI coding agents that can search for and install packages
• Organizations where multiple teams share runners and registries
• Environments where npm supply chain attacks could affect production builds

In short, Dependabot tells you what to update, CodeQL finds vulnerabilities in the code you write, and Package Firewall blocks risky packages at the moment of installation. In modern DevOps environments, it’s more realistic to deploy these capabilities at different points of defense than to try to replace them all with a single tool.

How to Operate DevOps with CI and AI Agents Under the Same Policies

Is it enough to give an AI agent permission to write code? No. The moment an agent searches for packages and runs npm install, your organization also needs to control which external software AI brings into your internal environment.

CI runners and AI agents have one thing in common: both install dependencies without immediate human review. Protecting only one leaves attackers free to choose the less restricted path. DevOps security policies should therefore be designed not around whether the actor is human or AI, but around verifying every package installation request against the same standards.

Why You Need to Control the Installation Path, Not Just Installation Permissions

An AI agent may look for libraries it needs, consult example code, and add dependencies as it works. This can introduce risks such as:

• Typosquatting: installing malicious packages with names similar to legitimate ones
• Immediately pulling a newly published malicious version
• Compromising CI or agent environments through preinstall or postinstall scripts
• Downgrading to package versions with weaker provenance guarantees
• Packages installed by an agent being added to the lockfile and spreading to future builds

The key point is that risk can arise even when an AI agent is not acting maliciously. To achieve its assigned goal quickly, an agent may choose packages that are highly visible or versions that are the latest available. But being the latest, ranking high in search results, or having a plausible name does not make a package safe.

That is why an installation-time control layer such as GitHub Package Firewall is needed for both CI and AI agents.

AI Agent ─┐
          ├─ Package Firewall ─ Policy evaluation ─ Allow or block
CI Runner ─┘

The key is to prevent both execution environments from connecting directly to the npm registry and require all metadata lookups and package downloads to go through the Firewall.

Same Policies, Different Levels of Strictness by Environment

Applying the same policies to CI and AI agents does not mean configuring every exception and restriction identically. Establish a consistent baseline, then adjust approval processes and enforcement levels to match the risk of each environment.

| Environment | Recommended DevOps policy | |---|---| | Production CI | Enforce cooldowns, advisory checks, and attestation downgrade prevention | | Release build | Apply the same policies as production CI, or stricter ones | | AI coding agent | Block direct registry access, require Firewall routing, and limit exceptions to approved cases | | Staging CI | Use production policies by default, with a limited exception process | | Developer local environment | Start with warnings and visibility, but enforce blocking on release paths |

AI agents may explore packages and repeatedly attempt installations, so the following principles are especially effective:

1. Do not give agents direct access to the registry.
2. Check agent installation requests against the same Firewall policies as CI.
3. Prevent blocked packages from being retried until a person has reviewed them.
4. Strictly scope exceptions by package name, version, duration, and repository.
5. Include changes an agent makes to package.json and the lockfile in Pull Request reviews.

This approach preserves AI’s productivity while reducing the risk of agents becoming a new route around supply-chain controls.

The Key to Implementation Is Blocking Bypass Paths

Even with policies in place, protection is limited if runners or agents can connect directly to the public npm registry. Adopting a Package Firewall is not simply a matter of enabling a feature; it is a DevOps initiative that requires coordinated changes to networking, environment configuration, and auditing.

In practice, review the following together:

• npm registry settings for GitHub Actions and self-hosted runners
• .npmrc configuration in AI agent containers or workspaces
• npm ci paths executed inside Docker builds
• How internal npm proxies, caches, and private registries connect to the Firewall
• Egress policies that block direct connections to external registries
• Audit logs for blocked events, exception approvals, and bypass attempts
• How packages installed from existing caches are verified

For example, if a self-hosted runner has unrestricted access to the public internet, someone could change .npmrc or specify a registry URL directly in a command to bypass the Firewall. So don’t stop at changing registry settings—also restrict outbound traffic to approved endpoints.

# Conceptual example: configure npm to use the organization’s approved route
npm config set registry "https://<organization-firewall-endpoint>/npm/"

This setting is only a starting point. In production, standardize the same installation path across CI images, container builds, agent sandboxes, and developer tools.

Handle Exceptions Quickly, but Don’t Open the Floodgates

Exceptions are sometimes unavoidable when a new package or urgent patch is needed. But “the build is urgent, so let’s disable the cooldown for everything” defeats the purpose of supply-chain defense.

A safe exception policy keeps the scope as narrow as possible:

• Allow only a specific package and version
• Apply only to a specific repository or workflow
• Set a clear expiration time
• Limit approval to the security team or designated repository owner
• Record the reason for the exception and the installation result in audit logs
• Automatically return to the default policy when the exception expires

In AI agent environments, it’s best not to give agents the authority to grant their own exceptions. The agent should report the block and the package details in a Pull Request, issue, or approval request, with a person or separate approval workflow making the final decision.

The Goal Is Not to Stop AI, but to Make Automation Safe

The value of a Package Firewall is not in restricting AI agents. It lies in creating boundaries that let agents explore and install packages more safely.

Current approach
AI agent or CI runner → Direct access to npm registry → Discover the problem after installation

Recommended approach
AI agent or CI runner → Policy validation → Install only approved packages → Proceed with the build

Ultimately, the assets a DevOps organization needs to manage are not limited to code. The packages brought in by CI runners and AI agents, their provenance and risk, and the way exceptions are used must all be covered by operational policy. When CI and AI agents operate under the same policies, automation doesn’t just get faster—it becomes more predictable and controllable, too.

Beyond the Limits of a DevOps Preview: How Far Should You Go?

Strong security policies can block dangerous packages, but they can also delay legitimate new releases. What’s more, GitHub Package Firewall is currently a public preview focused on npm. So is there any reason to introduce a feature that isn’t yet fully mature into your DevOps environment?

The answer isn’t a mandatory rollout across the entire organization, but rather a limited pilot targeting high-risk paths.

The value of Package Firewall goes beyond simply detecting vulnerable packages. It applies policies before CI runners and AI coding agents install dependencies, preventing risky packages from reaching the build environment in the first place. This is especially important when considering attacks that execute scripts during installation, such as preinstall and postinstall: relying only on scans performed after installation may be too late.

That said, applying the same policy to every repository right away is hard to recommend. A cooldown policy that holds new package versions for a period of time can slow the spread of supply chain attacks, but it can also delay urgent bug fixes and security patches. Strict provenance or attestation requirements may also block legitimate open-source packages whose verification systems have not yet matured.

A risk-based rollout is therefore the more practical approach.

| Environment | Recommended rollout | Operating principle | |---|---|---| | Production CI/CD | Prioritize rollout | Apply advisory blocking, cooldowns, and attestation downgrade blocking | | AI coding agents | Prioritize rollout | Prohibit direct registry access and require traffic to go through the Firewall | | Staging environments | Roll out in stages | Validate the exception approval process against production policies | | Developers’ local environments | Focus on observation | Initially prioritize warnings and log collection | | Experimental repositories | Apply selectively | Prioritize development speed while collecting policy effectiveness and false-positive data |

The key point is that simply turning on the Firewall does not complete your protection. If self-hosted runners, Docker builds, AI agent environments, or internal cache servers can connect directly to the npm registry, the policy can easily be bypassed. Alongside changing the npm registry endpoint, DevOps teams should also review their outbound network policies.

For example, a production environment should use a setup like this:

CI Runner / AI Agent
        ↓
GitHub Package Firewall
        ↓
Allowed npm Registry or Internal Registry

By contrast, if any of the following paths remain, the effectiveness of your controls will be significantly reduced:

CI Runner → Direct connection to the public npm registry
Docker build → External registry access using separate npm settings
AI Agent → Direct package installation using a personal token

During a pilot, measure the operational impact as well as the number of blocked requests.

• The percentage of legitimate packages that are blocked
• Average time required to approve exceptions
• Build delays in npm ci and npm install
• Compatibility with internal private packages and caches
• Behavior of monorepo and lockfile-based builds
• Whether bypass paths occur
• Patterns of dependency requests blocked or allowed for AI agents

Exception policies are particularly important because they determine the level of security. If exceptions such as “the build is urgent, so allow it for now” become routine, Package Firewall will be reduced to a simple proxy. Exceptions should be clearly limited by duration, repository, package version, and approver, and every approval should be recorded in an audit log. Even when an urgent security patch is needed, it is better to use a temporary break-glass process and ensure that a post-incident review takes place.

The limitation that only npm is currently supported is also clear. Organizations that use Python, Java, .NET, Go, container images, or Terraform modules cannot protect their entire software supply chain with Package Firewall alone. For other ecosystems, they should also use controls such as private registries, artifact proxies, checksum verification, image signing, and admission policies.

Even so, for organizations with many npm-based services that use GitHub Enterprise Cloud, the current preview is well worth experimenting with. The best place to start is with production repositories that have extensive deployment permissions and external dependencies, as well as AI agent environments that automate dependency installation.

Ultimately, Package Firewall’s success depends less on the feature’s level of maturity than on how it is operated. If you can route all package requests through the Firewall, minimize exceptions, and continuously measure the impact of policies on development speed, you can advance DevOps supply chain security—even while the feature is still in preview.