CI/CD policy uploads: what IAM teams should watch

NHI Mgmt Group · 2026-06-12T01:39:53+00:00

TL;DR: A CircleCI workflow that pushes policy files to Cerbos Hub on main-branch changes, using stored client credentials and environment variables to authorise the upload, is described by Cerbos. The pattern is operationally convenient, but it also concentrates trust in CI/CD secrets and access scoping that identity teams must govern as NHI controls, not just build plumbing. Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Automating Cerbos Policy deployments with CircleCI”. Key questions Q: What breaks when CI/CD pipelines rely on static secrets? A: Static secrets create a reusable attack path into production infrastructure. Q: Why do CI/CD publish credentials increase governance risk? A: Because the credential is not only proving identity, it is authorising a state-changing action in a control plane. Q: How do teams tell whether a pipeline secret is overprivileged? A: A pipeline secret is overprivileged when it can do more than the single workflow task it was created for, such as writing to stores outside the intended branch or environment. Practitioner guidance Constrain policy-upload credentials to one job Issue a dedicated publish identity for the upload step and scope it only to the Cerbos Hub store action required by the workflow. Rotate credentials on workflow or ownership changes Treat the client ID and client secret as governed NHI secrets with explicit rotation triggers when branch protections change, project ownership changes, or the pipeline is refactored. Review who can modify the CircleCI pipeline Separate repository write access from publish authority so that editing the config file does not automatically grant policy publication capability through inherited environment variables. Bottom line: CI/CD policy uploads are only as safe as the secret and scope model behind them, because the pipeline itself becomes a privileged identity. Explore furtherView Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →

Policy publishing through CI/CD is an NHI control plane, not a build convenience: The moment a pipeline can write policies to a central store, it is exercising non-human identity authority over security decisions. That authority depends on credential scope, branch protection, and runtime containment, not on the policy language itself. Practitioners should therefore classify the upload path as governed machine access, not a low-risk deployment helper.

A few things that frame the scale:

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.
59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.

A question worth separating out:

Q: Who should own credentials used by CI/CD policy automation?

A: The system owner, not the individual developer who created the workflow, should own the credentials and the offboarding path. Ownership should include approval, rotation, audit review, and a documented way to disable the job when the repository, project, or vendor relationship changes.

👉 Read our full editorial: CI/CD policy uploads expose Cerbos secret-handling assumptions

12/06/2026 9:55 am

CI/CD pipelines are NHI control planes, not just delivery tools. When a workflow can authenticate to an external policy store, it is operating as a non-human identity with delegated authority. That means the pipeline's credential handling, scope, and audit trail belong in identity governance, not only DevOps review. Practitioners should treat upload jobs as privileged machine identities with lifecycle, monitoring, and revocation requirements.