A GitHub Actions event that starts one workflow after another workflow is requested or completed. In a privileged configuration, it can access secrets and write tokens even when the earlier workflow could not. That design is useful for chained automation, but it becomes dangerous if the later job trusts untrusted code or data from the first run.
Expanded Definition
A workflow run is the execution instance that starts when GitHub Actions receives an event, including a request to run another workflow or a completed upstream workflow. In chained automation, that boundary matters because the second run may execute with a different trust profile and a broader permission set.
The practical boundary is simple: a workflow run is not just “the same pipeline continuing.” It is a new execution context with its own triggers, inputs, permissions, logs, and artifact handling. That means the security question is less about the name of the event and more about what the downstream run is allowed to read, write, or publish.
Definitions vary a little across platform guidance, but the operational meaning is consistent. When a later workflow inherits data, artifacts, or state from an earlier run, the handoff becomes part of the security model. The strongest boundary misunderstanding is treating “automation-to-automation” as inherently safe when the upstream source may be partially untrusted.
Examples and Use Cases
Workflow runs commonly appear in chained delivery and automation patterns:
- A build workflow completes, then a release workflow starts to sign, package, and publish artifacts.
- A pull request workflow validates code, then a downstream deployment workflow runs after approval or merge.
- An upstream job generates artifacts, and a later job consumes them for scanning, promotion, or distribution.
- A reusable operational workflow runs after a scheduled or manually triggered parent workflow finishes.
These patterns are useful because they separate concerns, reduce repetition, and let teams apply different permissions to different stages. The tradeoff is that the downstream run often has to trust something produced earlier, so the handoff must be designed as a security boundary rather than a convenience feature.
For teams managing secrets and automation, this is where control of execution context becomes critical. The later workflow may be intentionally privileged, but that privilege should only extend to the exact tasks it needs to complete.
Security Implications
The main security issue is privilege crossing. If a downstream workflow run can access secrets, write tokens, deployment credentials, or repository-scoped permissions, then any untrusted code, metadata, or artifact passed from the earlier run can become an attack path into a more powerful context.
That creates concrete failure modes: secret exposure, malicious artifact execution, unauthorized publishing, tampered releases, and hidden command execution in a privileged job. In practice, the danger often comes from assuming that a workflow boundary also creates a trust boundary. It does not, unless the workflow design enforces one.
A common practitioner signal is a job that mixes validation and deployment responsibilities in the same chained path. Once the privileged workflow trusts upstream outputs without strict provenance checks, the blast radius expands from one run to the whole release or automation pipeline.
Security, Operational and Governance Implications
Workflow runs matter because they turn CI/CD policy into enforceable access control. The security model should define which runs can obtain secrets, which can write to protected resources, and which must remain read-only. In GitHub Actions, that distinction is often the difference between safe automation and privileged compromise.
From a governance perspective, the handoff between runs should be treated like any other control point: ownership, approval, artifact provenance, and permission scope all need explicit review. For example, if the downstream run is allowed to publish or deploy, the upstream run should not be able to influence that outcome without validation.
NHI and credential hygiene can become relevant in this pattern because automation often relies on tokens and other machine-held secrets. NHIMG notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code and CI/CD tools, which is exactly the kind of exposure that chained workflows can amplify.
Good governance keeps the workflow chain narrow, intentional, and auditable. The safest pattern is to let the earlier run produce evidence, not authority.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Workflow runs depend on tightly scoped access between chained jobs and environments. |
| 16 — Application Software Security | Chained workflow runs can execute untrusted code or artifacts inside privileged automation. | |
| Recommendation — Restrict workflow permissions to the minimum required for each run and separate validation from deployment. Verify artifact provenance and treat upstream workflow outputs as untrusted until validated. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Workflow runs create distinct trust and permission boundaries that need policy enforcement. |
| ID.SC — Supply Chain Risk Management | Chained runs often consume upstream outputs, making provenance and trust transfer central. | |
| Recommendation — Define and enforce least-privilege access for each workflow run and its downstream handoff. Track workflow provenance and approval gates before allowing downstream release or deployment. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Rotation and Revocation | Workflow runs often use long-lived automation credentials that can outlive their intended scope. |
| NHI-04 — Overprivileged Non-Human Identities | A later workflow run may hold broader access than the upstream run, creating privilege-crossover risk. | |
| Recommendation — Rotate and revoke automation credentials that are reachable from privileged workflow runs. Reduce downstream workflow permissions so chained automation cannot inherit unnecessary privilege. | ||
Related resources from NHI Mgmt Group
- How should security teams reduce blast radius when workflow automation platforms run with broad infrastructure access?
- What happens when a GitHub Actions run violates an enforced workflow policy?
- What are the signs that an AI coding agent is behaving in a black-box way during a workflow run?
- Why do workflow_run pipelines create supply chain risk when they process pull request results?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
