Bitbucket policy uploads to Cerbos Hub expose pipeline trust gaps

At a glance

What this is: This guide explains how to automate Cerbos policy uploads from Bitbucket Pipelines to Cerbos Hub and shows that the main risk is concentrated trust in pipeline secrets and branch controls.

Why it matters: IAM and NHI teams should treat CI/CD variables and write-capable credentials as governed identities, because the security boundary shifts from deployment convenience to policy integrity.

Context

Bitbucket Pipelines workflows that push policy changes into a policy store create a governance problem that looks simple but is not: the pipeline becomes a write-capable identity with standing access to production policy state. In practice, that means the security question is not only whether the job runs, but who or what is trusted to publish policy and under what conditions.

For IAM and NHI programmes, this is a classic trust-boundary issue in CI/CD. The guide shows repository variables, secured secrets, and branch-based execution being used together, which is workable only if the credential lifecycle, branch controls, and policy change approval path are all tightly governed.

Key questions

Q: What breaks when policy uploads from Bitbucket Pipelines are not tightly governed?

A: The pipeline becomes a privileged policy publisher rather than a neutral delivery step. If branch protection, secret scope, or change review is weak, an attacker or careless operator can publish policy changes through a trusted path and alter downstream authorisation behaviour without direct access to the target store.

Q: Why do write-capable CI/CD credentials increase policy tampering risk?

A: Because they combine authentication and change authority in a runtime identity that is often reused across pushes. If the same credential can both start the job and write policy state, compromise or misuse of that pipeline path can translate into unauthorised policy changes, not just build leakage.

Q: How do security teams know whether pipeline access is actually under control?

A: Look for three signals: no long-lived deploy secrets in repository or pipeline settings, tight Kubernetes roles scoped to the smallest viable namespace and verbs, and audit logs that tie each deploy to a specific workflow run. If any one of those is missing, the pipeline still has standing privilege.

Q: What is the difference between securing a secret and governing its use in CI/CD?

A: Securing a secret means hiding the value and limiting casual exposure. Governing its use means defining who can trigger it, what it can change, how long it remains valid, and how its authority is revoked when the workflow changes. Both are needed for policy upload pipelines.

Technical breakdown

Why Bitbucket Pipelines becomes a policy publisher identity

When a pipeline uploads policies to Cerbos Hub, it is no longer just a build job. It acts as a non-human identity with write authority over policy state, using client credentials that must be stored, scoped, and protected like any other privileged secret. The trust model depends on repository variables, branch restrictions, and the assumption that only intended changes reach the main branch. That makes the pipeline a controlled publisher, not a passive automation step.

Practical implication: Treat policy-upload pipelines as privileged NHI actors and govern their credentials, branch triggers, and change paths accordingly.

Why secured variables are not the same as governed access

Marking Bitbucket repository variables as secured hides values from casual viewing, but it does not solve lifecycle governance. A secret can still be overprivileged, long-lived, reused across environments, or exposed through pipeline misuse if the execution path is weak. The guide’s use of Read & Write credentials is a reminder that authentication strength and authorisation scope are separate questions. Security depends on who can trigger the pipeline, when it runs, and what that identity can modify.

Practical implication: Separate secret storage from access governance and review who can invoke write-capable pipeline credentials.

Why main-branch automation concentrates blast radius

Branch-based automation can reduce manual error, but it also centralises control in a single merge path. If main is compromised, if pull request discipline is weak, or if change review is bypassed, the pipeline becomes a fast path to policy tampering. This is especially sensitive for policy-as-code environments because the output governs downstream authorisation decisions. In other words, the pipeline is part of the control plane, not just the delivery chain.

Practical implication: Apply stronger approval and protection controls to policy repositories than to ordinary application code.

Threat narrative

Attacker objective: The attacker aims to modify policy state through a trusted CI/CD path so that authorisation behaviour can be changed without direct access to the policy store.

1. Initial access occurs through the repository and pipeline path that is allowed to publish policy changes to Cerbos Hub.
2. Credential use centers on write-capable CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET values stored as repository variables.
3. Privilege escalation occurs when those credentials can alter policy state from an automated Bitbucket run, not just read configuration.
4. Impact is policy tampering or unauthorised policy publication, which can change downstream authorisation behaviour.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bitbucket policy upload workflows turn CI/CD into a privileged non-human identity. The guide makes that clear by requiring stored client credentials and a write-capable upload path. That means the pipeline is not just moving files, it is exercising authorisation against a policy store, so governance must treat it as an identity with scope, lifecycle, and accountability.

Policy-as-code changes the location of the control problem, not the control problem itself. The important question is whether the repository, branch protection, and pipeline trigger together form an acceptable trust boundary for policy publication. If those controls are loose, the automation path can become the shortest route to authorisation drift. Practitioners should read this as a policy integrity issue, not a deployment convenience issue.

Write access through a pipeline is blast-radius amplification. A single secret pair can publish changes that affect all downstream decisions relying on those policies. That makes branch governance, credential scoping, and change separation the real control surface. The practical conclusion is that policy publishers need stronger governance than ordinary application build jobs.

CI/CD policy publisher trust debt: The hidden liability is the assumption that an automated delivery path remains trustworthy simply because the secrets are stored securely. That assumption fails when the actor can both trigger publication and write policy state, because trust is concentrated in a small set of pipeline conditions. The implication is that policy distribution needs its own identity governance model, not a copy of application deployment controls.

Cerbos Hub uploads expose the gap between secured secrets and governed authorisation. Securing a repository variable does not establish least privilege if the same credential can publish policy changes from an automated branch flow. The field takeaway is that CI/CD identity controls must be evaluated against what they can change, not just where they are stored.

What this signals

Pipeline-upload workflows should be treated as governed identity flows, not as simple automation. Once a build job can publish policy state, the relevant question becomes whether the surrounding programme can prove who authorised that change and under what branch conditions. That pushes teams toward tighter change separation for policy repositories and clearer ownership of write-capable CI/CD identities.

Policy integrity depends on the trust boundary around the upload path. If repository variables, branch rules, and pipeline execution are not aligned, the upload mechanism can outpace the governance model. The safer pattern is to design policy publication as a controlled control-plane action, with stronger approval and secret lifecycle discipline than ordinary application delivery.

For practitioners

• Harden the policy repository branch path Require explicit review and protection for the main branch that triggers policy publication, so only authorised policy changes can reach the upload job.
• Scope pipeline credentials to the minimum publish path Use separate write credentials for policy upload and ensure they cannot be reused for unrelated environments or other administrative actions.
• Audit CI/CD variables as privileged identities Track CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET as governed secrets, including ownership, rotation, and offboarding when the workflow changes.
• Separate policy publication from ordinary build trust Treat the pipeline that publishes authorisation policy as a control-plane workflow and apply stricter change controls than for standard application builds.

Key takeaways

• Bitbucket-to-Cerbos Hub automation is really a privileged identity path, not just a deployment convenience.
• The main governance risk is concentrated trust in write-capable pipeline secrets and branch controls.
• Policy publication should be governed like a control-plane change, with tighter review and secret lifecycle rules than ordinary builds.

Key terms

• Policy Publisher Identity: A pipeline or automation job that has authority to write policy state rather than merely move code or configuration. In identity governance terms, it is a non-human identity whose outputs directly affect authorisation decisions, so its scope, ownership, and revocation matter as much as any privileged service account.
• Control-Plane Workflow: A control-plane workflow is a process that changes identity state, access state, or system configuration rather than just displaying data. Password resets, account provisioning, and administrative changes belong here, and failures in these paths tend to have wider consequences than ordinary application bugs.
• Write-Capable Pipeline Secret: A credential stored for use by automation that can modify a target system, not just authenticate to it. These secrets are high-risk because compromise or misuse can alter policy, configuration, or data, and they should be managed as privileged non-human identity credentials.
• Policy Integrity: Policy integrity is the assurance that administrative rules, firewall settings, and security controls have not been altered by unauthorized activity. It matters most on central management systems, where one change can affect many downstream enforcement points at once.

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