Who is accountable when a compromised workflow changes trusted release artefacts?

Accountability sits with the organisation that defines workflow permissions, release governance, and token lifecycle controls. For auditors, the relevant question is whether automation identities were approved, scoped, monitored, and revocable before the compromise. Frameworks such as NIST CSF and NIST 800-53 place that responsibility under access control and change management.

Why This Matters for Security Teams

A compromised workflow that rewrites trusted release artefacts is not just a build problem. It is a governance failure in the identity and approval chain that allowed automation to act with release authority. The real risk is that signing, packaging, or deployment tokens can become an unreviewed control plane for production change, especially when secrets are embedded in CI/CD. NHIMG notes that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, which makes release automation a prime target for abuse.

This is why accountability cannot stop at the developer who committed code. It extends to the team that defines workflow permissions, the security function that approves token scope, and the owners of release governance who allow artefacts to be trusted without continuous verification. NIST SP 800-53 Rev. 5 treats this as an access control and change management issue, not a narrow tooling issue, and NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now frames why non-human identities need lifecycle controls equal to their operational power.

In practice, many security teams discover the compromise only after a trusted release has already been used downstream.

How It Works in Practice

Accountability is established by tracing who can create, approve, impersonate, or rotate the non-human identities that move artefacts through the pipeline. In a well-governed workflow, the build identity should have only the minimum permissions needed to fetch dependencies, produce outputs, and publish to a controlled repository. Release approval should be separated from build execution, and the credential used to sign or promote artefacts should be short-lived, revocable, and tied to a specific workflow run.

That model is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises access enforcement, auditability, and change control. It also aligns with NHIMG guidance in the 52 NHI Breaches Analysis, where compromised automation identities repeatedly turn routine delivery paths into attack paths.

• Define the release identity separately from developer and build identities.
• Bind each workflow token to one job, one repository, and one short TTL.
• Require signed artefacts and verify signatures before promotion or deployment.
• Log who approved the workflow, who issued the credential, and who could revoke it.
• Continuously review whether the automation still needs the same release rights.

Where teams get this wrong is assuming that a trusted pipeline equals a trusted artefact. Trust must be re-earned at each stage with policy, identity, and verification, not inherited from the last successful run. These controls tend to break down when long-lived secrets are shared across repositories because one compromised token can alter every downstream release path.

Common Variations and Edge Cases

Tighter release controls often increase operational overhead, requiring organisations to balance delivery speed against the cost of additional approval and revocation steps. That tradeoff becomes more visible in multi-team platforms, where one pipeline may publish to several products or environments. Current guidance suggests that shared release identities should be treated as high-risk and broken into narrower, purpose-built identities wherever possible, but there is no universal standard for exactly how granular every pipeline must be.

Edge cases appear when third-party runners, delegated build services, or ephemeral agentic tooling can change artefacts outside the direct control of the application team. In those environments, accountability may be shared across platform engineering, product owners, and security operations, but the organisation still owns the control design. The key test is whether the automation identity was approved, scoped, monitored, and revocable before the compromise, and whether release trust was based on verified attestations rather than pipeline reputation alone. NHIMG’s research on the GitHub Action tj-actions Supply Chain Attack shows how quickly CI/CD trust can be converted into broad secret exposure once a workflow token is abused.

In environments with highly dynamic release engineering, the guidance breaks down when artefacts are promoted by loosely governed automation that no single team can revoke quickly enough.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised workflow publishes secrets or malicious changes?
• Who is accountable when a third-party MCP tool changes its description?
• What actions should I take if my OAuth tokens are compromised?
• Who is accountable when a compromised workflow exposes cloud and repository credentials?