What changed on September 3
GitHub's September 3, 2026 announcement makes multiple npm trusted publisher configurations generally available. Each configuration has independent repository, workflow and environment criteria. Matching any one can authorize an operation; another configuration does not narrow that permission, and match order is unspecified. New configurations default to staging, with direct publishing an additional choice. The update also prevents approval while a staged package's malware scan is running and exposes staged version history to maintainers.
For an AI release agent, make the release boundary an explicit review item: which identities may submit a candidate, which may publish immediately, and which human approves a staged version? Use the audit below before expanding an agent's release responsibilities. It is a proposed test method, not a report of an integration test performed for this article.
Review the union of permissions
Consider two hypothetical connections for the same package. One matches release.yml in the production environment and permits staging. Another matches the same repository and workflow without an environment criterion and permits direct publishing. Treat the second as a possible route around your intended human approval boundary. Giving the first connection a more reassuring name does not resolve that overlap.
Our engineering recommendation is to review the set of permitted operations across all matching connections. Ask the reviewer to explain why each remaining direct route exists. If the answer is that the agent normally chooses the staging command, the enforcement evidence is incomplete: add a negative test in which that workflow attempts the direct command. Keep the wider identity and tool boundaries in the zero-trust architecture guide for AI agents alongside this package-specific audit.
Inventory old and new routes
The npm trusted publishing documentation distinguishes historical settings: connections created before May 20, 2026 defaulted to direct publishing alone; those created before September 3 required explicit action selection. It describes staging as the automatic permission for connections created after September 3. Inspect saved actions rather than assuming that a new default migrated an old connection. For GitHub Actions, record owner, repository, workflow filename and the optional environment. npm also documents traditional authentication alongside OIDC and token fallback.
Build a matrix from actual package settings. The rows below are illustrative proposed settings, not npm defaults or a verified production configuration. Replace every example with your values and record configuration identifiers and creation dates where available. Write “no criterion” for an omitted environment so reviewers can distinguish it from missing audit data.
| Repository / workflow / environment | Proposed permission | Owner and evidence |
|---|---|---|
| example/sdk / stable.yml / production | Stage; reject direct publish | Release owner; positive and negative run IDs |
| example/sdk / prerelease.yml / preview | Stage; reject direct publish | Preview owner; separate test versions |
| example/sdk / staging.yml / staging | Stage; reject direct publish | Agent operator; recorded approval boundary |
| example/sdk / old-release.yml / no criterion | Inspect saved actions; removal candidate | Migration owner; removal and retest evidence |
| Token or manual route | Inspect separately | Account owner; access policy and credential inventory |
Inspect release jobs, secret references and registry configuration without copying credential values into the review. Name each token reference, its intended use and the person responsible for retiring it. The npm documentation recommends restricting token publishing after trusted publishing is configured. Decide and record that policy explicitly; adding an OIDC connection is not evidence that token access has been removed.
Test staging and denied direct publishing
Use a dedicated test package under your control containing harmless synthetic content. Mirror the intended publishing criteria, document differences from production, and reserve a distinct version for every attempt. Keep the test package out of real dependency graphs. Start with a positive staging control; otherwise a broken runner or unavailable registry could produce misleading negative results.
npm documents npm stage publish for staging and npm publish for direct publication. Use those operations in the paired tests below with the same job identity and package contents, apart from the fresh version. Record the installed CLI and runtime versions and verify compatibility against the linked documentation before running. Do not substitute a local dry run for a registry authorization test.
| Test | Expected evidence under the proposed policy |
|---|---|
| Each intended identity submits a staged candidate | Submission succeeds; candidate is staged and awaits human approval |
| Same identity attempts direct publishing | Authorization is denied; that attempted version is not publicly available |
| Unlisted workflow attempts staging and direct publishing | Both operations fail authorization with token fallback excluded |
| Identity uses an environment outside its configured criterion | Both operations are denied unless another connection matches; investigate any success |
| Retired connection is removed, then its workflow is retried | No remaining connection or credential authorizes the retired route |
For every result, retain the workflow revision, repository, environment, command, package version, timestamp, exit status and sanitized registry response. Classify timeouts, duplicate-version errors and build failures as inconclusive for authorization. A passing negative test needs both a relevant denial and a check of the attempted version's registry state. If direct publication succeeds, stop the rollout and trace every matching configuration and available credential before repeating the test.
Name the approver and retire redundant paths
In the positive staging case, have a named maintainer review the candidate after scanning completes. Record the submitted version, source revision, reviewed artifact, approver, decision and resulting registry state. Treat scan completion as a prerequisite for the approval exercise; it does not answer whether the artifact implements your intended change. Likewise, this authorization audit does not measure code quality or the agent's understanding of the release.
Write a removal date and owner beside each temporary publisher. Require a new review when workflow names, repositories, environments or permitted operations change. Keep the corresponding agent rollback and approval plan attached to the release record so an unexpected result has a defined response. The completed audit should let another maintainer reconstruct how a candidate reached approval and why no tested agent route could skip it.