Who should be accountable when a poisoned automation action exposes secrets?

Why This Matters for Security Teams

When a poisoned automation action exposes secrets, the failure is not just a bad package or a single misconfigured runner. It is an accountability problem across workflow ownership, secret issuance, and third-party trust. That matters because modern pipelines often execute with broad access, and once a malicious action inherits those permissions, the blast radius can move faster than manual review can respond.

NHI Management Group has shown how real-world supply chain incidents turn trusted automation into a secret exfiltration path, including the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign. The pattern is consistent: the workflow owner assumes the platform team constrained access, the platform team assumes the app team vetted the dependency, and the secret owner assumes the runtime isolates execution. Meanwhile, the automation simply runs.

That is why this question is operational, not theoretical. The right accountability model has to track provenance, approval, and containment as separate controls, then tie them back to a named owner who can act before exposure becomes incident handling. In practice, many security teams discover that no one owns poisoned automation until after secrets have already been harvested.

How It Works in Practice

The most defensible model is shared accountability with a primary workflow owner. That owner should be responsible for what the automation is allowed to do, while security and platform teams own the guardrails that make abuse harder. Current guidance suggests treating each action or dependency as an external supply chain trust decision, not a generic build step. The OWASP Non-Human Identity Top 10 is useful here because poisoned automation often succeeds by abusing machine credentials, not human sessions.

In practice, accountability should map to three checks:

• Workflow ownership: one team approves the automation logic, dependency pins, and update cadence.

• Secret scope: secrets are issued with the smallest usable audience and lifespan, so a compromised action cannot reuse long-lived access.

• Runner isolation: the execution environment is treated as hostile by default, with limited network reach and no ambient credentials.

This model aligns with the NIST view that access and control boundaries should be explicit and auditable, especially under NIST SP 800-53 Rev 5 Security and Privacy Controls. It also reflects the operational lessons captured in NHIMG’s Guide to the Secret Sprawl Challenge, where the problem is rarely a single leaked token and more often a weak chain of custody around where secrets exist and who can touch them.

The practical answer is not “security owns everything.” Security sets policy, platform enforces runtime boundaries, and application owners accept the risk of the dependencies they choose. These controls tend to break down when CI/CD runners share persistent credentials across repositories because the compromise of one action becomes the compromise of the whole execution plane.

Common Variations and Edge Cases

Tighter approval and isolation controls often increase delivery friction, so organisations have to balance trust reduction against pipeline speed. That tradeoff is real, especially where teams depend on third-party actions, reusable workflows, or generated automation that changes frequently.

There is no universal standard for who is “most accountable” in every environment, but current guidance suggests the answer shifts with control of the blast radius. If the platform team owns runner images and secret injection, it carries operational accountability for containment. If the application team imports unreviewed actions or expands token scope, it owns the risk acceptance. If a central security function sets policy but never reviews provenance exceptions, it may be accountable for governance gaps rather than the breach itself.

Two edge cases matter most. First, ephemeral secrets can still be exposed if logging, caching, or artifact upload captures them before revocation. Second, delegated automation in shared repositories can blur ownership unless the approval path is explicit. The 52 NHI Breaches Analysis shows how quickly machine trust fails when ownership, entitlement, and runtime controls are split across teams. In short, the accountable party is the team that can change the workflow, but effective prevention depends on every team controlling the part of the chain it actually operates.

Related resources from NHI Mgmt Group

• What is secrets exposure in NHI security?
• What is the main risk when automation systems store ServiceNow credentials?
• How should teams respond when CI or developer secrets are exposed?
• Why do still-valid secrets matter after public disclosure?