How should teams govern non-human access in software pipelines?

Why non-human access in pipelines needs identity governance, not just secrets handling

Software pipelines depend on build agents, runners, deployment tooling, package installers and automation tokens that can execute code, reach repositories and touch production-adjacent resources. The governance mistake is to treat them as background infrastructure instead of accountable actors. Once a pipeline credential can both run untrusted code and read sensitive material, you need identity controls that define purpose, ownership, scope and revocation.

That means every non-human principal should have a clear job, a named owner and a bounded trust envelope. The goal is not merely to store secrets safely, but to make sure each pipeline identity can only do the minimum set of actions required for its stage, environment and repository relationship.

For teams still standardising terminology, the distinction between a human operator, a service account, a deployment token and a workload identity matters because different pipeline components need different governance patterns. NHIMG’s Human vs Non-Human Identity explains where human and machine access overlap, and the definition of non-human identities covers the common pipeline actors teams usually need to govern.

What good pipeline governance actually controls

Good governance starts by assigning each pipeline identity a narrow purpose and an owner who can approve changes, review usage and accept exceptions. That ownership has to exist before the next credential rotation or access review, because orphaned automation is one of the easiest ways for privilege to drift quietly.

Runtime policy is the second control plane. The pipeline should be able to do only what its stage requires, for example build, sign, test, publish or deploy, and it should be blocked from unrelated reads such as secrets stores, production configuration or neighboring environments. If a process can execute arbitrary code, its read and write rights need even tighter separation.

Lifecycle controls matter just as much as access controls. Short-lived tokens, explicit expiry, environment-scoped permissions and reliable offboarding reduce the chance that old CI jobs, forgotten runners or copied installers remain valid after the underlying workflow has changed. For broader identity coverage, NHIMG’s NHI Ownership and Accountability Guide and Service Account Security Guide both align with the ownership and least-privilege pattern that pipelines need.

Pipelines also need separation between build, sign and deploy identities. If one token can cover all three, compromise in the least trusted stage can move straight into the most sensitive one. That is why identity reuse across environments is a governance smell, not a convenience.

Where pipeline identity fails in practice

The most common failure is scope creep. A build token gets reused for releases, a deployment token is granted read access to every secret, or a runner keeps standing privileges long after the job completes. That turns an automation identity into a standing access path with a wide blast radius.

Another recurring failure is mixing untrusted execution with secret access. When a pipeline can run third-party code, process pull requests or install external dependencies, every secret available to that same context becomes exposed to code you did not author. The same pattern appears in supply-chain incidents and poisoned workflows, which is why pipeline governance should be treated as part of software supply-chain defense as well as identity management. The CI/CD pipeline exploitation case study and reviewdog Action compromise 2025 show how pipeline exposure can turn into secret theft and unauthorized execution.

Third-party tooling introduces another governance gap. Installers, marketplace actions and shared build steps often inherit more privilege than teams realise, especially when approvals are global rather than repository-specific. NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide and Top 10 NHI Issues both reinforce the need to control third-party access paths, overprivilege and lifecycle drift.

Practitioner Guidance

What to prioritise: Start with identities that can combine code execution and secret access, because those are the highest-blast-radius pipeline principals. If a runner, installer or token can cross repository, environment or tenant boundaries, treat that as an urgent governance gap.

What to verify: Confirm that every pipeline identity has a named owner, a documented purpose, explicit expiry or rotation, and a permission boundary that is enforced at runtime, not just in policy docs. If you cannot show who approves the identity and what it can read, it is not governed enough to trust.

What good looks like: Separate identities for build, test, sign and deploy; short-lived credentials; no standing access to secrets by default; and clear evidence that untrusted code cannot inherit privileged read paths. NHIMG’s NHI Governance Maturity Model is useful here because it turns that separation into a maturity conversation rather than an ad hoc exception list.

Common mistake: Teams often harden secret storage while leaving the pipeline identity overly broad. That protects the vault but not the actor that can request or exfiltrate from it. Governance fails when the identity itself remains too powerful for the trust level of the job.

Practitioner takeaway: Govern pipeline access as an identity problem first and a tooling problem second, because the strongest control is the one that limits what the automation principal can do even when the pipeline itself is compromised.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?