CI/CD policy uploads expose Cerbos secret-handling assumptions

At a glance

What this is: This is a CI/CD guide for uploading Cerbos policies from CircleCI to Cerbos Hub using stored client credentials and environment variables.

Why it matters: It matters because CI/CD credentials are non-human identities, so IAM, PAM, and secrets governance teams need to treat the pipeline as an identity surface, not only a delivery mechanism.

👉 Read Cerbos' guide to uploading policies from CircleCI to Cerbos Hub

Context

CI/CD pipelines often become hidden identity systems because they authenticate services, not people. In this pattern, the build job holds client credentials, runs on branch filters, and uses those secrets to write policy updates into a downstream store, which makes the pipeline part of the non-human identity control plane.

The governance question is not whether policy uploads should be automated. It is whether the organisation can prove that the pipeline identity has only the access it needs, that the secrets are protected outside code, and that the write path is monitored like any other privileged NHI action. This is a classic secrets-management and workload-identity problem, not a simple scripting exercise.

Key questions

Q: How should security teams govern CI/CD jobs that write to policy stores?

A: Treat the job as a privileged non-human identity. Give it only the narrow write access it needs, store credentials outside code, require protected branches for every policy change, and make revocation part of the pipeline offboarding process. If the workflow can alter enforcement, its identity controls should be managed like any other high-risk service account.

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. If a job can read a client secret from environment variables, that secret can be reused, copied, or exposed across runs. The risk is not just leakage, but persistent authority that survives beyond any single build.

Q: What breaks when a build job has more access than the policy change itself requires?

A: The pipeline becomes a control-plane shortcut. A compromised or misconfigured job can write policy state, bypass separation of duties, and change enforcement without touching the application layer. That creates a much larger blast radius than ordinary deployment automation because the job now influences who gets access and under what rules.

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.

Technical breakdown

CI/CD pipeline identity and write access

A CircleCI job that runs docker commands against a remote runtime is acting as an identity-bearing workload. The job is authenticated by environment variables, which become the effective credentials for the upload path. Because the workflow is triggered by branch filters, the trust boundary is not the developer laptop but the pipeline execution context and its secret store. This is why CI/CD systems frequently become privilege concentrators: one workflow can combine source control access, container execution, and write access to an external system in a single automated path.

Practical implication: classify the pipeline as an NHI, then scope and monitor its write permissions separately from developer access.

Secrets in environment variables and build logs

Environment variables are convenient for CI, but they are also a common secrets-exposure pattern because they are easy to copy, reuse, and accidentally surface in logs or job metadata. A client ID and client secret pair gives the pipeline stable authority, so compromise of the job context can expose the same access path across multiple runs. In NHI governance terms, this is standing credential risk inside delivery automation. The technical concern is not just theft, but credential persistence across repeated executions without tighter containment.

Practical implication: move CI secrets into a managed secrets control and minimise the lifespan and scope of every credential the pipeline can see.

Branch-gated policy deployment and change control

Limiting execution to the main branch reduces noise, but it does not remove the need for change governance. The workflow still turns source changes into direct policy writes, which means review integrity, repository protection, and downstream auditability all matter. In practice, this creates a combined control plane across Git, CI, and the policy store. If any one of those layers allows weak review or untracked credential use, the pipeline can become a fast path for policy drift rather than a safe automation channel.

Practical implication: require branch protection, change approval, and audit logging for every policy upload path that can alter enforcement state.

Threat narrative

Attacker objective: The objective is to gain persistent write control over policy enforcement by abusing pipeline-held credentials.

1. Entry occurs when the pipeline job inherits Cerbos Hub client credentials from CircleCI environment variables during build execution.
2. Escalation occurs because the same write-capable credentials can be reused across runs, giving the pipeline persistent authority over policy uploads.
3. Impact occurs when an attacker or misrouted workflow uses that standing authority to replace or tamper with policies in the downstream store.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

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 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.

Standing credentials in build automation create identity risk that outlives the code change. The pipeline uses persistent client credentials to perform a repeatable write action, which means access survives beyond any single commit or reviewer. This is the same structural problem seen in broad NHI programmes: authority remains available because the execution context is trusted by default. Practitioners should recognise that automation convenience often masks standing access.

Policy deployment is an enforcement path, so its identity controls must be tighter than ordinary application delivery. A compromised upload workflow can alter who gets access, how decisions are made, or which rules are enforced. That makes the pipeline a governance choke point, not a simple integration. Practitioners should place this path under the same scrutiny they apply to privileged access and secrets management.

The named concept here is policy-upload blast radius. This is the amount of enforcement authority a single CI job can exercise if its credentials are abused or misrouted. The larger the blast radius, the less meaningful branch-level comfort becomes, because the job can still write directly into policy state. Practitioners should measure how far one pipeline credential can move the control plane, not just whether the build passes.

OWASP NHI guidance fits this pattern because the weakness is not the container, it is the non-human identity lifecycle. The problem spans secret storage, privilege scope, and revocation when the pipeline or repository changes. That is a lifecycle issue with direct control-plane consequences. Practitioners should govern the pipeline credential as an NHI from issuance through offboarding.

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.
• 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.
• For the broader control model, see NIST Cybersecurity Framework 2.0 for govern, protect, detect, and recover functions that should surround CI/CD identity paths.

What this signals

Policy-upload blast radius: CI/CD jobs that can modify downstream enforcement state should be treated as privileged machine identities with measurable blast radius, not as routine build steps. The practical signal is simple: if one pipeline credential can rewrite policy, the governance boundary is too wide.

With 96% of organisations storing secrets outside secret managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, pipeline secret handling remains a structural weakness across identity programmes. Teams should expect build systems to be targeted wherever persistent credentials exist.

The next control question is whether the organisation can prove revocation, logging, and branch protection across the whole upload path. That is where the OWASP Non-Human Identity Top 10 becomes useful as a planning reference, especially for secrets sprawl and overprivilege.

For practitioners

• 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.
• Enforce protected change paths Require branch protection, code review, and audit logs for every policy update that reaches the main branch, then verify the upload trail in CircleCI and the target store.
• Test credential revocation on offboarding Remove the pipeline's credentials and confirm the job fails cleanly when the store ID or client secret is revoked, then record that outcome in the offboarding runbook.

Key takeaways

• CI/CD policy uploads create a non-human identity problem when build jobs hold write-capable credentials to downstream enforcement systems.
• Secrets stored in environment variables or pipeline context expand the attack surface because the same authority can persist across repeated runs.
• The control that matters most is not just pipeline success, but the ability to scope, audit, and revoke every credential that can alter policy state.

Key terms

• Non-Human Identity: A non-human identity is any machine- or workload-based account used to authenticate and act in a system. In CI/CD, that can include client secrets, service accounts, tokens, and deployment credentials that need ownership, scope, rotation, and revocation like any other identity.
• Standing Credential: A standing credential is a secret or token that remains valid across multiple sessions or executions. In automation, it is risky because repeated use expands the chance of reuse, leakage, and abuse, especially when the credential can write to a downstream control plane.
• Policy-Upload Blast Radius: Policy-upload blast radius is the amount of enforcement authority a single automated job can exercise if its identity is compromised or misrouted. It describes how far a CI/CD credential can move from a harmless build action into a change that affects access, decisions, or controls.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: a guide to automatically uploading Cerbos policies from CircleCI to Cerbos Hub. Read the original.