npm's new trusted-publishing controls let multiple automated workflows prepare package releases with short-lived identities while reserving public promotion for a separate, authenticated decision.
One Package Can Trust Multiple Workflows
GitHub announced multiple trusted publishing configurations for npm on September 3, 2026. Each configuration binds an OIDC identity to its own repository, workflow, and environment criteria.
That removes a common reason to keep a long-lived publish token when stable, prerelease, and staging versions travel through different workflows. The current npm documentation allows up to ten trusted publishers per package and supports GitHub Actions, GitLab CI/CD, and CircleCI cloud runners.
Stage By Default, Publish By Exception
Every trusted publisher can submit a staged package. Direct publishing is an additional, opt-in permission. npm recommends stage-only configurations for its strongest posture, together with disabling traditional token-based publishing.
A staged package is not public. A maintainer must inspect and promote it with two-factor-authenticated approval, and npm now disables that approval until publish-time malware scanning finishes. The versions view also records whether a version was approved, rejected, or remains staged.
Additive Trust Needs An Audit
The configurations do not narrow one another. A publish or stage is authorized when the incoming OIDC token matches any configuration permitted to perform that action, and evaluation order is not guaranteed.
Treat each workflow as an independent release principal. Review its repository ownership, workflow path, environment protection, and allowed action; remove obsolete configurations; and keep direct publishing off unless unattended publication is an explicit policy.
The Zero-Human Company Boundary
Agents can assemble a package, run checks, attach provenance, and place an immutable candidate in staging without receiving the authority to publish it. That separates autonomous preparation from externally visible release.
The control is specific to npm and currently excludes self-hosted runners. It does not prove that a package is safe or that a workflow deserves trust. It makes the release authority narrower, short-lived, and auditable; the operator still owns the approval policy and the contents of every trusted workflow.