A GitHub Actions trigger that starts one workflow after another workflow finishes. It is useful for chained automation, but it also creates a trust boundary. If the upstream workflow or its artifacts are attacker influenced, the downstream workflow can inherit that risk unless it validates inputs carefully.
What Workflow Run Trigger Actually Does
A workflow run trigger links two GitHub Actions workflows so that completion of an upstream job starts a downstream one. That makes automation easier to chain, but it also turns the upstream workflow into a trust boundary: the next run inherits whatever the first run produced, including outputs, artifacts, and any attacker-influenced state.
In practice, the trigger is less about “starting another workflow” and more about deciding which prior results are safe to reuse. If the upstream workflow can be influenced through code changes, pull request content, dependency updates, or compromised actions, the downstream workflow may execute with false assumptions unless it treats those inputs as untrusted.
Where the Trust Boundary Appears
The important security question is not whether the trigger works, but what crosses the boundary between workflows. The downstream run may consume artifacts, metadata, caches, repository contents, or status signals from the previous run. If those inputs are accepted without verification, the trigger becomes a propagation path for tampering rather than a clean handoff.
This is why chained automation needs more scrutiny than a single workflow. A downstream job often has broader permissions, more secrets, or production-facing side effects, so a weak upstream step can become a launch point for privilege misuse. The same pattern is visible in the GitHub Action tj-actions Supply Chain Attack, where compromised automation helped expose CI/CD secrets at scale.
Security Implications for CI/CD Pipelines
Workflow chaining changes the blast radius of a compromise. If the first workflow is maliciously altered, coerced through a dependency attack, or simply misconfigured, the second workflow may treat tainted output as trusted build evidence. That can lead to secret exposure, poisoned releases, incorrect deployment decisions, or unauthorized changes that are harder to trace because the compromise originated one step earlier in the pipeline.
The risk is especially acute when downstream jobs use tokens, deploy credentials, signing keys, or environment-specific permissions. A chained workflow can turn a small integrity failure into a broader pipeline compromise, which is why artifact provenance and input validation matter as much as the trigger itself. Controls around provenance and supply-chain integrity, such as SLSA, help frame that problem as a verification issue rather than a convenience feature.
Practical Ways to Use It Safely
What to watch for: treat every upstream output as untrusted unless it is independently verified. The most common mistake is assuming that because both workflows live in the same repository, the second one can safely trust the first one. Repository co-location does not prove integrity.
Governance implication: assign ownership for both workflows as one control chain, not two isolated automations. Review who can modify the upstream workflow, who can approve the downstream permissions, and whether the handoff includes validation of artifact hashes, branch state, or other trust signals. For broader operational guidance on secrets and automation exposure, NHI Mgmt Group’s Ultimate Guide to NHIs is a useful companion reference.
Risk and Threat Considerations
Workflow run triggers can propagate compromise from one pipeline stage to the next, so the main risk is not the trigger itself but the untrusted data and authority that cross it. If an attacker can influence the upstream run, they may be able to shape the downstream execution path, poison artifacts, or reach higher-value secrets and deployment actions.
Failure mechanism: a downstream workflow trusts upstream outputs, artifacts, or status signals without verifying provenance or integrity, allowing manipulated inputs to steer a privileged job.
Impact: the compromise can spread across chained automation, leading to secret theft, unauthorized deployment, supply-chain tampering, or persistent CI/CD trust degradation.
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 chaining depends on controlling who can alter trusted automation paths and handoff permissions. |
| 3 — Data Protection | The trigger may move artifacts and outputs between workflows that must be validated before reuse. | |
| 16 — Application Software Security | GitHub Actions workflows are part of the software delivery path and need secure design and review. | |
| Recommendation — Restrict workflow edit and execution rights to the minimum set of approved maintainers. Verify and protect workflow outputs before downstream jobs consume them. Review chained workflows for insecure assumptions, untrusted inputs, and unsafe automation logic. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Storage and Exposure | Chained workflows can propagate secrets or secret-bearing artifacts into later jobs. |
| NHI-03 — Overprivileged Non-Human Identities | Downstream workflows often run with broader machine permissions than the upstream step. | |
| NHI-09 — Supply Chain Trust | The term describes a workflow-to-workflow trust boundary inside a delivery chain. | |
| Recommendation — Keep secrets out of reusable handoffs and validate any artifact that could expose credentials. Limit workflow tokens and service credentials to the smallest privilege set needed. Require provenance checks before letting one workflow trigger another privileged workflow. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions Are Managed | Triggered workflows need tightly governed permissions across the handoff boundary. |
| PR.DS-6 — Data is Protected During Transmission | Artifacts and outputs transferred between workflows need integrity protection in transit or at handoff. | |
| Recommendation — Apply least-privilege permissions to both workflows and the transition between them. Protect workflow handoffs with integrity checks before downstream consumption. | ||
Related resources from NHI Mgmt Group
- What breaks when a low-privilege AI agent can trigger a higher-privilege workflow?
- 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?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
