Notifications
Clear all
Topic starter
12/06/2026 12:35 am
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.
NHIMG editorial — based on content published by Cerbos: a guide to automatically uploading Cerbos policies from CircleCI to Cerbos Hub
Questions worth separating out
Q: How should security teams govern CI/CD jobs that write to policy stores?
A: Treat the job as a privileged non-human identity.
Q: Why do CI/CD environment variables create identity risk?
A: Because they often act as standing credentials inside an execution context that repeats many times.
Q: What breaks when a build job has more access than the policy change itself requires?
A: The pipeline becomes a control-plane shortcut.
Practitioner guidance
- Classify the pipeline as an NHI Document the CircleCI job as a non-human identity with write authority, then assign an owner, an approval path, and a revocation process for its credentials.
- Replace long-lived client secrets Move Cerbos Hub access out of static environment variables where possible and reduce the chance that build context can reuse the same write capability indefinitely.
- Limit the write blast radius Separate policy upload authority from broader repository or deployment permissions so a compromised job cannot move beyond the intended policy store action.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- The exact CircleCI config block used to upload policies into Cerbos Hub.
- The environment variable setup process for storing client ID and client secret values in CircleCI.
- The branch filter and workflow wiring needed to trigger uploads only from the main branch.
- The verification steps for checking the upload-policies job status inside CircleCI.
👉 Read Cerbos' guide to uploading policies from CircleCI to Cerbos Hub →
CI/CD policy uploads: what IAM teams should watch?
Explore further
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.
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.
- Another finding from the same research shows that 97% of NHIs carry excessive privileges, which broadens the attack surface when pipeline credentials can write to enforcement systems.
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
