企业管理脚本经常从一个管理员的个人访问令牌开始。脚本能跑起来，但它随后也继承了这个账号的权限范围，以及人员变动、凭据撤销和权限调整带来的维护负担。
GitHub 在 2026 年 10 月 23 日宣布 GitHub Apps 企业级安装正式可用，并扩展企业治理、安全和管理接口的支持。更多原本依赖 classic PAT 的自动化，现在可以评估迁移到应用身份。不过，装到企业并不等于获得所有仓库的内容权限，接口覆盖也没有一下变成百分之百。
这次扩展的是企业管理能力
GitHub Apps 可以声明所需权限，再由安装者授权。企业安装让应用获得企业层面的操作能力，适用于管理企业账号及其治理设置，而不仅是某个仓库里的开发操作。
本次公告新增或扩展的范围包括企业级组织和仓库策略、规则集、委派的绕过申请，以及双重身份验证要求、域名验证、IP 允许列表和访问限制等。企业资料、成员权限和仓库访问设置的管理也在其中。
这些并不是一个统一的“企业管理员”开关。例如，公告列出的 Enterprise bypass requests 权限只读，不能因为能读取申请，就推断应用也能批准申请。其他管理项同样有各自的权限定义。
原文还修补了一些已有权限的 API 和 GraphQL 覆盖缺口。应用可能早就有正确权限，却因某个接口不接受应用身份而只能保留个人令牌。现在可以重新检查这些例外，但仍要逐项核实目标接口。
官方称这些更新将进入 GHES 3.24。使用 GitHub Enterprise Server 的团队，应按服务器版本确认支持情况，不能直接把 Enterprise Cloud 的公告当成本地部署版本已经具备的能力。
一个应用可以有多个安装
GitHub App 的注册身份与安装实例是不同对象。同一个应用可以安装到企业，也可以分别安装到企业中的组织，每个安装有自己的授权范围。
| 安装或调用目标 | 主要授权范围 | 不能直接推断的能力 |
|---|---|---|
| 企业级安装 | 已批准的企业权限及支持这些权限的管理接口 | 自动读取所有组织和仓库内容 |
| 组织级安装 | 已批准的组织权限和所选仓库权限 | 自动获得企业级管理权限 |
| 仓库内容操作 | 对应安装已获得的仓库及内容权限 | 仅凭应用已安装到企业就可以调用 |
官方安装文档明确指出，企业安装不会授予组织或仓库权限；要访问这些资源，需要另外在相应组织安装。组织安装管理 API 是文档特别列出的例外，允许符合条件的应用管理组织中的应用安装，但管理安装的权力不能等同于直接取得仓库数据。
这会影响脚本的凭据选择。管理企业规则集时，应使用对应企业安装的身份；读取某个组织的仓库内容时，要使用具有相应授权的组织安装。把两种任务都塞给一个固定安装 ID，是迁移中容易出现的错误。
因此，配置中至少要区分应用 ID、安装 ID、目标企业或组织，以及实际调用所需的权限。收到 403 时，先排查安装目标和接口支持，不要马上给应用追加更大的权限。
不只是换一串 token
应用安装访问令牌的取得过程大致是：应用用自身凭据生成 JWT，针对目标安装换取安装访问令牌，再调用该安装允许的 API。GitHub 的认证文档说明，安装访问令牌在一小时后过期，SDK 可以帮助重新获取。
短期令牌能缩短单个访问令牌泄露后的可用窗口，但应用私钥仍是敏感资产。拿到私钥的攻击者可能继续获取新令牌，不能因为下游 token 只有一小时寿命，就把私钥放进脚本仓库、普通日志或共享构建产物里。
安装令牌不能突破应用安装本身获得的授权。令牌生成和权限收窄的具体选项，应以相应安装类型及端点文档为准，不要假定通用仓库安装示例里的所有参数都能原样用于企业安装。
另一个区别是“以安装身份执行”与“代表用户执行”。企业安装文档说明，应用可以取得安装令牌，也可以在用户授权后代表用户操作。后者仍要求用户自身具备相应权限，不能把用户登录当成扩大应用权限的捷径。
迁移前应先决定每项任务需要哪种身份。定时生成企业配置清单通常不应依赖某位员工每天保持登录，而必须代表用户作出的操作，也不宜悄悄改成应用自主执行。
安装和分发也有限制
按当前官方文档，企业所有者可以在企业级安装应用，App manager 不能仅凭这个角色完成企业安装。应用必须请求企业权限，即便同时声明了组织和仓库权限，企业安装也只批准企业这一部分。
来源同样影响能否安装。文档允许企业自身、企业内组织或第三方开发者拥有的应用；第三方公开应用可以通过开发者提供的安装链接安装，但企业外账号拥有的私有应用不能直接按这种方式安装到企业。
对于请求 Enterprise organization installations 权限的应用，文档还有更严格的归属限制，不能简单套用普通第三方公开应用的规则。计划用统一应用跨多个企业自动分发时，应先核对这项权限与账号模式的条件。
这类权限可能影响企业下许多组织。审批时除了确认应用能否工作，还应审查应用归属、私钥管理者、操作审计、停用流程，以及哪些任务确实需要写权限。
公告已正式发布，文档仍有预览标记
本次核对时，10 月 23 日的官方更新日志明确写着企业安装正式可用；它链接的安装指南却仍保留“公开预览”及部分限制段落。本文按较新的公告描述发布状态，同时保留指南中明确的授权与接口边界，不将两份资料拼成“所有能力已同步正式开放”。
例如，当前指南仍写着企业安装不支持企业级 webhook；组织和仓库事件需要对应安装。公告没有明确宣布这项限制已经解除，所以不能据此设计一个依赖企业安装直接接收全部事件的生产流程。
API 支持也应逐项处理。公告列出了新增权限和端点，不能推出任意企业 API 都接受安装令牌。试点时以具体 REST 端点、GraphQL 字段或 mutation 的认证说明和实际结果为准。关键能力存在文档冲突时，先向官方确认，再扩大使用。
从一份只读清单开始迁移
较合适的起点，是列出已有脚本调用的接口、实际读写动作和个人令牌权限，标明哪些已支持 GitHub Apps、哪些仍是例外。
可以先迁移一项只读配置核对任务，验证目标安装、令牌更新、分页、限流和错误处理。不要仅看一次 API 成功，就立即切换全套策略修改脚本。尤其是 IP 允许列表、双重身份验证和访问限制，错误修改可能直接影响成员登录与服务连通性。
写操作应在受控范围测试，保留变更前状态和回退路径，再逐步替换旧调用。classic PAT 的撤销也要等使用方确认迁移完成，避免既留下长期备用令牌，又误停仍依赖它的任务。本文没有替任何企业安装应用、改变权限或撤销凭据。
结语
这次更新让更多企业管理任务有机会脱离某个管理员的长期个人令牌。真正的迁移工作仍在接口和授权上：确认任务支持什么身份，使用正确安装，只批准需要的权限，并妥善处理令牌更新与私钥保护。
把这些边界分清，再替换凭据，比一次性给应用授予大量权限更容易验证，也更容易排查问题。
参考来源
- GitHub Changelog：Enterprise installations for GitHub Apps generally available，发布于 UTC 2026 年 10 月 23 日 15:03，北京时间 10 月 23 日 23:03。用于核对正式可用状态、新增权限与 GHES 3.24 计划。
- GitHub Docs：Installing GitHub App on enterprise，用于核对安装主体、企业与组织授权边界及当前限制。核对时仍含预览标记，本文已说明与公告的差异。
- GitHub Docs：Authenticating as a GitHub App installation，用于核对 JWT、安装访问令牌和一小时有效期。
资料核对日期为 2026 年 10 月 25 日；接口支持、权限及文档状态可能随版本更新，实际迁移应逐项验证。