Agent 提交了代码，PR 打开了，审查工作流也写在仓库里。过去，我们很容易把这三件事连成一条直线：PR 事件出现，AI Reviewer 就会被唤醒。但 工作流存在，不等于平台一定允许它运行。GitHub 即将改变这条链的默认条件。
这次不是抽象的安全倡议。Mira 当前有三个公开仓库，实际把 Organization AI Review 接在即将受到限制的事件上。我们需要分清两件事：仓库里的审查实现是否守住了权限边界，以及 GitHub 是否仍会放行这个触发器。前者不能代替后者。
发生了什么：默认允许变成默认阻断#
2026 年 11 月 2 日，GitHub 宣布，从 12 月 2 日起，公开仓库中的 pull_request_target 事件将默认被 GitHub Actions 阻断，除非适用的 Actions event policy 已明确允许。私有与内部仓库不在这次默认规则的影响范围内；已经存在的适用事件策略也不会被简单覆盖。
在正式执行前，GitHub 安排了两次短时强制演练：11 月 9 日、11 月 16 日，均为 16:00–18:00 UTC。演练时，受默认规则影响的工作流会留下带错误注解的失败运行，而不是执行任务；其余时间默认策略仍处于 evaluate 模式，可在 Policy insights 观察「如果现在强制执行，会拦住什么」。
原因是 pull_request_target 的特殊信任位置。它在目标仓库的可信上下文中运行，能够获得基础仓库的令牌和 Secrets；如果工作流随后把来自外部 PR 的代码当作可信脚本执行，就可能把高权限环境交给攻击者。GitHub 在安全指南里把「检出不可信 PR head 并执行其中代码」列为典型危险模式。
这项变化并不意味着所有使用 pull_request_target 的工作流都存在漏洞。它意味着平台不再仅凭仓库作者写了这个事件，就默认授予它执行机会。事件的可执行性，成为仓库代码之外的一项显式授权。
暴露的问题：写在 YAML 里的权限，不是全部权限#
pull_request 与 pull_request_target 不只是两个拼写不同的事件。前者通常用于在受限令牌下检查 PR 代码；后者适合由可信工作流读取 PR 元数据、做标签管理或调用受保护服务。把后者机械替换成前者，可能令需要 Secrets 的审查网关失效；保留后者并全组织放开，又可能扩大高权限触发面的攻击范围。
因此至少要区分三层边界：事件策略决定某类工作流能否启动；运行时权限决定启动后能接触哪些令牌、Secrets 与外部服务；PR 内容信任决定哪些输入只能作为待审数据，不能变成控制 Reviewer 的指令或可执行代码。
这三层中的任何一层都不能由另外两层推导。工作流使用 permissions: contents: read，不代表事件一定会被放行；代码严格隔离 PR head，也不代表 GitHub 会自动豁免；管理员允许某个事件，也不证明该事件里的每一步都安全。
Mira 的真实实践：审查边界存在，但平台策略尚未核实#
以下来自本次直接读取的仓库文件，而不是记忆中的实现。三个仓库均由 GitHub 仓库元数据确认是 public，并在当前 prod 中保留 pull_request_target：
它们监听 dev、test、prod 上的 PR 事件，且只对非 Draft、同仓库来源、符合既定分支转换条件的 PR 执行相应审查。Desktop 当前版本还显式检出可信 base SHA 的 Review Runner，再通过受保护的 Gateway 与审查包交互；Mobile 与 Docs 的调用器把 PR 标识交给 Control Room 的审查入口。这里的共同方向是：PR head 是被检查的对象，不应决定审查器的权限与控制指令。
这也符合 Mira Organization AI Review Policy：审查只提供只读建议，绑定准确的 base/head SHA，不得执行 PR 控制的代码来取得上下文，也不得把模型的审查结论冒充合并或产品验收。它与 GitHub 此次强调的风险模型在原则上相容。
但「原则相容」不是「自动获准运行」。本次核验的是仓库可见工作流与治理文件，没有取得 Organization / Repository Actions event policy 的实际配置，也没有读取 Policy insights 的命中记录。因此不能断言这三个工作流一定会在 11 月 9 日失败，也不能断言它们已经获得豁免。是否存在其他仓库的同类触发器，本次搜索也不构成穷尽审计。
另一个容易混淆的事实：Mira Docs 的纯文章 feat/* → prod 直达发布是维护者单独授权的内容流程；当前 AI Review 工作流的分支判断本就不会把这类 PR 当成常规 feat/* → dev 审查。这种既有跳过不能拿来证明新事件策略已通过测试。
应该验证什么，而不是立刻放开什么#
在第一轮演练前，最小的真实核验不是重写审查系统，而是到三个仓库或 Organization 的 Settings → Actions → Policies / Policy insights 检查当前策略与命中情况，确认这几个工作流是否会被默认规则拦截。GitHub 的执行治理文档说明，事件策略可以按仓库和具体工作流路径限定范围；不需要把整个组织的所有 pull_request_target 一次性放开。
若确有命中，应先判断审查调用器是否必须使用高信任事件：需要受保护 Gateway Secrets 的可信发布步骤，可以考虑保留受控触发器并做精确的工作流级允许；不需要特权的验证则应评估迁到受限的 pull_request。不论哪条路线，都要保持 PR head 与可信控制分离，并验证调用器的权限、事件来源、失败路径和审查结果绑定关系。这里是待验证的方案，不是 Mira 已执行的配置变更。
更重要的是做一次实际触发验证：在演练窗口或适用策略生效后，用一个符合分支条件的非 Draft PR 观察工作流是否启动、是否到达 Gateway、审查是否绑定正确 SHA、结果是否正常发布。工作流文件静态存在、CI 其他检查全绿，都不足以证明 AI Review 仍在工作。
还有什么不确定#
截至本次研究，GitHub 已明确公告了日期、范围和默认行为；但实际 Organization 事件策略、三个仓库是否已被现有策略覆盖、Policy insights 的命中记录、11 月演练的真实结果，均未由本次研究取得。不能把预计的风险写成已发生的事故，也不能把尚未验证的策略豁免写成已完成的修复。
这条信号对 Mira 的价值，甚至不只在于避免一次审查中断。Agent 工程的安全边界已经不再局限于提示词、模型工具和仓库 YAML：平台是否允许触发、运行时拿到什么权力、哪些代码可以被执行，必须分别拥有可验证的证据。 当 Agent 能越来越快地交付 PR，审查链本身能否可靠启动，就成了产品交付能力的一部分。
