Trusted publishing
Trusted publishing lets a package registry authorize a configured automation identity through short-lived identity tokens instead of requiring a long-lived publishing secret in that workflow.
The registry trusts a specific automation identity
PyPI describes an exchange in which a configured CI identity presents an OpenID Connect token and receives a short-lived, project-scoped API token. The workflow does not need a manually created long-lived PyPI token for that publishing path.
npm also supports trusted publishing. For GitHub Actions, its configuration identifies an owner, repository, and workflow filename, with an optional environment. The configuration also controls allowed publishing actions. These details are registry-specific; do not assume every trusted publisher has identical release authority.
The maintainer handoff guide separates source changes, build operations, and package distribution. Trusted publishing connects an approved automation identity to that last responsibility.
Trusted identity does not mean harmless output
The trust check identifies an eligible workflow context. It does not prove that the package contains only intended code. Whoever can change or influence the authorized workflow may affect what it publishes.
Review the workflow, its executable inputs, and the registry-side trust configuration together. Removing a stored secret reduces one exposure without replacing code review or control over release automation.
The workflow approval article explains why artifacts from untrusted code remain untrusted when passed to a more privileged job. A short-lived credential does not make the artifact safe to publish.