npm's Staged Publishing: A Human Checkpoint for AI-Driven Supply Chains

Finally, a Human in the Loop

The npm registry just rolled out staged publishing, and it's a quiet but meaningful shift in how packages go from a developer's terminal to the rest of the world. Instead of a single npm publish that instantly makes your code available to millions, there's now a checkpoint. A human has to look at it first.

The feature is straightforward: you upload a pre-built tarball to a staging queue, visible both on npmjs.com and in the CLI. Then someone with maintainer rights has to approve it, which triggers a two-factor authentication prompt. Only after that does the package actually appear in the registry. It's a speed bump, but it's a deliberate one.

Why Bother with Staging?

The context here is a string of ugly supply chain attacks. The Shai-Hulud worm, for instance, showed how easy it is to slip malicious code into a package that nobody's watching. Traditional tokens have been deprecated. Security researchers are basically begging developers to adopt this. Adnan Khan, a security researcher, put it bluntly on X: everyone publishing to npm should enable this now. Use OIDC in your CI, stage the release, and only push it live after a human gives the thumbs up. Shai-Hulud? No thanks.

This isn't just about npm, either. It's about a broader trend in software development where AI automation is taking over more of the pipeline. If you're letting a CI system handle your releases—and plenty of teams are—you're trusting that nothing in that chain is compromised. Staged publishing adds a human review step that AI can't easily fake.

How the Staging Workflow Works

The CLI commands are simple enough. You submit a version to the stage queue, list what's waiting, inspect the tarball, then approve or reject it. Here's the basic flow:

npm stage publish
npm stage list
npm stage view <stage-id>
npm stage approve <stage-id>
npm stage reject <stage-id>

That approval step is where the 2FA comes in. It's worth noting that the staging upload itself doesn't require 2FA, so your CI pipeline won't break. The security check is deferred to the human who approves the release. That's a clever design, because it means you can keep your automated workflows unchanged.

Pairing with Trusted Publishing

GitHub recommends combining staged publishing with OIDC-based trusted publishing. The idea is to configure your environment so that the CI can only stage releases, not publish directly. That way, even if an attacker gets control of your CI, they can't just fire off a malicious npm publish. They'd have to get past the human approval gate.

If you're already using trusted publishing, migrating is supposed to be painless. You reuse the same configuration, upgrade your CLI, and swap out the publish command for the stage version. The CLI flags like --tag and --provenance behave exactly the same as with npm publish, so there's no learning curve.

New Flags and Defaults

The update also brings new flags: --allow-file, --allow-remote, and --allow-directory, alongside the existing --allow-git. These can be set to all or none, and you can configure them in either .npmrc or package.json. Starting with npm v12, --allow-git defaults to none, which tightens things up further.

This is part of a broader push to lock down what packages can do during installation. Later this year, npm plans to add an allowScripts field in v12, making install scripts opt-in by default. That's a big deal, because install scripts are a common vector for malicious code.

Mixed Reactions from the Community

Not everyone is thrilled. On Hacker News, a user named weinzierl called staged publishing a band-aid, arguing that it might actually weaken long-term efforts to build more secure infrastructure. That drew a sharp rebuttal: for trusted publishing, this is a major improvement, not a band-aid. It closes a whole class of attacks where an attacker hijacks the CI and publishes a malicious package. Sure, they might find other ways, but this blocks a huge gap.

Others question adoption. One user pointed out that it only helps if maintainers actually use it. Another suggested making it mandatory by default. On Reddit, a commenter said this only slows down the spread of malicious packages, not solve the root problem. That's a fair point—staging doesn't stop a determined attacker who has legitimate access. But it does give maintainers a chance to review what's about to go out.

Competitors Are Catching Up

npm isn't the only one moving in this direction. pnpm 11.3 added a pnpm stage command with the same subcommands, and Yarn has its own equivalent. The release-it tool now supports a "stage": true option. pnpm also delays installing freshly published packages by default, which is another layer of protection.

This is a good sign. When package managers start aligning on security features, it means the industry is taking the problem seriously. And it's not just about npm—it's about the whole ecosystem of AI automation tools that depend on these packages.

What This Means for AI Automation

If you're building AI automation pipelines, you're probably pulling in a ton of npm packages. Every one of those is a potential entry point for an attack. Staged publishing gives you a way to ensure that a human has signed off on each release before it reaches your production environment.

It's not a silver bullet. You still need to review your dependencies, lock versions, and monitor for anomalies. But it's a step toward making the software supply chain more resilient. And in a world where AI is writing more code, having a human checkpoint is more important than ever.

So, if you're publishing packages to npm, consider enabling staged publishing. It's a small change that could save you from a nasty surprise down the road.