Who is accountable for credential governance when CI/CD jobs can assume access dynamically?

Accountability should sit with the platform and identity owners who define the policy, approve the trust relationship, and monitor issuance. Developers may trigger the job, but security and DevOps teams must decide which workloads can access which systems, for how long, and under what conditions. Auditing should prove every request and grant.

Why This Matters for Security Teams

When CI/CD jobs can assume access dynamically, the real question is not who clicked “run,” but who owns the trust path that makes the job eligible to receive credentials at all. That distinction matters because pipeline identities are often broader than application identities, and their access can expand quietly through reused tokens, inherited permissions, or poorly scoped automation roles. Guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward explicit control of non-human access, not trust by default.

This is where accountability often gets blurred: developers define pipeline logic, platform teams maintain runners and orchestration, and identity or security teams own policy and enforcement. If those boundaries are not explicit, credential issuance becomes a shared-risk zone with no clear approver, no consistent TTL, and no reliable audit trail. In practice, many security teams encounter over-permissioned pipeline access only after a supply chain incident has already exposed secrets or lateral movement has occurred.

How It Works in Practice

For dynamic CI/CD access, accountability should map to the control plane rather than the job submitter. The platform owner typically governs the runner environment, the identity owner defines the trust relationship, and security sets policy for what a workload may request at runtime. That model is consistent with current guidance in NHI research such as the Ultimate Guide to NHIs — Static vs Dynamic Secrets, which emphasizes short-lived credentials over standing access.

In practice, mature implementations use workload identity rather than shared secrets. A pipeline job presents a cryptographic identity such as OIDC or a SPIFFE-based workload identity, then a policy engine evaluates the request at runtime. The decision should consider repository, branch, environment, build provenance, target system, and time window. That is why best practice is moving toward intent-aware authorization, not fixed RBAC alone. RWAC-style permission sets are too blunt when a job may build, test, sign, deploy, or rollback in the same execution path.

• Issue credentials per task, with a short TTL and automatic revocation on completion.
• Bind trust to a specific workload, repo, and environment rather than a human account.
• Log every request, decision, and grant so audit can reconstruct the full path.
• Separate policy definition from pipeline execution so no single developer role can self-authorize access.

For governance, the control owner should define approval criteria, enforce least privilege, and monitor anomalies in issuance volume, scope, and reuse. The operational reality is that dynamic access only stays safe when issuance is narrow and traceable; these controls tend to break down in self-hosted runners with persistent storage because secrets and tokens can survive beyond the intended job boundary.

Common Variations and Edge Cases

Tighter credential governance often increases delivery friction, requiring organisations to balance deployment speed against stronger runtime controls. That tradeoff is real in high-frequency CI/CD environments, especially when release pipelines span multiple clouds, third-party actions, or ephemeral containers. Current guidance suggests the answer is not to relax accountability, but to make approval and issuance machine-enforceable so teams do not rely on informal handoffs.

One common edge case is delegated administration. A DevOps team may operate the pipeline, but if it can also mint or widen its own access, governance has failed even if the workflow is “automated.” Another edge case is federated deployment across business units, where the identity owner and the system owner are different groups. In those cases, policy must state who approves the trust relationship, who reviews exceptions, and who can revoke access immediately when the runner, token issuer, or downstream service changes.

NHIMG research consistently shows why this matters. The 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect they have experienced an NHI breach, which is a strong signal that governance gaps are not theoretical. Pair that with the CI/CD pipeline exploitation case study, and the lesson is clear: dynamic access fails fastest where ownership is split but accountability is not written down.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• Should organisations prioritise external exposure or internal credential governance first?
• Who should be accountable for privileged access hidden in CI/CD and cloud tooling?
• Why do CI/CD service accounts and publishing tokens need the same governance as human access?