Accountability sits with the team that owns the workflow, the repository maintainers, and the platform security function that defines token scope and review policy. Release automation needs explicit ownership because a compromised CI/CD identity can become a supply chain incident, not just a build failure. Governance should require traceable approvals for every privileged workflow path.
Why This Matters for Security Teams
A workflow token is not just a convenience credential. In a release pipeline, it can authorize code checkout, package publication, environment changes, and cloud access in the same execution path. When that token is abused, the issue is not limited to a failed build. It becomes a trust breakdown across software delivery, secrets handling, and production change control. NIST SP 800-53 Rev 5 Security and Privacy Controls treats access control and auditability as core security outcomes, and that is exactly where pipeline identity must be governed.
NHIMG research shows how quickly pipeline access becomes systemic risk: the CI/CD pipeline exploitation case study and the Guide to the Secret Sprawl Challenge both show that secrets and tokens are often distributed across tools, repos, and chat systems long before anyone notices. In practice, many security teams discover accountability gaps only after a release identity has already been used to publish malicious artifacts or access downstream systems.
How It Works in Practice
Accountability in a workflow-token abuse scenario should be assigned by control plane, not by blame after the fact. The team that owns the workflow is responsible for the pipeline logic, triggers, and approved runtime paths. Repository maintainers are responsible for the code and configuration that define when the token is requested and where it can be used. The platform security function is responsible for token scope, TTL, approval requirements, and logging policy. That division is important because release automation often spans source control, CI runners, artifact registries, and cloud APIs.
Operationally, the strongest model is to treat the workflow token as a short-lived, task-bound secret with explicit context. Current guidance suggests pairing least privilege with just-in-time issuance, narrow audience claims, and traceable approvals for privileged workflows. In the release path, that means the token should only be minted for the exact job, the exact repository, and the exact environment, then revoked automatically when the job ends. OIDC-based workload identity, policy-as-code, and immutable audit logs make it possible to prove which workflow requested access and why.
That approach aligns with the realities described in the 2025 State of NHIs and Secrets in Cybersecurity: 44% of NHI tokens are exposed in the wild, often across tickets, chat, and code. The practical lesson is that accountability must include the people who approve token scope, the people who maintain the workflow, and the people who can revoke the identity when abuse is suspected. One useful external reference for control design is the NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for access enforcement, monitoring, and audit evidence. These controls tend to break down in monorepos with shared runners and inherited permissions because the executing identity is no longer unique to a single team or release path.
Common Variations and Edge Cases
Tighter release-token governance often increases delivery overhead, requiring organisations to balance deployment speed against stronger approval and revocation controls. That tradeoff becomes sharper in multi-team platforms, where shared runners, reusable workflows, or centrally managed templates blur ownership boundaries. There is no universal standard for this yet, but current guidance suggests documenting a named workflow owner, a repository owner, and a platform approver for every privileged release path.
Edge cases usually appear when tokens are reused across multiple repositories, when a single NHI is shared by several pipelines, or when a release system can self-approve its own access. Those patterns weaken accountability because abuse can look like normal automation. In higher-risk environments, teams should also separate build identity from deploy identity, use different approval rules for artifact signing versus production changes, and review whether a compromised workflow could chain into cloud or secret-manager access. The Reviewdog GitHub Action supply chain attack is a useful reminder that trusted actions can become a distribution point for abuse. For teams following the Shai Hulud npm malware campaign pattern, the failure mode is usually broad token scope plus weak revocation, not a single isolated bug.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Workflow token abuse is an NHI lifecycle and scope problem. |
| OWASP Agentic AI Top 10 | A-04 | Autonomous pipeline actions need runtime authorization and traceability. |
| CSA MAESTRO | TRUST-03 | Release pipelines need workload trust and controlled machine-to-machine access. |
| NIST AI RMF | Accountability for automated decision paths is a governance concern. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and authorization directly apply to pipeline tokens. |
Inventory release identities, constrain scope, and revoke any token that exceeds its intended workflow.
