GitHub Actions policy uploads expose secret handling in CI/CD

At a glance

What this is: This is a how-to guide for automating Cerbos policy uploads from GitHub Actions, and its key governance signal is that the pipeline relies on write-capable repository secrets.

Why it matters: IAM and platform teams should treat CI/CD workflows that hold credentials as managed identities, because the access path and the secret lifecycle become part of the control surface.

Context

This guide is about a GitHub Actions workflow that automatically pushes policy files to a Cerbos Hub store when code lands on the main branch. The identity question is not the YAML itself, but the trust placed in the workflow, the repository secrets, and the write permission granted to the upload process.

In practice, that means the pipeline is acting as a non-human identity with privileged access to policy storage. Once a workflow can authenticate with client credentials and write changes, it needs the same governance attention that teams give to service accounts, tokens, and other machine credentials.

Key questions

Q: What breaks when GitHub Actions workflows are allowed to access secrets without approval?

A: When workflow secret access is not gated, an attacker can turn the CI runner into the exfiltration tool. A malicious workflow can dump secrets, upload them as an artifact, and remove traces before anyone notices. At that point, detection becomes reactive only, and organisations are left rotating credentials after exposure instead of preventing the theft in the first place.

Q: Why do CI/CD repository secrets increase access-control risk in policy deployment workflows?

A: Because they create standing privilege inside automation. A write-capable secret can be reused every time the workflow runs, so the control problem becomes who can use, expose, or replace that credential, not just who can edit the workflow file.

Q: What are the signs that a GitHub Actions integration is over-privileged?

A: Look for workflows that can both authenticate and replace policy or configuration files, use the same credential for multiple tasks, or run with broad repository secrets that outlast the actual deployment need. Those patterns indicate the integration has grown beyond its original purpose.

Q: How should teams govern branch-triggered policy uploads in GitHub Actions?

A: Treat the branch trigger, the workflow file, and the credential set as one control path. Governance should cover who can change the trigger, who can approve the workflow, and who can revoke the upload credential when the deployment path changes.

Technical breakdown

Why policy upload workflows become identity-bearing automation

A GitHub Actions workflow is more than a build step when it can authenticate to an external service and write policy changes. The workflow in this guide uses repository secrets for CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET, then passes them into a containerised CLI that performs the upload. That creates a non-human identity path with its own authentication, authorisation, and blast radius. The security issue is not GitHub Actions by itself, but the fact that the workflow becomes a governed actor with standing access to a downstream policy store.

Practical implication: classify upload workflows as NHI paths and review them as privileged integration accounts.

Repository secrets are credentials, not configuration values

Repository secrets in GitHub Actions are operational credentials. If they can write to a policy store, they are equivalent to a service account token with a narrowly defined purpose and a real failure mode if exposed or over-scoped. The workflow shown here depends on Read & Write client credentials, which is stronger than a read-only integration and therefore needs stricter lifecycle handling, access scoping, and offboarding discipline. Secret storage reduces casual exposure, but it does not remove the governance burden that comes with credentialed automation.

Practical implication: inventory CI/CD secrets as production credentials and apply rotation, revocation, and scope review.

Containerised CLI execution shifts trust to the pipeline runtime

The upload step runs a containerised CLI inside the GitHub Actions job, mounting the repository workspace and injecting credentials through environment variables. That makes the runtime boundary important: the workflow runner, the container image, and the repository contents all influence what can be changed or leaked. In identity terms, the execution context is part of the trust model because it determines where secrets land, what code can run, and how easily an attacker could abuse the same path if the workflow were compromised.

Practical implication: treat the runner, image, and mounted workspace as part of the credential protection boundary.

Threat narrative

Attacker objective: The objective would be to alter policy content or abuse the upload path so that access control decisions change in the attacker’s favour.

1. Entry occurs through the GitHub Actions workflow path itself, where a push to main triggers a job that already has access to write-capable client credentials.
2. Credential exposure is concentrated in repository secrets passed into the upload step and into the container runtime as environment variables.
3. Escalation happens if the workflow, the secret values, or the container image is tampered with, because the same path can be used to write policy changes.
4. Impact would be unauthorised modification of policy files in the Cerbos Hub store, which could change downstream access decisions.

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).
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

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 policy upload workflows are non-human identities, not build plumbing. Once a pipeline can authenticate to a policy store and write changes, it becomes a governed credential-bearing actor with its own lifecycle. That shifts it out of the convenience category and into identity governance, where scope, ownership, and revocation matter. Practitioners should stop treating these jobs as disposable automation and start treating them as managed machine access.

Write-capable repository secrets create standing privilege in disguise. The workflow depends on client credentials with Read & Write access, which means the privilege exists before the upload begins and persists until someone rotates or revokes it. That is classic standing access, even if it is delivered through a secret store rather than an account console. The practitioner conclusion is that secret storage alone does not satisfy governance over the access it enables.

Policy deployment is now part of the identity control plane. When policy content is pushed by automated workflow, the control path that governs access decisions is itself mediated by credentials and execution context. That means CI/CD and policy administration can no longer be separated cleanly in governance reviews. Teams need to treat the pipeline as part of the authority chain that protects production access decisions.

Secret-bearing workflows expand blast radius when they are tied to branch events. A push-to-main trigger creates a narrow but powerful automation window in which a commit can invoke privileged policy deployment. That is a useful delivery pattern, but it also means branch protection, repository permissions, and workflow integrity are now directly linked to authorisation outcomes. The practitioner takeaway is that the trigger path must be governed as tightly as the secret itself.

Credentialed automation should be governed through lifecycle discipline, not ad hoc setup. The article shows a common pattern in which teams create a working integration first and only later ask how to govern it. That order is backwards for identity security because the workflow already has enough privilege to matter from day one. The practical conclusion is to define ownership, access scope, and offboarding for every CI/CD integration before it is allowed to change policy.

What this signals

Pipeline policy uploads need the same lifecycle discipline as service accounts. The main governance mistake in this pattern is assuming that an automated job is harmless because no human signs in. In reality, the workflow is a credentialed actor with a specific purpose, so ownership, offboarding, and scope review should be applied before the first deployment.

Branch-triggered uploads create a compact authority chain: repository change, workflow execution, secret use, and policy write. That chain should be documented in the same way teams document privileged integrations elsewhere in the identity programme, because the policy system and the delivery pipeline now share responsibility for access outcomes.

For practitioners

• Inventory policy-upload workflows as managed identities Record every workflow that can authenticate to external services, especially those that can write to policy or configuration stores. Assign an owner, a purpose, and a revocation path for each one.
• Restrict CI/CD credentials to the minimum write scope Avoid broad Read & Write access unless the workflow truly needs to replace files. Where possible, separate read, upload, and administrative functions so the secret only supports the task it must perform.
• Rotate and revoke repository secrets on a schedule Treat CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET like production credentials, with documented rotation, immediate revocation when the workflow changes, and cleanup when the repository is retired.
• Harden the workflow runtime boundary Review the container image, runner permissions, and workspace mount used by the upload step so the job cannot be repurposed to read or exfiltrate unrelated secrets.

Key takeaways

• A GitHub Actions policy upload workflow is a non-human identity path when it authenticates and writes to an external store.
• Write-capable repository secrets create standing privilege, even when they are hidden inside automation.
• The control question is whether the workflow’s credentials, trigger, and runtime boundary are governed like production identity assets.

Key terms

• Policy Deployment Workflow: A policy deployment workflow is an automated path that moves access rules or configuration into a live control store. In identity governance terms, it behaves like a machine actor because it can authenticate, write, and trigger downstream authorisation effects without human intervention.
• Repository secret: A credential stored for use by code or automation inside a repository context. Repository secrets are identity assets, not configuration text. They should be owned, scoped, rotated, and removed with the same discipline applied to service accounts and other privileged non-human identities.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Workflow Runtime Boundary: The workflow runtime boundary is the set of trusted components that can influence what a pipeline job can read, execute, and transmit. It includes the runner, container image, repository contents, and mounted workspace, all of which shape the real security boundary for automated identity actions.

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.