TL;DR: Pipeline convenience can depend on careful secret handling and variable management, as Cerbos’ Azure DevOps guide shows how to automate policy uploads to Cerbos Hub using stored client credentials, a main-branch trigger, and a containerised upload job according to Cerbos. The governance lesson is broader than policy deployment: CI/CD paths that move privileged credentials can quietly become NHI control points if they are not tightly scoped and reviewed.
At a glance
What this is: This is a guide for automating Cerbos policy uploads from Azure DevOps, and its key risk is that pipeline-managed client credentials become privileged non-human access.
Why it matters: It matters because IAM, PAM, and NHI programmes need to treat CI/CD jobs that handle secrets as governed identity pathways, not just delivery automation.
Context
Azure DevOps policy upload pipelines are a form of non-human identity governance because they move credentials, execute privileged jobs, and make access decisions outside a human login flow. The security question is not whether automation is useful, but whether the pipeline becomes a durable access path that is hard to inventory, scope, and review.
This guide shows a main-branch-triggered workflow that uploads Cerbos policies using stored client credentials and a containerised job. That pattern is common in delivery engineering, but it creates an identity control surface inside CI/CD: secrets are passed into runtime, used by tooling, and then expected to disappear without leaving a lingering privilege trail.
Key questions
Q: What breaks when CI/CD pipelines use privileged credentials for policy uploads?
A: The failure mode is that the pipeline becomes a standing non-human identity with write capability, so any change to the YAML, runner, or container can turn a delivery step into an authorisation-changing control point. The risk is not just secret theft. It is credential reuse in a path that is assumed to be routine and low risk.
Q: Why do main-branch upload pipelines increase governance risk?
A: Because the branch trigger links release authority to repository governance. If main is compromised or poorly reviewed, the upload path can be reached with the same credentials used for legitimate deployment, which raises the impact of misconfiguration, insider change, or malicious pull request activity.
Q: What do security teams get wrong about secret variables in Azure DevOps?
A: They often treat variable storage as the control, when the real risk is every place the variable can flow after expansion. Scripts, logs, inherited environment values, and container commands can all expose the secret even when the variable itself is marked secret.
Q: How should security teams govern CI/CD jobs that publish security policy?
A: Treat the publishing job as a privileged non-human identity, not a build task. Scope its credential to one action, protect the variables that hold it, and restrict execution to approved branches and trusted runners. If policy publication changes authorisation behaviour, it belongs in IAM oversight and audit scope, not only in DevOps controls.
Technical breakdown
How Azure DevOps pipelines turn secret handling into identity risk
A pipeline that uploads policies must authenticate to an external service, usually by passing client ID and client secret values into the build environment. That creates a temporary identity boundary inside CI/CD: the runner, the script, and the container all touch credentials that are capable of privileged action. The risk is not only exposure in source control. It is also variable expansion, log leakage, mis-scoped environment inheritance, and reuse of the same secret across jobs. In NHI terms, the pipeline is acting as a machine identity with standing authority unless that authority is tightly constrained.
Practical implication: Treat the pipeline as a governed identity, and scope its credentials to the minimum action set needed for upload only.
Why main-branch triggers increase the blast radius of policy automation
When a pipeline is triggered on pushes to the main branch, every change merged into that branch can reach the privileged upload path. That makes branch protection, code review, and pipeline change control part of the access model, not just the development workflow. If the YAML itself can be altered, an attacker or careless change can redirect the job, print secrets, or reuse the credential in another step. The security boundary therefore includes repository governance, not just the Cerbos Hub store or the Azure DevOps variable store.
Practical implication: Lock down pipeline definitions with branch protection and change review because pipeline code can be an access path.
What containerised upload jobs change about secret exposure
Running the upload through a container makes the runtime portable, but it does not remove the identity problem. The container receives environment variables, mounts the working directory, and executes a command with credentials already present in memory. If the container image, entrypoint, or surrounding script is compromised, the upload path can be abused without any new login event. This is a classic CI/CD NHI pattern: a service credential is not just stored, it is operationalised inside an automated execution context that may be reused across many runs.
Practical implication: Separate build tooling from credential-bearing jobs and verify the container image and command path before granting upload authority.
Threat narrative
Attacker objective: The attacker’s objective is to use pipeline-handled client credentials to change policy content or reuse privileged upload access for broader control.
- Entry occurs when pipeline secrets are stored as variables and passed into a scripted upload job that runs on each main-branch change.
- Credential exposure follows if those secrets are echoed, inherited, or reused in a modified pipeline step or compromised container runtime.
- Escalation happens when the same credentials can perform write operations against Cerbos Hub without additional approval or just-in-time gating.
- Impact is policy tampering or unauthorized policy upload, which can alter downstream authorisation decisions for applications consuming those policies.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CI/CD upload jobs are non-human identities with governance consequences, not neutral delivery plumbing. A pipeline that holds client credentials, triggers on main, and performs a privileged upload is functioning as an operational identity. That means ownership, scope, and revocation need the same discipline applied to other NHI actors. The practitioner conclusion is straightforward: treat the upload job as a governed access path, not a convenience script.
Branch-triggered secret use creates an identity blast radius that extends beyond the secret store. The access decision is no longer only about who can read a variable. It also depends on who can change the pipeline, who can merge to main, and which runtime paths inherit the secret at execution time. This is why CI/CD governance and NHI governance converge in the same control plane.
Secret handling in delivery pipelines is a lifecycle problem, not just a confidentiality problem. The key issue is that credentials often outlive the moment they are needed, then remain reusable inside automation until someone rotates or removes them. That creates a standing privilege pattern inside release infrastructure. Practitioners should read this as a sign that pipeline credentials need explicit lifecycle ownership and offboarding.
Access review processes are weak when they assume a human operator is the only accountable identity. In this pattern, the operator may be the pipeline, while the human only authored the YAML or set the variables. Accountability therefore splits across repository control, build control, and secret control. The implication for practitioners is that recertification must include automated jobs that can act independently of human login sessions.
Policy deployment automation exposes a simple governance concept: upload authority must be as tightly controlled as policy authorship. If a workflow can publish policies, it can affect authorisation outcomes even when application code is unchanged. That means CI/CD pipelines need to be assessed as part of the authorisation fabric, not only as code delivery tooling. The practitioner conclusion is to align policy upload rights with the same rigor used for production access.
What this signals
Pipeline identity now belongs in the same governance conversation as workload identity. Any automated job that can authenticate, inherit secrets, and publish security policy is performing identity work, not just release work. Programmes that ignore this blur will keep discovering that the most convenient delivery path is also a privileged access path.
CI/CD secret handling exposes an identity blast radius that is wider than the secret store. The real control question is who can change the pipeline, who can reach the runner, and what the container can do once credentials are injected. That is the boundary practitioners should map before they assume a secret is safely “stored.”
Policy upload automation needs lifecycle governance. A pipeline that can write policy should have a named owner, a defined purpose, and a clear retirement path. Without that lifecycle, temporary delivery convenience turns into a persistent privileged access pattern.
For practitioners
- Constrain pipeline credentials to upload-only scope Issue the Cerbos Hub client credentials with the minimum permissions needed for policy replacement and nothing broader. Keep the secret pair tied to a single pipeline purpose so reuse in other jobs is not viable.
- Protect the YAML as a privileged control surface Require review and branch protection for azure-pipelines.yml so changes to triggers, scripts, and environment handling cannot silently expand access. Treat modifications to the pipeline definition as access changes, not just code changes.
- Separate secret storage from runtime exposure Keep CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET in the pipeline variable store, but assume any step that receives them can leak them through logs, scripts, or container entrypoints. Minimise the number of steps that can read them.
- Review upload jobs as NHI assets Assign an owner to each CI/CD job that uses credentials, define its purpose, and retire it when the upload use case ends. If a pipeline can publish policy, it needs offboarding and recertification just like any other privileged non-human identity.
Key takeaways
- Azure DevOps policy upload jobs can become privileged non-human identities when they carry write-capable client credentials into automated runtime steps.
- The main risk is not the upload workflow itself but the way secrets, branch triggers, and container execution combine into a reusable access path.
- Treat pipeline definitions, secret variables, and upload permissions as governed identity assets so policy automation does not become standing privilege.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Pipeline secrets are injected into runtime and can leak through scripts, logs, or containers. |
| NHI-05 — Overprivileged NHI | The pipeline uses write-capable credentials to publish policy, creating excessive non-human access. | |
| NHI-07 — Long-Lived Secrets | Stored client credentials persist across runs and create standing access in the delivery path. | |
| Recommendation — Scan CI/CD jobs for secret leakage paths and remove any credential exposure from build logs and steps. Restrict pipeline credentials to the minimum upload scope and revoke broader permissions. Rotate pipeline secrets regularly and replace persistent credentials with shorter-lived alternatives where possible. | ||
| CIS Controls v8 | CIS-5 — Account Management | The pipeline's client credentials function as accounts that need ownership and lifecycle control. |
| Recommendation — Track CI/CD service credentials under account management and retire them when the workflow ends. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The risk path centers on credential theft and use through pipeline-controlled access to downstream systems. |
| Recommendation — Map exposed pipeline credentials to credential access and lateral movement detections in your pipeline telemetry. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The pipeline requires tightly bounded permissions because it can change policy content. |
| Recommendation — Apply PR.AA-05 to verify that CI/CD jobs have only the permissions needed for policy upload. | ||
Key terms
- Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
- Secret Variable: A secret variable is a protected value stored so a pipeline can read credentials without exposing them in normal configuration views. The control is only partial, because the secret still exists in runtime memory, environment variables, and scripts that can leak or reuse it if the job is not tightly governed.
- Branch-Triggered Deployment: Branch-triggered deployment is a release pattern where merges or pushes to a specific branch automatically run an operational workflow. For identity governance, the branch becomes part of the access boundary, because code changes can alter who or what receives privileged execution.
- Policy Upload Authority: Policy upload authority is the permission to publish or replace access policy in a policy store or authorisation system. It matters because changing policy can alter downstream access decisions even when application code remains unchanged, so it should be controlled like other high-impact privileged actions.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org