Who is accountable when a compromised workflow publishes secrets or malicious changes?

Why This Matters for Security Teams

When a workflow publishes secrets or pushes malicious changes, the failure is rarely just “a stolen token.” The real issue is that repository policy, workflow permissions, and privileged access governance were allowed to overlap without clear ownership. NHI Management Group’s Guide to the Secret Sprawl Challenge shows how quickly secret exposure becomes operational debt, while the OWASP Non-Human Identity Top 10 frames the underlying control problem: machine credentials are often issued, stored, and reused without enough lifecycle accountability.

That matters because workflow compromise is a governance failure as much as a technical one. If a CI/CD job can publish to production, access package registries, or exfiltrate tokens, then the team that approved those permissions is accountable for the blast radius. If a developer token was stolen, that is an incident trigger, not the full explanation. In practice, many security teams discover the ownership gap only after the workflow has already signed, shipped, or leaked something irreversible.

How It Works in Practice

Accountability should be mapped across three layers: repository policy, workflow execution, and privileged access. The owner of the repository decides who can merge workflow changes, the platform or DevOps team defines runner and token boundaries, and the identity or PAM team governs what the workflow is allowed to reach at runtime. That division matters because a compromised workflow can abuse whichever control is weakest, including stored secrets, inherited permissions, or long-lived deployment tokens.

Current guidance suggests treating workflows as non-human identities with named control owners, not as anonymous automation. That means binding each pipeline to an explicit workload identity, enforcing least privilege, and using short-lived credentials that expire after the task completes. The operational pattern is straightforward:

• Use policy-as-code to restrict which branches, paths, or events can trigger privileged workflows.
• Issue JIT, ephemeral credentials only when the job context matches an approved use case.
• Separate build, test, and deploy permissions so a compromised step cannot freely pivot.
• Require revocation and audit logging when a workflow signs artifacts, updates registries, or exports secrets.

This is consistent with the direction described in the CI/CD pipeline exploitation case study and reinforced by the Anthropic report on AI-orchestrated cyber espionage, where autonomous tooling and stolen access combine to accelerate abuse. These controls tend to break down when runners are overprivileged, because a single compromised job can impersonate trusted automation and move faster than manual review.

Common Variations and Edge Cases

Tighter workflow control often increases operational overhead, requiring organisations to balance delivery speed against the assurance needed for production access. That tradeoff becomes sharper in monorepos, shared runners, and multi-tenant build platforms where one team’s change can affect another team’s secrets or deploy path. Guidance is still evolving for these environments, so there is no universal standard for ownership split in every setup.

One common edge case is “shared automation,” where several teams reuse the same pipeline template or runner pool. In that model, accountability must follow both the template owner and the local consumer because both influence exposure. Another is agentic or AI-assisted development, where a tool can generate commits, open pull requests, or call external services without a human in the loop. In those cases, organisations should treat the agent itself as a governed workload and trace control ownership to the policy that allowed the action, not only to the human approver.

For incident response, the practical question is not “who had the password?” but “who owned the right to issue, approve, and scope that access?” The 52 NHI Breaches Analysis and the Reviewdog GitHub Action supply chain attack both illustrate that exposure is usually a chain of delegated trust, not a single misstep.

Related resources from NHI Mgmt Group

• Who is accountable when a GitHub Actions workflow exposes secrets or pushes malicious code?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• Who is accountable when a compromised non-human identity causes major outage or data loss?
• Who is accountable when an AI agent or workflow executes privileged actions under a forged identity?