Should organisations separate package publishing identity from CI runtime identity?

Why separation matters for publishing, builds and deployment

package publishing identity is the principal actor that signs, uploads, or releases an artifact. CI runtime identity is the actor that executes tests, builds, and pipeline steps. Those duties should not collapse into one account or one secret set, because the trust boundary is different: publishing needs authority over release actions, while build execution needs controlled access to source, dependencies, and ephemeral tooling.

That separation reduces blast radius. If a maintainer token, CI runner, or workflow file is compromised, the attacker should not automatically gain the ability to publish a trusted package, impersonate release automation, or reuse the same credential elsewhere. Distinct identities also make audit trails clearer, because release activity and build activity can be reviewed independently.

Publishing identities are best treated as narrow release authorities, not general-purpose automation users. Build identities should be short-lived, scoped to the minimum repositories and registries they need, and isolated from the tokens that can create public artifacts. In practice, that means the person or system that can trigger a build should not be the same principal that can publish the resulting package.

A useful way to think about this is to separate the trust you grant to the build path from the trust you grant to the release path. A compromised build can be noisy and recoverable, but a compromised publishing identity can turn a clean build into a malicious release. A compromise of either path should not let an attacker cross directly into the other path.

Where the boundary usually fails

Separation fails when teams reuse the same token across local development, CI, and publication, or when a pipeline holds a long-lived publishing secret just because it is convenient. That creates a single point of failure: once the secret leaks, the attacker inherits both the ability to run pipeline actions and the ability to ship artifacts.

It also fails when build workflows are allowed to mint or retrieve release credentials on demand without a strong trust condition, such as protected branches, signed provenance, or narrowly delegated federation. If the runtime environment can reach the same publishing authority as the release process, then a poisoned workflow, dependency substitution, or malicious pull request may become a release event.

Supply-chain guidance consistently treats build and release trust as different problems, not one combined identity problem. The stronger pattern is to keep CI ephemeral and low privilege, then let a separate publishing identity act only when the pipeline has crossed the required assurance gates. That is the model described in CI/CD Pipeline Identity Security Guide, and it aligns with artifact-integrity guidance from NIST SP 800-190 Container Security and provenance controls described by OpenSSF.

What good separation looks like in practice

Good separation usually has three properties. First, build identities are ephemeral and do not carry publishing permissions. Second, publishing identities are distinct, narrowly scoped, and used only after the pipeline has produced a verifiable artifact. Third, the handoff between the two is explicit, so the release step can verify what was built before anything is published.

That model is easier to operate when you treat the release identity as a controlled delivery function, not as a shared automation convenience account. It should have access to the registry or package repository, but not broad access to source code, runner infrastructure, or unrelated cloud services. Build runners should be able to build, test, and prepare attestations, but not silently publish on their own.

This is also where provenance and trust policy matter. If your build identity can only assume publishing authority after a specific branch, tag, signature, or attestation check, then the publishing step becomes a conscious control point rather than a hidden side effect of CI execution. The distinction is especially important in ecosystems where packages are consumed automatically and a compromised release can spread quickly.

For organisations that also manage broader identity lifecycle and governance, the pattern maps cleanly to standard identity hygiene: separate ownership, separate credentials, separate rotation, and separate review. NHIMG’s NHI Lifecycle Management Guide and Top 10 NHI Issues reinforce the same operational principle, that the lifecycle and privilege of an automation identity must match its exact role. For teams standardising the control model, Ultimate Guide to NHIs, Standards is a useful reference point for the surrounding control set.

Practitioner Guidance

What to prioritise: Separate the credential that can publish from the credential that can build, then review whether either one has broader access than its job requires. If a single identity can both execute untrusted pipeline code and release a package, treat that as a design defect rather than an optimisation.

What to verify: Confirm that publishing requires a distinct principal, short-lived access where possible, and an explicit trust gate tied to a verified build output. Also verify that revoking the CI runtime identity would not break the ability to rotate or recover publishing access, because dependency between the two is the failure mode you are trying to eliminate.

Common mistake: Teams often protect the package registry but leave the CI path overpowered. That leaves the attacker one stolen workflow secret or one poisoned runner away from converting build compromise into release compromise.

Practitioner takeaway: The question is not whether CI can reach the publisher, it is whether a compromised CI path can cross the release boundary without an additional, independently controlled trust decision.

Related resources from NHI Mgmt Group

• Should organisations separate agent runtime controls from identity governance?
• How should teams separate package trust from identity trust in CI?
• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?