Write the Package Install Policy Before AI Coding Agents Install Packages

Should an AI coding agent ever run npm install, npm update, npm audit fix, or pnpm add without a package install policy?

No.

Short answer

Treat package installation as code execution and supply-chain change, not housekeeping. Before an AI coding agent installs or upgrades a package, require a review packet that names the dependency, source, version, reason, exact command, manifest diff, lockfile diff, lifecycle scripts, build-script permissions, release-age exceptions, and dependency review status.

The goal is simple: let the agent propose the package change, but do not let it execute the install until the change has been reviewed.

Why this matters

AI coding agents are good at turning build errors into action.

A test fails. The error says a package is missing. The agent adds it. The lockfile changes. The install command runs. The agent moves on.

That looks productive until you remember what a package install can do.

OWASP's CI/CD dependency-chain abuse guidance warns that a malicious package may be fetched and executed locally when pulled. It also notes that malicious packages may be executed after download through pre-install scripts and similar processes.

npm's lifecycle script documentation describes install-time hooks such as preinstall, install, postinstall, and prepare. That means a package-manager command is not only a dependency graph update. It may run code.

That is the risk. The agent thinks it is fixing a build. The environment receives new code and may execute package-managed scripts before a human has reviewed the package.

Question

What should block an AI coding agent before it installs or upgrades a package?

Goal

The goal is not to ban dependency changes. The goal is to split package selection from package execution.

The agent can recommend a dependency. It can explain why. It can prepare a diff. It can run tests after approval.

It must not silently install, upgrade, or change package-manager policy on its own.

Step 1: Make the agent write a package install packet

Before the agent runs a package-manager command, require a small packet:

1. Package name.
2. Registry or source.
3. Requested version.
4. Current version, if one exists.
5. Reason for the change.
6. Exact command requested.
7. Files expected to change.
8. Lifecycle scripts that may run.
9. Build-script permission status.
10. Release-age policy status.
11. Pull request dependency review status.
12. Rollback or revert plan.

This changes the review from "the agent needs a package" to "the agent wants to run this command, against this source, with these execution and lockfile effects."

That is a better approval object.

Step 2: Treat lockfiles as review evidence

An AI coding agent should not hide package changes inside a general fix commit.

If package.json, package-lock.json, pnpm-lock.yaml, or another manifest or lockfile changes, the pull request needs a dependency review.

GitHub's dependency review documentation says dependency review helps teams understand dependency changes and security impact at every pull request. The Dependency Review Action can report dependency differences in pull requests and add enforcement through GitHub Actions.

That matters because the lockfile is where transitive changes become visible. A one-line manifest change can pull a much wider dependency graph.

The agent should surface that graph. It should not ask reviewers to discover it by accident.

Step 3: Review lifecycle scripts before execution

The dangerous part of an install is not only the new import.

The dangerous part is code that runs during install.

For npm ecosystems, the review should look for lifecycle scripts such as preinstall, install, postinstall, and prepare. The same idea applies in other package managers with different names.

The agent must not approve these scripts by itself.

If the package wants to run install-time code, the default decision should be stop and ask.

Step 4: Separate dependency install from build-script approval

pnpm gives a useful pattern here.

The pnpm approve-builds command approves dependencies for running scripts during installation. Approved dependencies are added to allowBuilds in pnpm-workspace.yaml. Unapproved ones are saved with false.

That is the right shape for agent policy.

Installing a package and allowing that package to run build scripts are different decisions.

An AI coding agent should not edit allowBuilds, ignoredBuiltDependencies, or similar package-manager policy files without explicit approval. Treat those changes like permission changes, not formatting noise.

Step 5: Protect release-age controls

Fresh packages deserve extra skepticism.

pnpm's minimumReleaseAge setting defines how many minutes must pass after a version is published before pnpm will install it. The setting applies to all dependencies, including transitive ones. The fetched pnpm settings card records the pnpm 11 built-in default as 1440 minutes. The strict setting matters too. pnpm documents minimumReleaseAgeStrict as true when minimumReleaseAge is explicitly configured, and false otherwise. When it is false, pnpm can fall back to a version that does not meet the age constraint so installation can still succeed.

That kind of delay is useful because dependency-chain attacks often rely on speed. The attacker wants a malicious or compromised version installed before the ecosystem catches up.

An AI coding agent should not reduce release-age settings, bypass them, or add minimumReleaseAgeExclude exceptions on its own.

A release-age exception is a security decision.

Step 6: Define what the agent must not do

Write the stop rules plainly.

An AI coding agent must not do these things without approval:

• Run npm install, npm update, npm audit fix, pnpm add, pnpm update, or equivalent package-manager commands.
• Modify package.json, package-lock.json, pnpm-lock.yaml, pnpm-workspace.yaml, .npmrc, or package-manager policy files.
• Add or change preinstall, install, postinstall, or prepare scripts.
• Enable dependency build scripts.
• Change allowBuilds, ignoredBuiltDependencies, minimumReleaseAge, minimumReleaseAgeExclude, or equivalent controls.
• Add a dependency from a git URL, newly published version, pre-release version, or unfamiliar registry source.
• Merge a dependency change before dependency review is visible.

This is the package-install version of least privilege.

The agent can reason. It can suggest. It can prepare.

It should not give itself a new supply chain.

Evidence versus opinion

The evidence is straightforward.

OWASP documents dependency-chain abuse and install-time execution risk. npm documents lifecycle scripts. pnpm documents controls for build-script approval and release-age delay. GitHub documents dependency review for pull requests.

The opinion is the field-guide rule:

AI coding agents should treat package installs as approval-gated actions, not routine cleanup.

That may feel slower for small fixes. It is still the right default for write-capable agents.

A package install can change what code enters the workspace, what code runs during install, and what transitive code ships later.

That deserves a real gate.

Free next step

Test your agent.

Give it a missing-package error in a disposable repo and watch what it does.

If it runs the install command before producing a package install packet, your policy is not ready.

Sources

• OWASP CI/CD Security, CICD-SEC-03 Dependency Chain Abuse: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-03-Dependency-Chain-Abuse
• npm Docs, Scripts and lifecycle scripts: https://docs.npmjs.com/cli/v11/using-npm/scripts#life-cycle-scripts
• pnpm, approve-builds: https://pnpm.io/cli/approve-builds
• pnpm settings, minimumReleaseAge and strict mode: https://pnpm.io/settings#minimumreleaseagestrict
• GitHub Docs, About dependency review: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review