On July 28, 2026, GitHub announced that GitHub Actions will hold certain potentially malicious workflow runs before they start. The change targets supply-chain attacks in which compromised GitHub credentials are used to push malicious Actions workflows into a repository, with the goal of stealing CI/CD credentials or carrying out additional attacks.
The new flow adds a risk gate before execution. When GitHub identifies a run as potentially malicious, the run does not start immediately. A collaborator with write access to the repository must review and approve it through an authenticated web session. After approval, the workflow continues normally. The path from commit to execution therefore gains a platform-triggered checkpoint.
For repository maintainers, the protection is automatic and requires no configuration. Automation does not become manual for every run: only runs identified as potentially malicious are held, while runs that pass the platform’s risk decision can continue as before. The design concentrates approval work on a smaller set of higher-risk cases instead of asking teams to approve every CI/CD job.
The scope is specific. GitHub says the protection currently applies to public repositories on github.com. GitHub Enterprise Server does not add this protection at this time. Teams should not assume that a self-managed environment has the same server-side gate, and the existence of an approval step should not be read as complete supply-chain protection.
The important change is to the workflow trust model: “a credentialed push can run immediately” becomes “the platform checks first and asks for confirmation when necessary.” Human approval still requires inspection of what the workflow does, including which secrets it can touch, which third-party actions it uses, which permissions it requests, whether action versions are pinned, and whether the recent commit and contributor make sense. The approval button is not a substitute for security review.
For teams that use AI agents or other automation to generate workflows, the checkpoint is particularly useful. An agent can draft YAML, change permissions, or update an action, but a platform or human should still have a chance to stop the result before it reaches CI/CD credentials. Workflow review, least privilege, secret rotation, action pinning, and audit logs should remain part of the same delivery process.
GitHub does not claim that its risk decision will catch every malicious workflow. The announcement says that certain potentially harmful runs will be held. The safer interpretation is that GitHub has added a default-on launch defense, not that supply-chain risk has been solved. Teams should still verify the behavior against their own repositories, runners, secrets, and deployment environment.
