Topic starter
12/06/2026 12:36 am
TL;DR: A Buildkite pipeline pattern uploads policy files to Cerbos Hub on main-branch changes using environment-stored client credentials and a Docker-based agent step, according to Cerbos. The governance issue is not the upload itself, but the standing trust and secret handling assumptions embedded in pipeline execution.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Automating Cerbos Policy deployments with Buildkite”.
Key questions
Q: What breaks when CI/CD policy uploads rely on agent-stored secrets?
A: The main failure is that the build agent becomes a standing secret boundary, so any compromise, reuse, or leakage on that host can expose the credentials that authorize policy uploads.
Q: Why do environment-stored pipeline credentials increase governance risk?
A: Because they extend the lifetime and reach of the credential beyond the single job that needs it.
Q: How should teams separate policy deployment from ordinary CI builds?
A: Treat policy deployment as a privileged path with its own authorization boundary, not as a side effect of a normal build.
Practitioner guidance
- Separate build and write paths Keep routine CI jobs read-only and reserve policy-upload authority for a narrowly scoped pipeline or approval path that is isolated from general build execution.
- Move secrets off the agent host Avoid placing long-lived client credentials in system-wide environment files on Buildkite agents, and prefer tighter secret injection patterns with shorter exposure windows.
- Scope credentials to the upload job Use credentials that only permit the exact Cerbos Hub store operation required for policy replacement, rather than broad reusable write access across jobs.
Bottom line: This pattern exposes the familiar CI/CD weakness where convenience-driven secret placement creates a privileged host boundary.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 9:56 am
CI/CD policy uploads are really identity events, not just deployment steps. The upload is only safe if the build identity, the host identity, and the policy store authority are all narrowly defined. Once client credentials live on the agent machine, the control plane moves out of the repository and into a broader machine trust boundary. The practitioner conclusion is that policy delivery must be governed like any other privileged non-human identity.
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.
A question worth separating out:
Q: What is the difference between container isolation and credential isolation in CI?
A: Container isolation limits the process environment, but credential isolation governs whether the job ever receives authority in the first place. A short-lived container can still execute with durable host-held secrets, so runtime isolation does not remove the need for strict secret issuance and scope control.
👉 Read our full editorial: Buildkite policy uploads expose CI/CD secrets handling gaps
This post was modified 5 days ago by NHI Mgmt Group