Who is accountable when supply chain compromise persists through automation workflows?

Accountability usually spans application security, platform engineering, and identity governance because the failure is shared across package trust, token control, and CI/CD permissions. Frameworks such as NIST CSF and OWASP NHI help assign ownership to the controls that govern reuse, scope, and revocation.

Why This Matters for Security Teams

When supply chain compromise persists through automation workflows, the problem is no longer limited to a single bad package or a single exposed secret. It becomes a governance failure across code ingestion, build trust, token scope, and workflow permissions. That is why accountability cannot sit only with one team; it must be mapped across application security, platform engineering, and identity governance. The practical question is not who caused the first weakness, but who owned the control that allowed it to keep operating. Guidance from the OWASP Non-Human Identity Top 10 is especially relevant because automation identities often outlive the task they were created for.

Security teams often underestimate how quickly one compromised dependency can become a repeatable path when CI/CD runners, service accounts, and API tokens are allowed broad reuse. In that state, remediation is not just patching software. It is revoking trust, reducing privilege, and proving which workflow step actually had authority to act. In practice, many security teams encounter this only after the workflow has already been reused to sign, ship, or deploy something that should never have reached production.

How It Works in Practice

In operational terms, accountability follows the control plane that allowed the compromise to persist. If a build pipeline pulled an untrusted dependency, platform engineering may own the runner configuration, application security may own the dependency policy, and identity governance may own the token lifecycle. If the same automation account could access repositories, artifact stores, and deployment targets, then the root issue is excessive standing access, not just a vulnerable package.

The cleanest way to assign ownership is to break the workflow into control points and ask who is responsible for each one:

• Package intake and verification, including source trust and integrity checks
• Secret storage, rotation, and revocation for machine credentials
• Pipeline permissions, especially who can trigger releases or modify build logic
• Artifact signing, provenance, and release approval
• Detection and response when a workflow behaves outside expected bounds

This is where control mappings become useful. NIST SP 800-53 Rev. 5 Security and Privacy Controls helps translate the issue into enforceable access, configuration, and audit requirements, while the NIST CSF approach keeps the focus on governance, protect, detect, and respond outcomes. For more advanced automation environments, especially where AI agents can trigger tools or approve actions, current guidance suggests treating the automation identity itself as a protected asset with explicit scope and expiry rather than as a convenience credential.

That means ownership should be documented before an incident, not negotiated during one. Security leaders should define who can revoke a token, who can freeze a pipeline, who can quarantine an artifact, and who must sign off on recovery. These controls tend to break down when multiple teams share unmanaged automation accounts across ephemeral runners because no single owner can see the full execution path.

Common Variations and Edge Cases

Tighter workflow control often increases delivery overhead, requiring organisations to balance release speed against stronger assurance. That tradeoff becomes sharper in highly automated environments, where short-lived build agents, third-party actions, and delegated deployment permissions are normal. Best practice is evolving, but there is no universal standard for exactly how far to centralise ownership of automation identities versus leaving some control with platform teams.

One important edge case is AI-assisted automation. If an AI system can select tools, generate code, or trigger deployment steps, accountability expands beyond traditional DevSecOps into AI governance and non-human identity management. The emerging risk is not only compromised code, but compromised instruction flow, where a malicious input or poisoned dependency changes what the automation chooses to do. The Anthropic report on an AI-orchestrated cyber espionage campaign shows why human review still matters when autonomous systems gain execution authority.

Another edge case is shared service accounts in legacy pipelines. They may look stable, but they obscure ownership and make revocation difficult. In those environments, accountability often sits with the team that can finally constrain the account, even if another team created it. The practical answer is to assign responsibility to the function that controls scope, rotation, and recovery, then verify that someone can actually act on that responsibility when the compromise persists.

Related resources from NHI Mgmt Group

• Who is accountable when a supply chain compromise spreads through trusted credentials?
• Who is accountable when a supply-chain breach persists because an NHI credential survived rotation?
• Who is accountable when third-party trust relationships are exploited in a supply chain compromise?
• Who is accountable when a supply chain package compromise reaches developer systems?