AI Engineering

npm Trusted Publishing Finally Fits Real Release Pipelines

npm now supports multiple trusted publisher configurations per package, making OIDC publishing practical for stable, prerelease, and staged release workflows without long-lived tokens.

Publishing packages is one of the places where software engineering still depends on surprisingly fragile operational habits. A build runs in CI, a token sits in a secret store, a workflow turns source into an artifact, and the registry accepts the result because that token has publish authority.

That model works until the token leaks, a workflow grows more complicated than the access model, or maintainers want a human approval step without throwing away automation. npm's September 3, 2026 trusted publishing update is important because it closes a practical gap, not because it introduces a new acronym. Trusted publishing already moved npm toward OpenID Connect. The new change makes it fit the release topologies maintainers actually use.

What Happened

On September 3, 2026, GitHub announced three generally available npm publishing updates: multiple trusted publishing configurations per package, staged package approvals blocked until malware scanning completes, and staged release history in the package versions tab.

The first item is the core engineering change. An npm package can now have more than one trusted publishing configuration. The updated npm documentation says a package can have up to 10 trusted publishers configured at the same time. Each configuration is an independent trust relationship with its own CI provider criteria, such as repository, workflow, and environment. npm authorizes a publish or stage operation when the incoming OIDC token matches any one configured relationship.

Before this change, one package effectively had one trusted publisher slot. That was too narrow for real projects. A package may publish stable releases from one workflow, prereleases from another, canaries from a staging branch, or artifacts from more than one CI provider during a migration. If OIDC could cover only one of those paths, teams had an ugly choice: collapse release logic into one workflow, create brittle workarounds, or keep a long-lived npm token for the paths that did not fit.

The second update connects trusted publishing to npm's newer staged publishing flow. Every trusted publisher configuration can stage by default. Direct npm publish is opt-in per configuration. npm's recommendation is clear: keep configurations stage-only where possible, then require a maintainer to approve the staged version before it becomes available.

The third update tightens the registry's release queue. npm introduced publish-time malware scanning on July 28, 2026. With the September 3 update, a staged package cannot be approved while that scan is still pending. The approval button is disabled until scanning completes, and npmjs.com refreshes the status periodically. Maintainers also get a version-level staged history showing whether a staged package was approved, rejected, or remains staged.

The availability details matter. npm trusted publishing currently supports GitHub Actions on GitHub-hosted runners, GitLab.com shared runners, and CircleCI cloud. The npm docs still say self-hosted runners are not supported. Trusted publishing requires npm CLI 11.5.1 or later and Node 22.14.0 or later. Staged publishing requires npm CLI 11.15.0 or later and Node 22.14.0 or later.

Why It Matters

The security story is straightforward: long-lived publish tokens are bad release infrastructure. They sit in CI secrets, they need rotation, they are difficult to scope to exact workflow intent, and compromise usually remains useful to an attacker until someone notices and revokes the credential.

OIDC-based trusted publishing changes that trust boundary. The registry no longer trusts a static secret copied into CI. It trusts a workload identity asserted by the CI provider for a specific job. GitHub Actions, for example, can mint an OIDC token for a workflow run. That token carries claims about the repository, owner, workflow, ref, environment, run, and related identity fields. npm validates those claims against the configured trusted publisher policy and exchanges the identity for publish authority only for that operation.

That is a better primitive, but primitives only matter when they survive contact with release engineering. The previous single-configuration constraint made trusted publishing look cleaner in diagrams than in monorepos, multi-package repositories, and mature release trains.

Consider a normal JavaScript platform team. It may run latest releases only from protected tags, next releases from a release-candidate branch, nightly canaries from scheduled workflow runs, and emergency patches from a tightly controlled hotfix workflow. Those are not the same risk profile. They should not necessarily share one CI workflow, one environment, or one release approval policy.

Multiple trusted publisher configurations let maintainers model those paths directly instead of smuggling them through one overloaded pipeline. The package can trust release.yml for stable tags, prerelease.yml for candidate builds, and a different provider during CI migration. Each relationship is additive. That means the correct mental model is an allow list of release identities, not a chain of policies where one configuration narrows another.

This also matters for AI engineering teams because more release work is becoming automated by agents. Coding agents can update dependencies, prepare pull requests, generate changelogs, adjust build scripts, and sometimes drive release candidates. Whether a human or an agent authored the change, the package registry should still demand a narrowly scoped publishing identity and, for high-risk packages, proof that a maintainer approved the final promotion.

The best version of agent-assisted release engineering is not an agent with a publish token. It is an agent that can prepare artifacts, trigger a stage-only workflow, and leave a human-maintained promotion step at the registry boundary.

How It Works

Trusted publishing is based on OpenID Connect. The package registry stores a trust policy. A CI job asks its identity provider for an OIDC token. The registry verifies the token signature and claims, checks that the issuer and audience are acceptable, and compares provider-specific claims against the stored policy.

The OpenSSF Trusted Publishers guidance is useful here because it explains why generic OIDC validation is not enough. A registry should not rely only on standard claims such as issuer, subject, and audience. It needs provider-specific claims that identify the repository, owner, workflow, job, or pipeline with enough precision to make the trust relationship meaningful.

npm's implementation exposes that as trusted publisher configuration. For GitHub Actions, maintainers configure the organization or user, repository, workflow filename, optional environment name, and allowed actions. The workflow itself needs id-token: write so GitHub can issue the OIDC token, plus enough read access to check out and build the package. GitLab and CircleCI have their own provider-specific fields because their OIDC claims differ.

The September 3 change turns that one trust relationship into a bounded set. npm's docs now say each package can have up to 10 trusted publishers. Connections are independent, and existing trusted publisher connections cannot be edited after creation; to change a provider or required field, delete the connection and create a new one. That immutability is a good tradeoff. Release identities should be explicit records, not mutable knobs whose meaning quietly changes under old audit trails.

Staged publishing is a separate but complementary release state machine. npm stage publish packs the package and places that version in the registry as staged, not publicly installable. A maintainer can list staged packages, inspect details, download the staged tarball, and then approve or reject it. Approval requires 2FA. The stage operation is designed for automation and does not require an interactive 2FA prompt.

The important split is between build identity and proof of presence. OIDC answers, "Did this artifact come from a trusted workload?" Staged publishing answers, "Did a maintainer intentionally promote this artifact?" Malware scanning answers, "Did the registry's automated checks clear before promotion?" None of those controls replaces the others. The value is in composing them.

There are limits. OIDC authentication applies to npm publish and npm stage publish, not to every npm command. Other stage commands, including approval and rejection, require interactive authentication. Trusted publishing only covers the publish operation; if your build installs private npm dependencies, you still need separate read-only credentials for that install step. npm provenance is generated automatically for public packages published from public repositories through trusted publishing on GitHub Actions or GitLab CI/CD, but not for CircleCI and not for private source repositories.

Example

A practical migration should start by separating release paths before touching npm settings. Most packages have at least two different flows: a low-frequency stable release and a higher-frequency prerelease or canary path. They should be represented as different workload identities.

For a GitHub Actions-based package, the stable workflow might look like this:

name: publish-stable

on:
  push:
    tags:
      - "v*"

permissions:
  contents: read
  id-token: write

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: npm-stable
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: "24"
          registry-url: "https://registry.npmjs.org"
          package-manager-cache: false
      - run: npm ci
      - run: npm test
      - run: npm run build --if-present
      - run: npm stage publish --tag latest

The prerelease workflow should use a different file and environment, for example publish-next.yml with environment: npm-next and npm stage publish --tag next.

In npmjs.com, configure two trusted publishers for the package: one for the stable workflow and one for the prerelease workflow. Keep both stage-only unless you have a specific reason to allow direct publishing. Then set package publishing access to require 2FA and disallow traditional tokens.

That gives you a cleaner release boundary. CI can build and stage artifacts without holding a long-lived npm publish token. The registry accepts only the configured workload identities. A maintainer still has to approve the staged package with 2FA. If malware scanning is pending, approval waits. If the staged tarball looks wrong, the maintainer can reject it before users ever install it.

For a monorepo, repeat the pattern per package, but do not assume every package needs the same 10 entries. The design goal is to make every trusted release identity obvious during review.

My Take

This is the kind of supply-chain change I like: small surface area, large operational effect.

npm did not invent a new release platform. It made an existing security primitive usable in the messy middle where maintainers live. A single trusted publisher per package sounds disciplined until you run real release trains. Then it becomes pressure to consolidate unrelated workflows or keep a token alive. Supporting up to 10 trusted publishers removes that excuse without turning publishing into an unbounded permission sprawl.

The stage-first default is just as important. Direct publishing from CI is convenient, but convenience is not the only requirement at the registry boundary. Popular packages are infrastructure for other people's production systems. A release process that requires a maintainer to approve the exact tarball after CI produces it is slower by design. That slowness is useful when the alternative is immediate global availability after one compromised workflow run.

There is still room for mistakes. Additive configurations mean one permissive trusted publisher can undermine several careful ones. If you configure a broad workflow that can run from unprotected branches, the fact that your stable workflow is locked down does not save you. Treat each trusted publisher as an independent doorway into the package. Review repository rules, tag protection, environment protection, workflow triggers, and who can modify workflow files.

I would also avoid treating provenance as a checkbox. Automatic provenance is valuable when it is available, but it is not universal across providers and repository visibility. The stronger habit is to make release identity explicit, make promotion intentional, and make artifacts inspectable before publication. Provenance then becomes evidence that fits into a larger release control, not the release control itself.

For teams adopting coding agents, the advice is stricter. Do not give agents registry tokens. Give them the ability to prepare changes, run tests, update release notes, and trigger constrained CI paths. Let OIDC identify the workload. Let staged publishing create the pause. Let a maintainer approve the final package. Agent speed belongs before the registry boundary, not inside an always-valid publish secret.

Conclusion

npm's September 3, 2026 trusted publishing update makes OIDC-based package publishing more realistic for serious JavaScript projects. Multiple trusted publishers let one package trust distinct release workflows without falling back to long-lived tokens. Staged publishing keeps automation in the build path while preserving human approval. Malware-scan-aware approval closes a timing gap in the staged queue.

The next step for maintainers is practical: inventory every npm package that still uses an automation token, split release paths into explicit trusted publisher configurations, prefer stage-only permissions, and delete bypass-style publish tokens once the OIDC flow is proven. This is not glamorous work, but it is exactly the kind of release hygiene that keeps package registries usable at scale.