Delivery-path privilege

The effective authority held by systems that move software from source to production, including registries, CI/CD jobs, publishing tokens, and agent workflows. It matters because attackers often target the path that delivers change, not the application that receives it.

Expanded Definition

Delivery-path privilege describes the authority embedded in the software delivery chain, not the final application itself. It covers the credentials, service accounts, pipeline runners, signing workflows, registry permissions, and agent actions that can alter what code is built, approved, or released. In practice, this is a security-domain concept that overlaps with OWASP Non-Human Identity Top 10 because the systems holding this authority are usually NHIs, and because compromise of those identities can create direct production impact.

The term is broader than “CI/CD security” because it focuses on effective power: what a delivery system can actually do if it is hijacked, over-permissioned, or implicitly trusted. That includes release automation, artifact promotion, infrastructure provisioning, and AI-assisted build or deployment agents that can execute tools without human review. Definitions vary across vendors on whether a build runner, publishing token, or GitOps controller is part of the delivery path, but the security meaning is consistent: if the component can move software into production, it has delivery-path privilege.

The most common misapplication is treating the delivery path as a set of harmless automation tasks, which occurs when teams fail to map indirect production authority across tokens, runners, and agent workflows.

Examples and Use Cases

Implementing delivery-path privilege rigorously often introduces operational friction, requiring organisations to weigh deployment speed against tighter control over who and what can release change.

• A CI job signs release artifacts and pushes them to a production registry, so the job token becomes a high-value NHI that must be isolated, short-lived, and monitored.
• A GitOps controller syncs manifests into a cluster after every merge, meaning repository write access and deployment authority can become equivalent in practice.
• A software publisher token can overwrite package versions in a public or private registry, creating a path for dependency poisoning or malicious rollback.
• An autonomous deployment agent can approve, stage, and roll forward changes through tool calls, so its execution authority needs explicit bounds and logging.
• A privileged build runner can inject secrets into downstream steps, which means compromise of the runner can cascade into environment takeover and release tampering.

For delivery integrity patterns, security teams often pair this concept with OWASP NHI guidance and identity-centric controls so that each automation identity has only the minimum release authority needed for its step.

Why It Matters for Security Teams

Delivery-path privilege matters because it reframes software supply chain risk as an identity and authority problem. When an attacker gains control of a publishing token, pipeline runner, or AI agent with deployment rights, they may not need to breach the application at all. They can alter artifacts, inject malicious dependencies, change infrastructure state, or push unauthorised releases that appear legitimate from the inside. This is especially important in environments using ephemeral build systems and agentic automation, where effective privilege can be granted through runtime trust rather than static roles.

For governance, the key question is not simply who can access source code, but which identities can change the delivery outcome. That includes human maintainers, service accounts, brokered secrets, and non-human agents with tool access. Security teams need traceability across build, sign, publish, and promote stages, plus clear separation between read-only automation and release-capable automation. The term becomes most relevant after a tampered artifact, unexpected deployment, or registry compromise forces teams to trace which identity actually had the power to move change into production.

Related resources from NHI Mgmt Group

• Why do Windows integrity levels fail to stop every privilege escalation path?
• Support-path privilege
• Privilege path
• Deployment-path privilege inheritance