读懂｜GitHub 拦下高权限工作流后，AI 智能体安全了吗？

GitHub 12 月 2 日起在公开仓库默认拦截高权限 PR 工作流，11 月先演练两次。由 issue 和评论触发的 AI 智能体不在这条规则之内。

在 GitHub 的公开仓库里，外部 PR 带着仓库密钥触发工作流，将从默认可行变成默认被拦。仓库里接了 AI 智能体的维护者会问：这下安全了吗？

答案是：只关上了其中一条路。外部 PR 借高权限工作流拿密钥的那条路被关上了。由 issue 和评论触发的智能体，不在这条规则之内。

两次演练定在北京时间深夜

据 GitHub Changelog 11 月 2 日的公告，从 2026 年 12 月 2 日起，GitHub Actions 在所有公开仓库默认拦截 pull_request_target 事件，仓库或组织的事件策略明确放行的除外。

私有和内部仓库不受影响，GitHub Enterprise Server 也不在范围内。

正式执行前有两次演练：11 月 9 日和 11 月 16 日的 16:00–18:00（UTC），即北京时间 11 月 10 日和 11 月 17 日的 0 点到 2 点。

窗口内被拦的运行会直接失败，并留下错误注释。窗口过后，规则恢复到只记录、不拦截的评估模式。

规则不是突然出现的。据 GitHub Changelog 9 月 17 日的公告，工作流执行保护当天正式上线。它分两类规则：执行者规则管谁能触发，事件规则管哪些事件能触发。

默认拦截 pull_request_target 随这次上线推出，原定 11 月 2 日执行，10 月 21 日改到 12 月 2 日。

拦它的理由，GitHub Docs 写得很直白：这个事件在基础仓库的上下文里运行，能拿到可写的令牌和仓库、组织的密钥。工作流若再检出并运行外部 PR 的代码，就构成所谓的「pwn request」。文档说，这类写法已是多起供应链入侵的根源。

今年 4 月 15 日，研究者 Aonan Guan 与约翰斯·霍普金斯大学的合作者公开了一类攻击。他们在 PR 标题、issue 正文和评论里写入指令，让三个在 GitHub Actions 里运行的智能体泄露密钥：

据 Aonan Guan 的披露原文，三家分别付了 100、1,337 和 500 美元赏金。Anthropic 的回复是，这个 Action 的设计并不针对提示注入加固。

这三条路径并不相同。Claude Code 的例子靠 PR 标题。按 Aonan Guan 的说明，GitHub 默认不向外部 PR 暴露密钥，用 pull_request_target 放行密钥的仓库才会中招。

Gemini 的例子靠 issue 评论，Copilot 的例子则把指令藏在 issue 的 HTML 注释里。

后续论文规模更大。据 arXiv 上的论文，作者截至 2026 年 3 月抓取了 112,568 个 GitHub 工作流，找出 4,174 个可被劫持。

涉及的智能体有 Claude Code、Gemini CLI、Qwen Code、Cursor CLI 等，触发来源包括 issue 评论、PR、issue 标签和 issue 或 PR 的内容。

我们的分析推断是，12 月 2 日之后，在没有显式放行的公开仓库里，Claude Code 式的外部 PR 标题注入拿不到密钥了。依据是默认规则拦的正是那个把密钥交给外部 PR 的事件。

issue 和评论触发的工作流则照常运行，它们本来就在基础仓库的上下文里、带着密钥。GitHub 给了管它的工具，即执行者规则，但要维护者自己开。

论文作者的建议也是这个方向：只让授权用户触发智能体，只给它完成任务所需的密钥和工具。

有人会说，GitHub 先拦被利用最多的一类事件，是务实的分步做法，评论触发早有执行者规则可管。我们接受规则本身是进步，但不接受把它当作智能体工作流的安全底线。

还不知道的是两件事。演练窗口里有多少公开仓库的工作流会失败，GitHub 没有公布。4,174 个可被劫持的智能体工作流里，有多少由 pull_request_target 触发，论文没有拆分。

如果 GitHub 把默认规则扩到 issue 和评论事件，或者公布数据显示智能体相关的密钥泄露主要来自 pull_request_target，这个判断要改。