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.
Why This Matters for Security Teams
When a build job can modify policy state, the pipeline stops being a delivery mechanism and becomes an authority boundary. That matters because policy changes are not ordinary code changes: they determine who can access what, under which conditions, and with what level of privilege. If the job has broader rights than the policy update requires, a compromise in CI/CD can turn into a direct control-plane takeover.
This is a classic NHI failure mode, not just a DevSecOps hygiene issue. NHI Management Group has documented that 97% of NHIs carry excessive privileges in the Ultimate Guide to NHIs, which helps explain why over-scoped automation so often becomes the easiest path to lateral movement. The practical issue is separation of duties: the job that proposes or tests a policy should not necessarily be the same identity that can publish or enforce it. Current guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both reinforce least privilege and controlled change paths, but implementation is where teams usually fall short.
In practice, many security teams encounter this only after a pipeline token has already been used to alter enforcement rather than through intentional policy design.
How It Works in Practice
The safer pattern is to scope the build identity to the narrowest action set needed for the change, then separate authoring, approval, and enforcement into distinct trust steps. A job that validates policy can read configuration and run tests, but it should not hold standing permission to write the active policy store. If publication is required, use a second, tightly controlled NHI or an approval-gated release step with short-lived credentials.
That approach aligns with the basic control themes in 52 NHI Breaches Analysis, where over-privileged machine identities routinely expand a small weakness into an enterprise-wide incident. It also fits the operational direction of OWASP Non-Human Identity Top 10: treat each workload as an identity, not as a trusted environment.
- Use separate identities for policy authoring, approval, and deployment.
- Issue JIT credentials for the exact policy operation and revoke them immediately after use.
- Store secrets in a managed vault, not in pipeline variables, repositories, or build logs.
- Require signed change artifacts and immutable audit trails for every policy update.
- Bind policy publication to context, such as environment, repo, approver, and change ticket.
When teams need stronger assurance, policy-as-code checks should be evaluated at request time rather than assuming a static role map is enough. That usually means pairing CI/CD with runtime authorization logic and an explicit approval workflow for enforcement changes. These controls tend to break down in monolithic release pipelines because the same service account is often reused across build, test, and deploy stages.
Common Variations and Edge Cases
Tighter separation of duties often increases pipeline complexity and release latency, so organisations have to balance change velocity against control-plane safety. There is no universal standard for exactly how many identities a pipeline should use, but current guidance suggests that the identity used to propose a policy should not be the identity that can activate it.
Edge cases appear when policy updates are generated automatically, rolled out across many clusters, or packaged with infrastructure changes. In those environments, teams may be tempted to grant broad write access so automation does not fail on partial deployments. That tradeoff is dangerous because a single compromised build agent can then rewrite enforcement everywhere. The better pattern is to scope access by environment and by action, then require human or independent system approval for promotion into production.
This is also where Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 converge on lifecycle discipline and access governance. The practical takeaway is simple: if the job can both change and enable policy, then compromise of the job becomes compromise of the rulebook.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Over-privileged build jobs are a credential scope problem. |
| NIST CSF 2.0 | PR.AC-4 | Policy publication needs least privilege and controlled access paths. |
| NIST AI RMF | Context-aware authorization and governance apply to automated policy changes. |
Use runtime governance so machine actions are approved in context, not by static trust.
