GitHub 於 2026 年 7 月 28 日宣布，GitHub Actions 現在會把部分可能有害的 workflow run 暫停，待人工批准後才開始執行。這項改動針對的是 supply-chain attacks：攻擊者利用被盜的 GitHub credentials，將惡意 Actions workflow 推入 repository，目標可能包括竊取 CI/CD credentials 及進一步發動攻擊。
新的流程在 workflow 啟動前加入一個風險閘門。當 GitHub 判斷某次 run 可能有害，run 不會立即執行，而是等待具有 repository write access 的 collaborator 檢視和批准。批准必須透過 authenticated web session 提交；批准後，workflow 才會按正常流程繼續。這意味著從 commit 到執行之間，多了一個由平台觸發的檢查點。
對 repository 維護者來說，這項保護不需要額外設定，GitHub 會自動套用。自動化本身不會因此全部變成手動：只有被識別為可能有害的 workflow run 才會被暫停，已經通過風險判斷的 run 仍可照常執行。這種設計把批准行為集中在少數高風險情況，而不是要求團隊逐次批准所有 CI/CD 工作。
目前的範圍有清楚限制。GitHub 表示，保護只適用於 github.com 上的 public repositories；GitHub Enterprise Server 暫時不提供這項保護。團隊不能因此推斷企業自建環境已經有相同的 server-side gate，也不能把「有批准流程」理解成 repository 已經完成整套 supply-chain 防護。
這項更新的價值，在於它把 workflow 的信任模型由「有權限推送就可以直接執行」改成「平台先檢查，必要時要求另一個具寫入權限的人確認」。但人工批准仍然需要看 workflow 做了什麼：例如觸碰哪些 secrets、使用哪些 third-party actions、要求哪些 permissions、是否固定 action 版本，以及最近的 commit 和 contributor 是否合理。批准按鈕本身不是安全審查的替代品。
對使用 AI agent 或其他自動化工具產生 workflow 的團隊，這個檢查點尤其值得保留。代理可以協助產生 YAML、修改 permissions 或更新 action，但當結果會接觸 CI/CD credentials 時，應讓平台或人工在真正執行前有機會攔截。更重要的是把 workflow review、least privilege、secret rotation、action pinning 和 audit log 放在同一條交付流程內。
GitHub 這次沒有聲稱風險判斷可以攔截所有惡意 workflow；公告只說明部分可能有害的 run 會被 hold。較穩妥的理解，是平台新增了一道預設開啟的啟動防線，而不是宣告供應鏈風險已經解決。團隊仍應按自己的 repository、runner、secrets 和部署環境驗證實際行為。
