Accountability sits with the teams that defined workflow permissions, secret handling, runner isolation, and federation policy. Security, platform, and identity owners all share responsibility because the failure usually spans IAM, CI/CD, and cloud governance rather than a single control owner.
Why This Matters for Security Teams
A poisoned action that exfiltrates cloud credentials is not just a build failure or a malware event. It is an identity governance failure across workflow permissions, secret distribution, runner trust, and cloud federation. The accountable parties are usually the teams that approved the automation path, not only the person who merged the code. That is why NHI Management Group treats poisoned automation as an identity problem first and a supply chain problem second.
The risk is amplified when secrets are long-lived and broadly usable. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why static credentials persist far beyond the task that needed them, and why compromise often spreads silently after initial exposure. This is also where the OWASP Non-Human Identity Top 10 is relevant: over-privileged, poorly governed machine identities create the conditions for credential theft to become cloud takeover.
NHIMG’s Reviewdog GitHub Action supply chain attack shows how third-party automation can turn trusted pipeline execution into credential exposure in minutes. In practice, many security teams only discover the accountability gap after secrets have already been copied out of CI/CD and reused in the cloud control plane.
How It Works in Practice
Accountability follows control ownership, because poisoned actions exploit the seams between teams. Security typically owns policy, detection, and incident response. Platform engineering often owns CI/CD runner design, isolation, and build trust. Identity teams own federation, token lifetimes, and cloud role mapping. The merger request that introduced the action may be the trigger, but the blast radius is created by design choices made earlier.
Operationally, the right response is to map each step of the workflow to a named owner and a runtime control. That includes:
- restricting which actions can run and from where
- issuing just-in-time credentials with short TTLs instead of static secrets
- binding cloud access to workload identity rather than reusable tokens
- separating runner trust domains so one compromised job cannot reach another
- logging every secret read, token exchange, and federation event for auditability
For implementation guidance, the NIST SP 800-53 Rev 5 Security and Privacy Controls provide a control baseline for least privilege, access enforcement, and audit logging, while the NIST SP 800-63 Digital Identity Guidelines remain useful when federated assertions and proofing boundaries matter. In cloud-native environments, the practical objective is not to trust the action, but to constrain what it can prove, request, and retain at runtime.
NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that secrets leakage is often a distribution problem, not a storage problem. These controls tend to break down when runners are shared across projects and static cloud credentials are still injected into jobs by default, because one poisoned step can inherit trust that was never meant to be reusable.
Common Variations and Edge Cases
Tighter workflow control often increases build complexity and operational overhead, requiring organisations to balance developer speed against containment. That tradeoff becomes sharper when third-party actions, reusable workflows, or self-hosted runners are part of the delivery path. Current guidance suggests treating those components as separate trust zones, but there is no universal standard for this yet.
Edge cases matter. If the action only exfiltrated short-lived tokens, accountability may shift toward the team that allowed overly broad token scope or weak federation policy. If the runner itself was compromised, platform engineering may own more of the failure than the application team. If a cloud role trusted any repository in an organisation, identity governance failed at the federation layer even if CI/CD permissions were tight.
NHIMG’s 230M AWS environment compromise illustrates how cloud credentials can become the real breach path after an initial foothold. The practical lesson is that accountability should be documented before the incident, with explicit owners for action approval, secret issuance, runner isolation, and cloud trust policy. Where those ownership lines are vague, incident reviews tend to turn into blame-shifting instead of remediation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Poisoned actions are autonomous execution risks with tool abuse. |
| CSA MAESTRO | G3 | Maps to governance over workflow trust, secrets, and execution boundaries. |
| NIST AI RMF | GOVERN | Accountability depends on clear governance for AI-enabled automation. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static or over-scoped secrets enable exfiltration after action poisoning. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust limits lateral movement after a compromised action runs. |
Assign owners for runner trust, secret handling, and federation policy before production use.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
