Buildkite policy uploads expose CI/CD secrets handling gaps

At a glance

What this is: This is a Buildkite CI/CD guide for automatically uploading Cerbos policies to Cerbos Hub, with the key security issue being how agent-hosted secrets and pipeline credentials are handled.

Why it matters: It matters because CI/CD pipelines often sit inside identity programmes without the same scrutiny as human access, yet they can expose high-impact NHI and secrets-management gaps across build, deploy, and policy workflows.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Cerbos's guide for Buildkite-based Cerbos policy uploads

Context

CI/CD pipelines are identity-bearing systems, not just delivery plumbing. In this Buildkite pattern, the pipeline step reaches into a Cerbos Hub store using client credentials on the agent host, which means the security question is how those non-human credentials are governed, rotated, and bounded before the pipeline can act on them.

The main governance gap is familiar across NHI programmes: build-time automation often inherits long-lived secrets and broad execution trust from the host environment. That creates a path where policy delivery depends on credentials that are not isolated from the agent machine, the repository, or the pipeline definition itself.

Key questions

Q: How should security teams govern CI/CD credentials used by build agents?

A: Treat CI/CD credentials as non-human identities with explicit ownership, scope, and lifecycle controls. Store them outside general-purpose host environment files, limit them to the exact publishing action they need, and review the agent host as part of the access boundary. If the host can read the secret, the host is already in scope for identity governance.

Q: Why do branch protections not fully solve CI/CD secret risk?

A: Branch protections decide when a pipeline runs, but they do not constrain what the pipeline credential can do once execution starts. A compromised or over-permissioned secret can still upload, replace, or expose artifacts even in a protected main-branch workflow. Access control and release control must be governed separately.

Q: What breaks when CI/CD secrets live in shared environment variables?

A: Shared environment variables create standing privilege on the agent host, which widens exposure to any process or operator with sufficient local access. That breaks the assumption that only the intended pipeline step can use the secret. It also makes rotation, offboarding, and audit harder because the secret is embedded in host state rather than isolated workflow state.

Q: Who should own revocation when a build pipeline credential is changed or retired?

A: The owning platform or identity team should own revocation, not the developer who last edited the pipeline. Pipeline credentials should be registered as governed assets with a clear owner, rotation schedule, and offboarding path so that retired agents, shared hosts, and legacy workflows do not retain access after the pipeline is no longer needed.

Technical breakdown

Buildkite agent secrets and environment inheritance

Buildkite agents commonly execute jobs with environment variables inherited from the host, which makes the agent machine part of the trust boundary. In this pattern, the Cerbos Hub client ID and secret are stored in a system-wide file and then injected into a container at runtime. That is convenient, but it also means the CI/CD control plane now depends on the security of the agent host, the local shell environment, and the process used to restart the agent after credential changes. The identity at work here is non-human and persistent, so the question is whether the pipeline can operate without turning the host into a secret vault.

Practical implication: treat agent hosts as privileged secret-bearing systems and isolate CI/CD credentials from general-purpose environment storage.

Main-branch triggers and policy publishing trust

The pipeline is conditioned to run only when the build branch is main, which is a common release gate for automated publishing. The deeper issue is that branch-based gating controls when the job runs, not whether the credentials it uses are tightly scoped. A branch trigger can reduce noise, but it does not constrain what an abused credential can do once the pipeline starts. For NHI governance, that distinction matters because execution authority is still concentrated in a reusable secret pair that may outlive any single build.

Practical implication: pair branch triggers with narrow credential scope and separate approval for policy publishing paths.

Containerised CLI access to Cerbos Hub

The docker run step mounts the repository into a Cerbos control image and passes Hub credentials into the container as environment variables. That architecture reduces local tool installation, but it also means the container receives both code and secrets in the same execution context. If the agent is compromised, or if logs or debugging output expose process state, the attacker can capture the same credentials used to upload policy files. This is a classic NHI pattern: transport convenience improves operability, but it does not eliminate the identity and secret exposure surface.

Practical implication: keep upload credentials separate from build artefacts and review how container runtime logs or process inspection could expose them.

Threat narrative

Attacker objective: The attacker wants to gain non-human credential access that lets them alter policy content or disrupt policy publishing workflows.

1. Entry occurs when an attacker or insider gains access to the Buildkite agent host, the repository pipeline definition, or the environment storage where the Cerbos Hub client secret is defined.
2. Credential access follows if the client ID and secret are retrieved from the agent environment or reused in a pipeline job with broad upload rights.
3. Impact is policy store manipulation or unauthorised policy publishing, which can change the authorisation posture of downstream Cerbos-controlled applications.

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 credentials are NHI credentials, not implementation details: This guide shows a pipeline whose useful work depends on reusable client secrets, which means the identity problem sits inside delivery engineering rather than beside it. Once a build system can upload policy artifacts on command, the question becomes who can act as that identity, from where, and under what lifecycle constraints. Practitioners should treat pipeline credentials as governed NHI assets, not local config.

Environment-file secret storage is a standing privilege pattern: Placing client credentials in /etc/environment gives the agent machine persistent access that is convenient for automation but weak for governance. That pattern creates broad blast radius because the secret is available to any process with the right host access, not only to the intended upload step. The implication is not just better storage hygiene, but a re-evaluation of whether the build host should hold the credential at all.

Branch-based publishing controls timing, not trust: Limiting execution to main reduces accidental runs, but it does not answer the harder question of whether the identity used to publish policies is scoped tightly enough. This is where CI/CD governance often breaks down: organisations confuse release discipline with access discipline. Practitioners should separate when a pipeline may run from what the underlying NHI can do once it runs.

Policy delivery needs lifecycle discipline, not just automation: The most important control gap in this pattern is offboarding and rotation for the credentials that keep the pipeline alive. If a Buildkite agent is rebuilt, moved, or shared, the client secret must be handled as a governed lifecycle object with clear ownership and revocation. For identity teams, the lesson is that policy pipelines are part of the access estate and should be reviewed like any other privileged service account.

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.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• The Guide to the Secret Sprawl Challenge helps teams map where CI/CD secrets accumulate and how they escape formal control.

What this signals

Secret sprawl in CI/CD is a governance problem, not a tooling problem: When build agents inherit reusable credentials from host state, rotation and revocation become harder to verify and easier to defer. That is why pipeline security should be measured as an identity lifecycle issue, not just a delivery hardening task.

As CI/CD systems take on more policy, deployment, and approval actions, their credentials increasingly resemble privileged service accounts. Teams that already struggle with secret visibility should expect the same control failures to appear in build automation unless they move to tighter secret isolation and clearer ownership.

The practical signal to watch is whether your pipeline credential can be independently offboarded without editing application code or rebuilding every agent. If it cannot, the identity boundary is too loose for a system that can change production access or policy state.

For practitioners

• Move build secrets out of host-wide environment files Store Cerbos Hub client credentials in a dedicated secret manager or ephemeral injection mechanism instead of /etc/environment, then verify that the Buildkite agent only receives them for the duration of the job.
• Scope policy-upload credentials to the narrowest possible action Create a credential pair that can upload policies only to the intended store and cannot be reused for unrelated administrative functions or broader Hub actions.
• Separate release gating from secret authority Keep the main-branch trigger as a deployment gate, but do not treat it as access control for the credential itself. Review whether branch protection, repository permissions, and pipeline permissions are independently enforced.
• Review agent-host exposure as part of NHI lifecycle Inventory every Buildkite agent host that can access Cerbos Hub, document ownership, and revoke or rotate the credentials whenever the host role changes or the pipeline is retired.

Key takeaways

• CI/CD pipelines that publish policy are identity-bearing systems, so their credentials need the same governance as any privileged service account.
• Host-level secret storage and branch-only gating create standing trust assumptions that can widen the blast radius of a compromised build environment.
• Practitioners should separate release control from credential authority and track pipeline secrets through a full lifecycle of issuance, rotation, and revocation.

Key terms

• Build Agent Identity: A build agent identity is the non-human identity used by a CI/CD runner to execute automation, fetch secrets, and perform release tasks. It must be governed like other privileged machine identities because it can change code, policy, or deployment state without human intervention.
• Standing Privilege: Standing privilege is access that remains continuously available rather than being issued only when needed. In CI/CD environments, it often appears as long-lived secrets in host files or environment variables, which increases exposure if the agent machine is compromised or shared.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, configuration files, environment variables, and automation systems. It weakens auditability and revocation because the same secret may exist in multiple places with different owners and no single lifecycle view.

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 identity programme, it is worth exploring.

This post draws on content published by Cerbos: a guide to uploading Cerbos policies from a Buildkite pipeline. Read the original.