Azure DevOps policy upload pipelines expose secret-handling risk

At a glance

What this is: A Cerbos guide explains how to automate policy uploads from Azure DevOps to Cerbos Hub using secret-backed pipeline variables and a containerised upload step.

Why it matters: IAM and security teams should treat pipeline credentials as non-human identities, because build automation can become a durable access path if secret handling, scope, and revocation are weak.

👉 Read Cerbos's guide to uploading Cerbos policies from Azure DevOps

Context

Azure DevOps pipelines often become identity control points the moment they move from build automation into privileged deployment or content publishing. In this case, the primary issue is not policy authoring itself but how the pipeline stores and uses CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET to upload content on behalf of the repository.

That pattern belongs squarely in non-human identity governance. The pipeline has a stable trigger, a fixed execution path, and credentialed access to an external service, which means access review, secret rotation, and offboarding all matter as much here as they do for service accounts or API tokens.

Key questions

Q: How should security teams govern secrets used by CI/CD pipelines?

A: Treat pipeline secrets like any other non-human identity credential. Give them a named owner, limit their scope to one service and one purpose, rotate them on a schedule, and revoke them when the pipeline, repository, or team changes. If a secret can be reused outside the intended build path, governance is too weak.

Q: Why do CI/CD pipelines create NHI governance risk?

A: Because a pipeline can hold delegated access long after the developer who created it has moved on. That makes the build system a durable identity broker, not just an automation helper. The risk rises when secrets are stored in variables, branch triggers are broad, or revocation is not tied to lifecycle events.

Q: What breaks when pipeline secrets are not rotated or revoked?

A: The organisation loses control over who can still publish, deploy, or upload through the pipeline. Old credentials can keep working after code changes, staff changes, or repository handoffs, which turns an automated workflow into a persistent access path. The failure is lifecycle drift, not just weak secret hygiene.

Q: Who is accountable when a CI/CD pipeline publishes privileged changes?

A: The team that owns the trigger, the variables, and the downstream service is accountable, even if the action is automated. Branch protection, secret management, and approval design all sit inside that accountability chain. If no one can explain who can revoke the pipeline’s access, accountability is already broken.

Technical breakdown

Azure DevOps pipeline identities and secret variables

An Azure DevOps pipeline can act as a machine identity when it uses stored variables to authenticate to downstream services. In this guide, the pipeline reads client ID and secret values from the pipeline variable store and passes them into a containerised upload command. That creates a clear separation between code and credentials, but it also creates a durable trust path that depends on the secrecy, scoping, and lifecycle of those variables. The security boundary is not the YAML file alone. It is the combination of trigger, variable scope, hosted agent, and downstream credential acceptance.

Practical implication: treat pipeline variables as governed credentials, not as convenience settings.

Containerised uploads to Cerbos Hub

The upload step runs cerbosctl inside a Docker container on a Microsoft-hosted Linux agent, mounting the working directory and forwarding environment variables into the container. Architecturally, that means the build agent is not doing the policy work itself. Instead, it becomes a broker that supplies files and secrets to a separate executable with external reach. This is a classic machine-to-service pattern, and the risk sits in the trust chain between repository contents, pipeline execution, and the remote store that accepts the upload. If any of those boundaries are too loose, the pipeline becomes a broad access lane rather than a controlled deployment path.

Practical implication: constrain what the container can read, write, and reach before using it for privileged uploads.

Main-branch triggers and change control

A trigger on pushes to main means the pipeline responds automatically to changes on the primary branch. That is useful for controlled promotion, but it also makes branch protection and approval discipline part of the identity story. The pipeline is effectively authorising a credentialed action whenever code lands in the protected branch. If the branch is weakly governed, the upload path inherits that weakness. In identity terms, the question is not just who can run the pipeline, but who can cause it to run with privileged credentials.

Practical implication: align branch protections with the privileges carried by the pipeline.

NHI Mgmt Group analysis

Pipeline credentials are non-human identities, not implementation details. The guide shows a routine automation flow, but the real security object is the pair of Cerbos Hub credentials stored in Azure DevOps and reused by a build job. That is a non-human identity with a lifecycle, scope, and revocation requirement. Organisations that treat pipeline secrets as disposable configuration miss the governance reality: the pipeline is holding delegated access on behalf of the repository. The practical conclusion is that CI/CD credentials need the same ownership and review model as any other privileged service identity.

Branch-triggered uploads turn source control into an access decision point. When pushes to main automatically trigger a credentialed upload, the repository ceases to be just code storage and becomes an authorisation gateway. This matters because the change-control model now determines whether privileged content moves into Cerbos Hub. If branch governance is weak, the downstream store inherits unreviewed intent. The broader lesson is that NHI governance must include the systems that initiate actions, not only the systems that authenticate them.

Ephemeral agent, standing secret: the pipeline agent is short-lived, but the client secret persists beyond any single run. That asymmetry is the control gap this pattern exposes. The build job disappears after execution, while the secret may remain valid across many runs, branches, and operators. The implication is not merely better rotation. It is that organisations need to recognise the mismatch between transient execution and persistent delegated authority in pipeline design.

Secrets in deployment pipelines create cross-programme exposure. A credential used for policy uploads can also become part of a wider compromise path if build logs, variable misconfiguration, or repository access are weak. That is why CI/CD identity controls sit at the intersection of IAM, PAM, and NHI governance. The practitioner takeaway is to manage pipeline access as a governed identity layer, not as a DevOps convenience feature.

Automation does not remove accountability, it redistributes it. The guide makes the pipeline the actor, but accountability still sits with the team that created the variables, protected the branch, and approved the upload path. That makes lifecycle governance central: who can create the secret, who can rotate it, who can revoke it, and who can change the trigger. The field implication is clear. CI/CD identity controls must be owned like any other privileged access path.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, which shows how often lifecycle control lags behind operational convenience.
• For related NHI governance patterns, see Guide to the Secret Sprawl Challenge for how secret sprawl turns routine automation into a persistent exposure problem.

What this signals

Secret sprawl is the hidden control plane behind many CI/CD identity failures. When a pipeline can read credentials from variables, files, or config, the governance challenge shifts from access granting to access containment. With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the operational default is still too permissive for modern build systems.

The practical signal for programme owners is that pipeline governance must be measured like identity governance, not like developer tooling. If branch controls, variable handling, and revocation are not linked, the pipeline will continue to outlive the assumptions behind it. That is why NHI programmes need explicit ownership for build-time credentials, not shared engineering responsibility.

Ephemeral execution does not eliminate standing privilege: a short-lived agent can still carry a long-lived secret. That distinction matters for IAM leads who are trying to align CI/CD with Zero Trust principles. The better question is not whether the agent is temporary, but whether the privilege attached to it can be constrained, observed, and revoked on the same lifecycle as the application it supports.

For practitioners

• Classify pipeline secrets as governed NHI credentials Assign an owner, scope, rotation interval, and revocation path to CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET. Do not leave them as generic pipeline variables without lifecycle control.
• Harden the main-branch trigger path Require branch protection, code review, and change approval before any pipeline run can publish policy changes to Cerbos Hub. The trigger should reflect the same control expectations as the target system.
• Limit container access to only the policy workspace Restrict mounted paths, environment exposure, and outbound permissions so the upload container cannot read unrelated repository material or reuse credentials outside the intended task.
• Review pipeline logs for secret leakage risk Verify that job output, task tracing, and masked variable handling do not expose credential values, repository paths, or upload metadata that could aid abuse.
• Build offboarding into pipeline ownership changes When repository ownership, team membership, or deployment responsibility changes, revoke and replace upload credentials rather than assuming the old pipeline secret can remain in place.

Key takeaways

• Azure DevOps pipelines can function as non-human identities when they use stored credentials to publish or deploy on behalf of a team.
• The largest governance risk is not the upload command itself, but the persistence of privileged secrets across branches, runs, and ownership changes.
• If pipeline access cannot be owned, rotated, and revoked like any other credentialed identity, the automation path is already over-trusted.

Key terms

• Pipeline Secret: A pipeline secret is a credential stored for use by an automated build or deployment job. In identity terms, it is delegated access that must be owned, scoped, rotated, and revoked like any other non-human credential because it can unlock external systems without a person present.
• Workload Identity: Workload identity is the identity assigned to a machine process, container, or automation path so it can authenticate to other services. For CI/CD, it defines what the pipeline may do, what it may reach, and how tightly that access must be controlled across its lifecycle.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, configuration files, build systems, and other non-secret stores. It increases exposure because access becomes harder to audit, rotate, and revoke, especially when the same secret is reused in multiple automation paths.
• Branch Protection: Branch protection is a change-control mechanism that limits who can alter a protected branch and under what conditions. In pipeline governance, it acts as a gate on when privileged automation can run, making source control part of the access decision rather than a passive repository.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: a guide to setting up an Azure DevOps pipeline for Cerbos policy uploads. Read the original.